July 2018 - cypherpunks-legacy

[tahoe-dev] Announcing Tahoe-LAFS v1.9.2
by David-Sarah Hopwood 06 Jul '18

06 Jul '18

ANNOUNCING Tahoe, the Least-Authority File System, v1.9.2 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.9.2 of Tahoe-LAFS, an extremely reliable distributed storage system. Get it here: https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.rst Tahoe-LAFS is the first distributed storage system to offer "provider-independent security" b meaning that not even the operators of your storage servers can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst The previous stable release of Tahoe-LAFS was v1.9.1, released on January 12, 2012. v1.9.2 is a bugfix release that primarily fixes regressions in mutable file support. See the NEWS file [1] for details. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers fail or are taken over by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems, including Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django, Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [3]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or cloud storage. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all important issues that we are currently aware of please see the known_issues.rst file [2].) COMPATIBILITY This release is compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. This is the seventeenth release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the foreseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with this series. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file "COPYING.GPL" [4] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to delay for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file "COPYING.TGPPL.rst" [5] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.rst" [6]. HACKING AND COMMUNITY Please join us on the mailing list [7]. Patches are gratefully accepted -- the RoadMap page [8] shows the next improvements that we plan to make and CREDITS [9] lists the names of people who've contributed to the project. The Dev page [10] contains resources for hackers. SPONSORSHIP Atlas Networks has contributed several hosted servers for performance testing. Thank you to Atlas Networks [11] for their generous and public-spirited support. And a special thanks to Least Authority Enterprises [12], which employs several Tahoe-LAFS developers, for their continued support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that we feel compelled to warn our users and issue a fix, then we will award you with a customized t-shirts with your exploit printed on it and add you to the "Hack Tahoe-LAFS Hall Of Fame" [13]. ACKNOWLEDGEMENTS This is the eleventh release of Tahoe-LAFS to be created solely as a labor of love by volunteers. Thank you very much to the team of "hackers in the public interest" who make Tahoe-LAFS possible. David-Sarah Hopwood on behalf of the Tahoe-LAFS team July 3, 2012 Rainhill, Merseyside, UK [1] https://tahoe-lafs.org/trac/tahoe-lafs/browser/NEWS.rst [2] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/known_issues.rst [3] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects [4] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.GPL [5] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.TGPPL.rst [6] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/quickstart.rst [7] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [8] https://tahoe-lafs.org/trac/tahoe-lafs/roadmap [9] https://tahoe-lafs.org/trac/tahoe-lafs/browser/CREDITS [10] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Dev [11] http://atlasnetworks.us/ [12] https://leastauthority.com/ [13] https://tahoe-lafs.org/hacktahoelafs/ _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Syndicated Dave and Declan... RSS
by Joseph Lorenzo Hall 06 Jul '18

06 Jul '18

Hi Declan, Dave (for IP, if you wish), Being one of the many of your pesky readers that spends a good deal of time in a news aggregator and likes syndicated news (RSS, ATOM, etc.), I've bugged you both before about setting up something with RSS. (Declan finally caved and is using some sort of blog software with RSS and ATOM feeds: http://www.politechbot.com/ ) As for building a feed of Dave's IP list, I finally had to take matters into my own hands and hire a mercenary. I got Carlo Zottmann to build an RSS feed for Dave's Interesting People List... here's the RSS feed: http://bootleg-rss.g-blog.net/ d.interesting_people_org_archives_interesting-people.php A special feature that Carlo included was the ability to add '?date=YYYYMM' (ex: 200407) to the end of the script to access the archive for a previous month. When no date is given, the script defaults to the current month. Further, Carlo will scrape any site that you wished had syndication for $2 (If you like the IP syndication and would like to make a donation to Carlo's efforts, let me know): http://bootleg-rss.g-blog.net/journal/2004/07/announcement-accepting- feed-requests.html (via Boing Boing originally) I also asked him to syndicate the Drudge Report for fun (which appeared to be a major pain in the ass considering it seems to be hand-edited): http://bootleg-rss.g-blog.net/d.drudgereport_com.php Joe ------------------------------------------------------------------------ Joseph Lorenzo Hall, SIMS PhD Student; UC Berkeley. [web:<http://pobox.com/~joehall/>, blog:<http://pobox.com/~joehall/nqb>] ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

[IP] Syndicated Dave and Declan... RSS
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

[Freedombox-discuss] Tahoe-LAFS is not a filesystem
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

Folks: I'm a developer on the Tahoe-LAFS project (https://tahoe-lafs.org ) and I would be happy to see it used in Freedombox. The projects have many goals in common. I'm also the founder of a startup that sells Tahoe-LAFS ciphertext storage service: https://leastauthority.com . I'm just writing this brief note to try to explain something -- Tahoe, the Least-Authority File System fits better for file sharing, streaming or network-attached-storage than it does for a normal, local filesystem. It should probably be moved from here, where it is currently listed next to MooseFS: http://wiki.debian.org/FreedomBox/ExampleProjects#Filesystems To here: http://wiki.debian.org/FreedomBox/ExampleProjects#File_sharing or maybe here or here or here: http://wiki.debian.org/FreedomBox/ExampleProjects#Streaming http://wiki.debian.org/FreedomBox/ExampleProjects#Network_Attached_Storage Where it can be listed next to things like ownCloud, SparkleShare, BitTorrent, Tin Can Jukebox, etc. The confusion is that Tahoe-LAFS *is* a file system, in a couple of senses. It has arbitrarily nestable directories and files (unlike a lot of newfangled storage systems), and it has an SFTP server, which means you can point sshfs at it and have a reasonably good access to it directly in your kernel VFS. You could also use PyFilesystem to integrate it into your local filesystem. *But*, while the compatibility and correctness of Tahoe-LAFS and its SFTP server are pretty good, its performance characteristics as a distributed, secure, fault-tolerant storage system are sometimes a bad match for the expectations of user-space programs that access their storage through the POSIX filesystem API. Some things work fine -- it depends on your specific use case, but some access patterns that are normal and efficient on a local filesystem like ext4 are painfully slow or even infeasible on Tahoe-LAFS. For example, opening a file for append, appending a few bytes, and then closing it again, and then doing this over and over 10,000 times, will take about O(N) time and O(N) space on ext4 (about 10,000 disk operations and about 10,000 units of storage on disk), but take about O(N**2) time and O(N**2) space on Tahoe-LAFS (about 100,000,000 network operations and about 100,000,000 units of storage on the backend), which means the program that does something like that will never finish and might use up a lot of your secure cloud storage space. Everybody wants to use Tahoe-LAFS through FUSE as though it were a local filesystem, but nobody actually uses Tahoe-LAFS through FUSE, to my knowledge. All the people who actually Tahoe-LAFS end up using it less like it is a "filesystem" like ext4 and more like it is an "application" for backing up, sharing, or hosting files. (N.B. the tahoe-lafs developers actively try to support whatever it is that our users demand, and so we continue to support and improve its behavior when it is treated as though it were a local filesystem, even though I don't exactly recommend it.) Regards, Zooko _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [FoRK] Fwd: [IP] Aaron Swartz commits suicide - The Tech
by Wayne Baisley 06 Jul '18

06 Jul '18

>From the family: http://rememberaaronsw.tumblr.com/ _______________________________________________ FoRK mailing list http://xent.com/mailman/listinfo/fork ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: Bitcoin P2P e-cash paper
by James A. Donald 06 Jul '18

06 Jul '18

Satoshi Nakamoto wrote: > When there are multiple double-spent versions of the > same transaction, one and only one will become valid. That is not the question I am asking. It is not trust that worries me, it is how it is possible to have a a globally shared view even if everyone is well behaved. The process for arriving at a globally shared view of who owns what bitgold coins is insufficiently specified. Once specified, then we can start considering whether everyone has incentives to behave correctly. It is not sufficient that everyone knows X. We also need everyone to know that everyone knows X, and that everyone knows that everyone knows that everyone knows X - which, as in the Byzantine Generals problem, is the classic hard problem of distributed data processing. This problem becomes harder when X is quite possibly a very large amount of data - agreement on who was the owner of every bitgold coin at such and such a time. And then on top of that we need everyone to have a motive to behave in such a fashion that agreement arises. I cannot see that they have motive when I do not know the behavior to be motivated. You keep repeating your analysis of the system under attack. We cannot say how the system will behave under attack until we know how the system is supposed to behave when not under attack. If there are a lot of transactions, it is hard to efficiently discover the discrepancies between one node's view and another node's view, and because new transactions are always arriving, no two nodes will ever have the same view, even if all nodes are honest, and all reported transactions are correct and true single spends. We should be able to accomplish a system where two nodes are likely to come to agreement as to who owned what bitgold coins at some very recent past time, but it is not simple to do so. If one node constructs a hash that represents its knowledge of who owned what bitgold coins at a particular time, and another node wants to check that hash, it is not simple to do it in such a way that agreement is likely, and disagreement between honest well behaved nodes is efficiently detected and efficiently resolved. And if we had a specification of how agreement is generated, it is not obvious why the second node has incentive to check that hash. The system has to work in such a way that nodes can easily and cheaply change their opinion about recent transactions, so as to reach consensus, but in order to provide finality and irreversibility, once consensus has been reached, and then new stuff has be piled on top of old consensus, in particular new bitgold has been piled on top of old consensus, it then becomes extremely difficult to go back and change what was decided. Saying that is how it works, does not give us a method to make it work that way. > The receiver of a payment must wait an hour or so > before believing that it's valid. The network will > resolve any possible double-spend races by then. You keep discussing attacks. I find it hard to think about response to attack when it is not clear to me what normal behavior is in the case of good conduct by each and every party. Distributed databases are *hard* even when all the databases perfectly follow the will of a single owner. Messages get lost, links drop, syncrhonization delays become abnormal, and entire machines go up in flames, and the network as a whole has to take all this in its stride. Figuring out how to do this is hard, even in the complete absence of attacks. Then when we have figured out how to handle all this, then come attacks. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: Bitcoin P2P e-cash paper
by James A. Donald 06 Jul '18

06 Jul '18

Satoshi Nakamoto wrote: > When there are multiple double-spent versions of the > same transaction, one and only one will become valid. That is not the question I am asking. It is not trust that worries me, it is how it is possible to have a a globally shared view even if everyone is well behaved. The process for arriving at a globally shared view of who owns what bitgold coins is insufficiently specified. Once specified, then we can start considering whether everyone has incentives to behave correctly. It is not sufficient that everyone knows X. We also need everyone to know that everyone knows X, and that everyone knows that everyone knows that everyone knows X - which, as in the Byzantine Generals problem, is the classic hard problem of distributed data processing. This problem becomes harder when X is quite possibly a very large amount of data - agreement on who was the owner of every bitgold coin at such and such a time. And then on top of that we need everyone to have a motive to behave in such a fashion that agreement arises. I cannot see that they have motive when I do not know the behavior to be motivated. You keep repeating your analysis of the system under attack. We cannot say how the system will behave under attack until we know how the system is supposed to behave when not under attack. If there are a lot of transactions, it is hard to efficiently discover the discrepancies between one node's view and another node's view, and because new transactions are always arriving, no two nodes will ever have the same view, even if all nodes are honest, and all reported transactions are correct and true single spends. We should be able to accomplish a system where two nodes are likely to come to agreement as to who owned what bitgold coins at some very recent past time, but it is not simple to do so. If one node constructs a hash that represents its knowledge of who owned what bitgold coins at a particular time, and another node wants to check that hash, it is not simple to do it in such a way that agreement is likely, and disagreement between honest well behaved nodes is efficiently detected and efficiently resolved. And if we had a specification of how agreement is generated, it is not obvious why the second node has incentive to check that hash. The system has to work in such a way that nodes can easily and cheaply change their opinion about recent transactions, so as to reach consensus, but in order to provide finality and irreversibility, once consensus has been reached, and then new stuff has be piled on top of old consensus, in particular new bitgold has been piled on top of old consensus, it then becomes extremely difficult to go back and change what was decided. Saying that is how it works, does not give us a method to make it work that way. > The receiver of a payment must wait an hour or so > before believing that it's valid. The network will > resolve any possible double-spend races by then. You keep discussing attacks. I find it hard to think about response to attack when it is not clear to me what normal behavior is in the case of good conduct by each and every party. Distributed databases are *hard* even when all the databases perfectly follow the will of a single owner. Messages get lost, links drop, syncrhonization delays become abnormal, and entire machines go up in flames, and the network as a whole has to take all this in its stride. Figuring out how to do this is hard, even in the complete absence of attacks. Then when we have figured out how to handle all this, then come attacks. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [Freedombox-discuss] Routing around nationwide and international Internet blocks
by Paul Gardner-Stephen 06 Jul '18

06 Jul '18

Hello Eugen, On Mon, Feb 28, 2011 at 10:23 PM, Eugen Leitl <eugen(a)leitl.org> wrote: > On Sun, Feb 27, 2011 at 02:27:29PM -0800, Matt Joyce wrote: >> The only solution I can think of for this is a modular hardware design at >> the physical level that allows for pluggable communication devices. Then > > That's called GBit Ethernet. Some cheap switches even come with > literal SFP and SFP+ slots. It would be interesting to see whether > a couple of cheap aligned Newtons wouldn't cover a few 100 m, or so. > >> allow individual groups to play with laser links, packet radio, gsm / > > I only recently found out that Android smartphones are down to > about 100 EUR in Far East. Because of small size and power envelope > and ability to link up to 3G they can be rooftop-positioned in > weatherproof cases for maximum range, and powered by a small, > cheap PV panel to last through the night. About 95 EUR in Australia for the Huawei IDEOS (network locked, but that doesn't matter for mesh networking) which ServalProject.org is already using as a mesh telephony platform. We also have PV panels that we can use with them. The trick at the moment is that if the phone goes flat, it won't turn back on by itself; but I am sure some clever person can find a solution to that problem. ... >> The problem is mesh networking tends to not work well legally outside of >> 802.xx standards and 2.4 ghz. > > I think our best hope is that next WiFi standards will move towards > realtime beamforming, boosting range while reducing local interferences. This is particularly valuable if you wish to avoid purposeful interference which is trying to take your mesh down. ... > Plug computers are a nice focus, and also a point of departure. > The advantage of plugs is that they're easily placed, immobile, > poweful, and offer both wired and wireless access. Smartphone-based > platforms are mobile, but power-limited, and hence cannot operate > 24/7 unless they're dedicated immobile units, whether mains or > PV-powered -- notice that they come with their built-in UPS. Personally I think that plug computers, mobile phones and more "ordinary" wifi devices like the VillageTelco.org Mesh Potato together provide diversity and specialisation to various tasks and appplications; no one solves all problems. This is why I am passionate that ServalProject.org phone software and VillageTelco.org Mesh Potatoes be interoperable (which they are), and I hope, also that they will interoperate with what this community generates. This also distributes the maintenance and leadership of these platforms further removing single points of failure. Paul. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [Freedombox-discuss] Routing around nationwide and international Internet blocks
by Paul Gardner-Stephen 06 Jul '18

06 Jul '18

Hello Eugen, On Mon, Feb 28, 2011 at 10:23 PM, Eugen Leitl <eugen(a)leitl.org> wrote: > On Sun, Feb 27, 2011 at 02:27:29PM -0800, Matt Joyce wrote: >> The only solution I can think of for this is a modular hardware design at >> the physical level that allows for pluggable communication devices. Then > > That's called GBit Ethernet. Some cheap switches even come with > literal SFP and SFP+ slots. It would be interesting to see whether > a couple of cheap aligned Newtons wouldn't cover a few 100 m, or so. > >> allow individual groups to play with laser links, packet radio, gsm / > > I only recently found out that Android smartphones are down to > about 100 EUR in Far East. Because of small size and power envelope > and ability to link up to 3G they can be rooftop-positioned in > weatherproof cases for maximum range, and powered by a small, > cheap PV panel to last through the night. About 95 EUR in Australia for the Huawei IDEOS (network locked, but that doesn't matter for mesh networking) which ServalProject.org is already using as a mesh telephony platform. We also have PV panels that we can use with them. The trick at the moment is that if the phone goes flat, it won't turn back on by itself; but I am sure some clever person can find a solution to that problem. ... >> The problem is mesh networking tends to not work well legally outside of >> 802.xx standards and 2.4 ghz. > > I think our best hope is that next WiFi standards will move towards > realtime beamforming, boosting range while reducing local interferences. This is particularly valuable if you wish to avoid purposeful interference which is trying to take your mesh down. ... > Plug computers are a nice focus, and also a point of departure. > The advantage of plugs is that they're easily placed, immobile, > poweful, and offer both wired and wireless access. Smartphone-based > platforms are mobile, but power-limited, and hence cannot operate > 24/7 unless they're dedicated immobile units, whether mains or > PV-powered -- notice that they come with their built-in UPS. Personally I think that plug computers, mobile phones and more "ordinary" wifi devices like the VillageTelco.org Mesh Potato together provide diversity and specialisation to various tasks and appplications; no one solves all problems. This is why I am passionate that ServalProject.org phone software and VillageTelco.org Mesh Potatoes be interoperable (which they are), and I hope, also that they will interoperate with what this community generates. This also distributes the maintenance and leadership of these platforms further removing single points of failure. Paul. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: CNN: 'Explores Possibility that Power Outage is Related to Internet Worm'
by Bernie, CTA 06 Jul '18

06 Jul '18

It is ridiculous to accept that a lightning strike could knock out the grid, or the transmission system is over stressed. There are many redundant fault, limit and Voltage-Surge Protection safeguards and related instrumentation and switchgear installed at the distribution centers and sub stations along the Power Grid that would have tripped to prevent or otherwise divert such a major outage. I believe that the outage was caused by the MSblaster, or its mutation, which was besieged upon the respective vulnerability in certain control and monitoring systems (SCADA and otherwise) running MS 2000 or XP, located different points along the Grid. Some of these systems are accessible via the Internet, while others are accessible by POTS dialup, or private Frame relay and dedicated connectivity. Being an old PLC automation and control hack let me say that there is a very good plausibility that the recent East Coast power outage was due to an attack by an MBlaster variant on the SCADA system at the power plant master terminal, or more likely at several of the remote terminal units "RTU". SCADA runs under Win2000 / XP and the telemetry to the RTU is accessible via the Internet. >From what I recall SCADA based monitoring and control systems were installed at many water / sewer processing, gas and oil processing, and hydro-electric plants. I also believe that yesterdays flooding of a generator sub- facility in Philadelphia was also due to an MBlaster variant attack on the SCADA or similarly Win 2000 / XP based system. To make things worst, the Web Interface is MS ActiveX. Now lets see, how can one craft an ActiveX vuln vector into the blaster? Oh, and for the wardrivers, SCADA can be access via wireless connections on the road puts a new perspective on sniffing around sewer plants. It is also reasonable to assume that we could have a similar security threat regarding those system (SCADA and otherwise based on MS 2000 or XP) involved in the control, data acquisition, and maintenance of other critical infrastructure, such as inter/intra state GAS Distribution, Nuclear Plant Monitoring, Water and Sewer Processing, and city Traffic Control. IMO I think we will see a lot of finger pointing by government agencies, Utilities, and politicians for the Grid outage, until someone confess to the security dilemma and vulnerabilities in the systems which are involved in running this critical infrastructure. Regardless of whether the Grid outage can be attributed to the blaster or its variant, this is not entirely a Microsoft problem, as it reeks of poor System Security Engineering practiced by the Utility Companies, and associated equipment and technology suppliers. Nonetheless, the incident will cause lots of money to be earmarked by the US and Canadian Governments, to be spent in an attempt to solve the problem, or more specifically calm the public. This incident should be fully investigated, and regulations passed to ensure that the Utility companies and their suppliers develop and implement proper safeguards that will help prevent or at least significantly mitigate the effects of such a catastrophe. Conversely, I do not want to see our Government directly involved in yet another "business", which has such a controlling impact over our individual lives. - On 14 Aug 2003 at 15:18, Geoff Shively wrote: > Just flipped on CNN, watching the masses snake through the > streets of Manhattan as correspondents state that this could be > an affect of the blaster worm. > > Interesting but I don't see how an worm of this magnitude > (smaller than that of Slammer/Sapphire and others) could > influence DCS and SCADA systems around the US, particularly just > in the North East. > > Thoughts? > > > Cheers, > > Geoff Shively, CHO > PivX Solutions, LLC > - **************************************************** Bernie Chief Technology Architect Chief Security Officer cta(a)hcsin.net Euclidean Systems, Inc. ******************************************************* // "There is no expedient to which a man will not go // to avoid the pure labor of honest thinking." // Honest thought, the real business capital. // Observe> Think> Plan> Think> Do> Think> ******************************************************* ----- End forwarded message -----

1 0