Slashdot Mirror
Microsoft Worms Crash Ohio Nuke Plant, MD Trains
stieglmant writes "For everyone who thought the 'blackout of 2003' was bad, how about this, according to an article at SecurityFocus, and another article at The Register, 'The Slammer worm penetrated a private computer network at Ohio's Davis-Besse nuclear power plant in January and disabled a safety monitoring system for nearly five hours.'" Russell writes "Maryland MARC Train Service was shut down most of Wednesday morning due to what sounds like the MS-Blast worm or one of its variants. The local Baltimore news reports that the cause was a signal malfunction but CSX, whose communications system runs the tracks, has an article describing the shutdown as a result of 'a worm virus similar to those that have infected the systems of other major companies and agencies in recent days'. This indicates that the network that the train signaling stations are on is not protected by firewalls, at least to block ports 135 and 444 where the DCOM vulnerability is attacked. Wow, taken to the extreme, the exploitation of their systems could have caused a train collision and injury or death to hundreds of Maryland and Virginia commuters."
It is horrifying that critical systems such as Nuclear (or Nucular as W. says) power plant safety systems have been compromized by rampant known issues with Microsoft Security I believe that it is worse that such critical systems are not better administered. Heads should roll in the IT department. This is also an indicator of how this Nuclear power plant has treated Homeland Security in general. Having such systems exposed to the internet is just plain negligent.
That reactor had been down since February of 2002 due to a 6" hole in the reactor head.
Blaster got past a lot of firewalls that way.
IIRC it specifically states in the MS EULA that the software is not to be used for running nuclear power plants among other things (life support systems, aviation systems...).
The infected systems were 'only' in the higher level of the control hierachy. Control systems in all plants like this (chemical, power etc) are built on multiple levels. You start at level 0, which is pretty much mechanical - safety valves, burst plates, simple thermostats. Those ensure that even if every control layer above that goes haywire and tries to make the plant blow up, you still remain safe.
:)
I discovered the usefulness of this after setting a digital pressure control on a pilot plant wrong - nitrogen vented everywhere (which makes an incredibly loud noise), my supervisor went mad, but nothing broke
Do a google search on "navy yorktown microsoft"
h tml
Yes, and find a lot of crap written by people who repeat a web myth. Now as far as people who were on the ship at the time or who actually wrote the software involved we get a different story. WinNT was not at fault. The truth is that a server app corrupted it's data, a client app tried to use that bad data, and the client app failed to control equipment. Can happen with any OS. Add to this the fact that the ship was a test platform not an operational ship and they were trying to break things.
"Others insist that NT was not the culprit. According to Lieutenant Commander Roderick Fraser, who was the chief engineer on board the ship at the time of the incident, the fault was with certain applications that were developed by CAE Electronics in Leesburg, Va. As Harvey McKelvey, former director of navy programs for CAE, admits, "If you want to put a stick in anybody's eye, it should be in ours." But McKelvey adds that the crash would not have happened if the navy had been using a production version of the CAE software, which he asserts has safeguards to prevent the type of failure that occurred."
http://www.sciam.com/1998/1198issue/1198techbus2.
"McKelvey writes that the failure, "was not the result of any system software or design deficiency but rather a decision to allow the ship to manipulate the software to stimulate [sic] machinery casualties for training purposes and the 'tuning' of propulsion machinery operating parameters. In the usual shipboard installation, this capability is not allowed.""
http://catless.ncl.ac.uk/Risks/20.37.html#subj1
At Dungeness B nuclear power station in the UK they still run the reactor control systems with BBC B computers. The reason is that the operating system and control code is so small (ca. 32KB) that the engineers have gone through it by hand and manually checked every possible scenario.
A complete flow chart exists that details all errors that can occur in the code and what the solutions are. Try doing that with Microsoft Windows or Linux. Sometimes the simple solutions are the best.
I've worked with VITAL control systems - train brake systems, landing gear, flight recorders, etc., and those systems are in a completely different space than PCs (or Suns, or IBM, etc). You're more likely to find Vertix Ada than you are MS C++ or any Java implementation. The likes of Sun, IBM, and Microsoft never even bid on the control systems I worked on.
Having said that, while the PC commercial vendor types like MS and Sun stay a far distance from control side (and rightly so), they definately bid on the monitor boxes. That SCADA may well be running a custom RTK, but the console that the operator back at base has in front of him could well be an XP system.
I've never used MS-based front ends myself, but I've written interfaces to OS/2-based consoles that talked to my onboard stuff, and I can't see any reason why a Win2K or XP front end would be any more or less contentious than an OS/2 one.
The problem is not the SCADA or braking system itself; it's the remote monitoring station. Often, those things are connected to the net to synch the atomic clocks, and sometimes for remote logging purposes. If *those* get compromised, the control systems may be affected, but they are not compromised. Which is to say, it's a major fscking PITA, but the brake system will still work on the train without remote intervention or monitoring; it's just not going to start again after it stops.
This indicates that the network that the train signaling stations are on is not protected by firewalls, at least to block ports 135 and 444 where the DCOM vulnerability is attacked.
It means no such thing. It is perfectly possible to have machine (such as a laptop) infected on the outside, then brought in and connected to the inter LAN, where it starts infecting machines it can reach.
And sicne when does port 444 have anything to do with it? Once exploited, the victim is running a command shell on port 4444.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
8-bit processors still dominate the CPU market in terms of volume, and very nearly in terms of profitability. They are virtually never used as general-purpose computers anymore, but due to low cost of development, deployment and testing, they are ubiquitous in the control systems industry.
Companies like Atmel and Microchip are constantly devising new and better 8-bit microcontroller chips for this market. A lot of them are available in hardened grades for just these uses. A modern one will often bundle the entire machine onto a single chip, with as much IO and analog interfacing as you could ask for.
Reading the ENTIRE assembly dump of a 32K program is rather simple. A team of a dozen engineers can verify it in a matter of a couple months (I mean formal verification here, like you would do for a truly critical system, not just "give it a look over").
While truly using a BBC micro is a little obsolescant, the ideals that caused them to do so are sound.
Hardware, software, and blinking lights!