Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

To answer that, ask yourself this. If you somehow got access to the root account on the central control computer of a nuclear power plant, could you cause a meltdown? Most likely, the answer is no, because you don't know how to control a nuclear power plant. You can run any command, but you have no idea which command would cause any real-world damage. If you're just doing it for the lulz, you could go for the ever-popular "rm -rf *" and cross your fingers, but if you want to be sure to cause damage, you're going to need some domain-specific knowledge. Not just knowledge about nuclear power plants in general, but also knowledge about how to manipulate the control systems at your specific target nuclear power plant.

In other words, even if you have an easily-exploited attack vector available to you, you still need to know a lot about your target in order to cause damage. Contrast this to guided missiles, which don't really need to know anything about the building that they are blowing up other than its GPS coordinates.

For this reason, I'm skeptical that "any dumb hacker" will ever be capable of causing something like a nuclear meltdown via virus infection.



On modern reactors, it would be hard even for the plant operators to cause a meltdown -- there's just too many passive measures in place. You'd probably need to start by walking around the reactor smashing bits of machinery first.

On the other hand, triggering the reactor to automatically shut down would be pretty easy -- and if you shut down all the nuclear reactors in the US for a few weeks, you'll certainly have made a significant impact.


I'm reminded of a fairly recent -- or recently released -- demonstration where researchers (in Idaho, IIRC) programmed a large engine/generator to self-destruct. It was then pointed out that latent inventory on such items is practically non-existent and replacement time is several months. I believe that replacement is also increasingly dependent upon China; North America essentially doesn't make the item, or critical components, any more.

Knock out several of those in critical locations, and you start to grind the U.S. economy to a halt.

You don't need to go nuclear. And destroying the engine was a fairly simple task of pushing it well outside its performance envelope.

EDIT: Looks like pnathan already cited this event -- see the last link in this comment:

http://news.ycombinator.com/item?id=3035909

It's a bit older than I remembered. The article is dated September, 2007.

I note incidentally that for one "catastrophic" scenario they describe, with an estimated "cost" of $700 billion, the damages figure now pales in comparison to what the U.S. economy has been through in the last few years. A bit of a lesson of its own regarding the rhetoric that surrounds the actual topic.


Part of Langner's point is that if you can insert code into the PLC, which Stuxnet shows you how to do, you don't need any insider information to create a damaging payload. Just stop the PLC from running after a given date, or for thirty seconds every half hour, or whatever. The PLC is there for low-level, real-time control of actuators that direct some physical process, and once the control stops, the process will go on in some unwanted way.

Of course there are safeguards to prevent catastrophes, but even stopping some part of the automation in an industrial plant could easily cause serious problems such as damaged equipment and downtime for debugging.


you do need insider knowledge to know that the PLCs cessation of function would cause your effect. stuxnet didn't stop the PLCs, it changed their operation. how did they know what to change it to..?


"force cooling pump off" would probably do the job


But mechanical systems have safety checks built into them. For example, some years ago I wrote some code that helps to monitor and control gates on a reversible interstate highway. Theoretically, the main traffic center software could command all of the gates open, causing head-on collisions. In reality, in addition to many software checks, there were real-world checks and balances involving predictable manual procedures, on-site human intervention, etc. so much so that a Stuxnet-like attack would be extremely difficult, if not near impossible.


Even systems as common as traffic lights work this way. Even if the software were to command "green" in all directions, the electrical circuits are such that it's physically impossible. You'd have to actually rewire the signals to make this happen.


Exactly my point. Although even fail-safe systems can fail, as I've personally seen a T-intersection where all the lights were green (which was freaky to see and caused a little traffic jam). But your point still stands, as I'm not sure how the lights got in that configuration; it could have been worker error.

Computer-controlled systems that can have disastrous real-world consequences almost always have built-in checks to avoid these failure states.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: