Microsoft Worms Crash Ohio Nuke Plant, MD Trains 817
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."
The Horror (Score:4, Informative)
Didn't "crash" the plant (Score:5, Informative)
David-Besse Plant Problems (Score:3, Informative)
Re:The network administrators... (Score:5, Informative)
Blaster got past a lot of firewalls that way.
Railroad signalling affected? (Score:2, Informative)
Perhaps an accessory system was involved, but rail signalling involves quite proprietary and LOW-SPEED networking (on the order of 30 baud) on TOTALLY private wires.
Rail signalling was gradually developped over the last 150 years, and the earliest remote-control and automatic operations were developped almost 100 years ago.
From the onset, reduntancy and feedback was employed (for example, whenever a switch is automated, a separate sensor arm is attached to the switch points, as to monitor the exact switch position, as opposed as the switch motor actuating arm position), and the technology is extremely conservative (gravity-actuated relays with extremely big coils to pick-up the heavy armatures, contacts made out of special alloys that are guaranteed not to stick in case of arcing - why would they, they are overwhelmingly oversized for the current they carry- and the whole thing is mounted on heavy coil-springs to insure immunity to vibrations).
For compatibility purposes, whenever solid-state components are used, they are absolutely electrically compatible (and opto-isolated) with the older electromechanical relays.
And finally, everything runs on #8 gauge wire and the nominal voltage is 10 volts.
Such an overdesigned system can withstand quite a lot of punishment. So the idea of a worm bringing down signalling is laughable at best.
But if the suits insist on using a paperwork system that is vulnerable to worms, then, such lunacy can explain the outages...
Sometimes firewalls aren't enough. (Score:3, Informative)
As most people who had to fight this worm already know, a firewall doesn't do you a whole lot of good if you have users with laptops who plug in at home, then bring in their infected PCs and plug them into your internal network.
I'm not saying there aren't still ways to prevent the spread of worms, but an internal infection is in no way proof that there's no firewall. In many cases, it's just a clueless PHB who refuses to let the IT department lock down his laptop or install a personal firewall on it.
Re:Didn't "crash" the plant (Score:2, Informative)
Makes you wonder how soon they're going to remove the analog systems in the name of 'efficiency'.
Re:What I don't get (Score:3, Informative)
It's not uncommon for industrial applications on Windows to require admistrator access to merely run. Any services you turn off, as a result, can be modified by the user or turned back on.
Re:The network administrators... (Score:3, Informative)
"[T]he distinct trend within the industry is to link the systems to access control center data necessary for business purposes," reads the report. "One utility interviewed considered the business value of access to the data within the control center worth the risk of open connections between the control center and the corporate network."
IOW, they do it to save money. Time to be scared.
Re:No firewall? Probably not. (Score:4, Informative)
Re:The network administrators... (Score:3, Informative)
B3.2. High Risk. Unless QSS has provided its express written consent for each Runtime Component in the Runtime Configuration, the Software may not be, and OEM will ensure that it is not, used in any application in which the failure of the Software could lead to death, personal injury or severe physical or property damage (collectively, ?High-Risk Applications?), including but not limited to the operation of nuclear facilities, mass transit systems, aircraft navigation or aircraft communication systems, air traffic control, weapon systems and direct life support machines. QSS expressly disclaims any express or implied warranty or condition of fitness for High-Risk Applications.
So if you fork out the cash, you can get a license that says, "yes, you can use this software to run a nuclear power plant."
A bold statement, but apparently it's well founded. I've heard nothing but good things about the reliability of QNX.
J
No sh*t (Score:3, Informative)
What the hell does it take, MS-inducted Chernobyl to make them realize that such an OS HAS NO PLACE in a nuclear reactor? Or how about NT crashing a critical system in a battleship?
Have we REALLY become so pampered that we need a bloody GUI for every frickin thing we do? I don't advocate running X in linux either, it's stupid.
If there were ever a case for a specialized proprietary system, this would be it. Just do something that does the job, and does it well. No fancy GUI crap, no million-other-f***ing-functions that can cause it to break down. Linux is a bit better than windows because you can trim it to be very specific... so something linux-based could be OK (just not a whole RedHat install, or anything else).
I mean hell, it's security monitoring. You could work this with a few text screens, some big red lights, sirens, maybe a nice voice that says "Red Alert" a-la-startrek or something.
We don't need a windows installation, with a million doodads and AOL messenger stating "You've got Meltdown" for a nuclear reactor. We don't need a GUI. We need something that does the job (well), and is secure. Cut out the extra crap... and with MS there is more and more crap you can't cut out ('nix has source, you can trim all you like, but in-house is still better).
Makes you wonder exactly how many systems like this you are trusting your life too. Wonder if we'll find out tomorrow that the power-outage was caused by a virus.
Navy/Marine net infected (Score:2, Informative)
There are a number of other articles our there that give info on this and the reports of other nuke plants being affected on the fateful day last Thursday.
Re:The network administrators... (Score:3, Informative)
Train vulnerability (Score:4, Informative)
Re:Software Disclaimer (Score:5, Informative)
Trains not unsafe. (Score:1, Informative)
Not really, the systems that control the signals themselves do not rely on the computers. The are fail safe systems that default to safe conditions when a part of the system fails. Worst case the conductors of the trains would see a wrong or non existant signal and stop.
Re:For train control, Fail Safe == Stop Working (Score:2, Informative)
Microsoft Software Causes Train Brakes to Fail. Amtrak Ruined!"
Re:Safe == not sexy. (Score:5, Informative)
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
Re:No firewall? Probably not. (Score:2, Informative)
Patch, patch, patch should be the mantra of every company that runs their business on MS software.
no way, no how. (Score:4, Informative)
railroad signaling systems being what they are, I'm certain that this could not have caused a collision. Railroad signal systems run on proprietary, failsafe software. Getting trains to bump into each other, in most systems, takes a computer glitch in code, or a specific series of commands to the signal system, plus a human overriding signal indications in the field.
in every signal system i've ever seen (quite a few across the country), the only thing that MS software/OS relates to is supervisory remote control and monitoring. The local signal logic (software or relay based) will not allow for unsafe train movements, even if accidentally commanded to do so, unless very specific conditions are met. Again, an Engineer passing a stop signal, for example, is usually one of the requirements.
Re:The network administrators... (Score:2, Informative)
And microsoft makes it clear in their EULA that they don't consider their software fit for any purpose (yes they actually say they don't guarantee it's suitable for ANY purpose).
Wow these guys don't look fit to run a... (Score:2, Informative)
Check out http://www.ohiocitizen.org/campaigns/electric/nuc
Re:The network administrators... (Score:2, Informative)
I can't believe everyone is forgetting the next *nuclear* aircraft carrier, CVN-77, "will use Microsoft Windows 2000 to run its communications systems, aircraft and weapons launchers, and other ship electronics. "
http://www.fcw.com/fcw/articles/2000/0807/news-
http://www.gcn.com/vol19_no27/dod
Web Myth: WinNT Stops Ship (Score:5, Informative)
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
Re:Web Myth: WinNT Stops Ship (Score:5, Informative)
Wether it was MS's fault or the App's fault that the ship was dead in the water was not part of this discussion. In fact, everything I've read said that this was an unhandled floating point exception, which is of course the problem of an application not the OS.
Enterprise/Mission-critical/Life-critical systems should not be doing floating point operations period. They introduce too many errors and inaccuracies. If you think you need floats, try adjusting your units.
-molo
Re:The network administrators... (Score:5, Informative)
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.
What's up with microsoft today? (Score:1, Informative)
OK, I've worked in a Nuke and I'm angry. (Score:3, Informative)
The worm I got and the reaction I got from the mail administrators was very disturbing. The thing exploded out of Outlook's preview window, spawened multiple porn browsers and did God knows what else. I turned the computer off hard. The IIS people at corporate cenrtal did not believe me, executed to completion the thing by remote control without realizing it, recomended that I simply not use the preview screen and said that they got stuff like that all the time and it was "a normal part of advertising." It made me sick. They thought I was worried about being shit canned for looking at porn and were oblivious to the implications of rooting a desktop that could remote into any other desktop in the company. STUPID FUCKING MICROSOFT CERTIFIED ASSES. Whew, I really was angry and I still am.
My plant's server was also a pain. It was some goofey overpriced Dell "server" that collected information from plant systems and made it available. It failed often and required many late nights for the people in charge of it. There were many such system but the newest one had the most information. It also had the least abiltity to do real damage. For all it's faults, it was an improvement over what was there but was not required for the safe operation of the plant. It could have been done much better had Microsoft not had anything to do with it.
The answer is not to dissconect the "business" network from the plant information systems, it's to fix the network in a fundamental way. First, the network needed to be split into an Engineering section and an Adnministrative section, with Engineers only having partial access to the Administrative network and Administration haveing NO access to plant data systems. Data systems already have NO access to control systems, and this is a good thing. These architectual changes are valid regardless of software used but Microsoft must be eliminated from all of it. From a pure business perspective, having your information available to sabotage is unacceptable and that's what Microsoft's poor security record yields. Free software is superior from a security, and functionality standpoint and is now equal in ease of use. If running Microsoft keeps engineers from viewing plant data, while giving competitors and sabatours full access to such data, the costs of Microsoft is obviouly too high. Seperating engineers from their data, as Security Focus's write up implies, would be a costly mistake. I have every confidence that power plant operators will make the right choice soon.
Hell yes, I'm mad. I just about screemed this at the top of my lungs while I was there and was ignored. When the business comes, I'm more than happy to work for someone getting it done.
Re:The network administrators... (Score:5, Informative)
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.
Safety-critical stuff, yes. Displays, no. (Score:3, Informative)
As such, those systems are typically many years out of date relative to current hardware and software - if they were upgraded, they'd have to be recertified, and certification is so expensive that keeping thirty-year-old hardware running is cheaper. There are reactors in the US that are still controlled by PDP-8s (4K of 12-bit core memory, folks).
As others in this thread have said, the system that got hosed at this reactor was a modern status display added well after the reactor was signed off on and running. If it crashes, the operators get harder-to-understand information from the simpler systems in the control room, but the basic safety systems are still in place.
Homer Simpson to the contrary, the people who run nukes aren't completely stupid.
Re:The network administrators... (Score:2, Informative)
But don't underreact. (Score:3, Informative)
Sudden inspiration to use WashingtonPost.com and not Google
Well, I did a search of WashingtonPost archives for 95-98. It was January 7th of 1996, the tracks were icy, and the control was by a central computer. It kept it at 75mph and when it did brake for the station it slid into a parked train. Other than later articles discussing various probes into whether the possibility of the problem was known and ignored, I can't give much more info. The full text in the archives is only available for a fee, but the relevant facts were in each's first two paragraphs.
I guess my point is even the brakes didn't help, once the train was doing 75mph. Don't assume that human intervention will overcome computer error. a) They can make the errors a lot more quickly than humans can compensate. b) Sometimes we misread the errors.
If interested, archive search [washingtonpost.com]. I used Metro, Train, accident, from Jan 96 - Mar 96. If you expand to later dates you will see the followups.
Try again, (Score:5, Informative)
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.
Small systems (Score:5, Informative)
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.
Re:The network administrators... (Score:4, Informative)
Most likely this scenario was the same as the one at TI here in Dallas a few weeks ago. Some nimrod from marketing or somewhere in the company brought their laptop home, got it infected, and brought it back to infect the network. Fact is, admins can't control absolutely everything in their networks.
It's surprising to me that during this latest ballooning Microsoft crisis, Linux and Macintosh aren't getting more press. They can always step up and say "Ha Ha, this isn't happening to us."
Re:The network administrators... (Score:1, Informative)
If you don't know what an operating system really is, and what it is supposed to do, then you don't know why Windows is a bad choice for anything that shares the network with a SCADA system.
If your plant goes down because infected Windows machines starve the control systems for bandwidth, can you say that Microsoft wasn't the problem? Many people here (not you) have done exactly that, and it's absurd. It doesn't matter if a Microsoft system controls the switch, if it interferes with the systems that do control the switch it is just as guilty in the failure.
Safety Switches (Score:3, Informative)
Posting without reading (Score:3, Informative)
I think not. In his post he says that
That's the SLAMMER SQL WORM in JANUARY
Not the MSBlaster worm that's been going around for the last week or so. Blocking ports 135 or 139 or 445 would not affect the Slammer worm since it uses the 1433 MS SQL port.
Re:Posting without reading (Score:2, Informative)
That still doesn't forgive the numerous posters here who spoke of the nuclear facility in relation to the Blaster worm not the Slammer worm.