Slashdot Mirror
Using Memory Errors to Attack a Virtual Machine
gillus writes "A very cool scientific paper from Appel and Govindavajhala that explains how virtual machines like java or .Net can be exploited. How? Quite simple, bomb your DRAM chip with X-rays... or more simply with 50-watt spotlight, as the authors demonstrate. Definitively worth a read!"
Reports are sketchy at present, but we're being led to believe that it's easy to compromise a machine to which you have physical access!
Film at 11.
Send lawyers, guns, and money!
Now when I benchmark my computer using the punch-the-monkey java applet using a 50 watt spotlight, I'll have to be more careful!
Just overclock your tamper-resistant machine to the bleeding edge of running at maximum MHz you can get. Tweak the speed to the point that the body heat emitted by regular users will not overheat the CPU, but anyone approaching the machine with a 50 Watt bulb would fry the machine before gaining access to data.
:-)
However, now you get a denial of service attack, but hey, it's better than information disclosure or arbitrary code execution.
Oh great, it must be the Apocolypse or something. They actually posted a *link* to a *PowerPoint* document in a Slashdot article! Worse yet, no one seems concerned.
Furry cows moo and decompress.
If the air conditioner went out at midnight, most system administrators wouldn't know until the morning.
I used to be a narrator for bad mimes. (wright)
(There are some things you just never forget from your high school physics lab)
It turns out that if you have physical access to a system, you can perform a pretty effective denial of service attack using a rather devious little bit of technology called a 'baseball bat'.
Fortunately for the attacker, few users are surprised these days when applications use hundreds of megabytes to accomplish trivial tasks.
Java: the COBOL of the new millenium.
Holy crap he signed an NDA! Mod him up more! He has more nothings to say!
Surely the solution is obvious: make the posession of clip on lamps an offence under the DMCA, I cannot see why someone would want to posess such equipement unless it was to break into a computer and steal the latest music CDs....
Then, when doing the test/comparison, if there is not consensus in the bits (they should be all 1 or all 0), you know some memory error has occurred. The confidence level in the boolean test could be made arbitrarily high by storing increasing numbers of redundant bits.
This would slow things down considerably but it seems cheaper than lead cases.
This countermeasure is obviously not foolproof because most branches ultimately come down to a single register test but perhaps it's an improvement? Comments?
There are no karma whores, only moderation johns
Using bit errors to flake out machines, where there is no parity or other error checking, is very far removed from "secret tinfoil hat" stuff. Why do you think chips are packed in black epoxy?
"New LEAD cases from lian li to protect your system from intuders" Just another thing to worry about when it comes to security.
A non-animated PDF version here.
:-)
Link is valid for 7 days
How many websites would have an article that begins:
"A very cool scientific paper..."
Oh dear, we really are geeks, aren't we.
Read reviews of shopping cart software
I Believe I could be mistaken but the guy who made up the finite state machine for ECC had a mental break down. Making something like that is very complex I wonder how long parity checks which offer no correction where thought to be state of the art.
Um... no. The paper states that if a single-bit error can be induced, then the probability that this single-bit error will then allow the exploiting program to execute arbirary code (as opposed to causing the OS or the VM to crash, etc) is 70%.
So, keep in mind that there are two components to this exploit: 1) writing a program that takes advantage of single-bit errors to execute arbitrary code, and 2) wait for cosmic rays or direct some radiation yourself at the hardware to induce soft errors. The effectiveness depends largely on how quickly/reliably you can induce such errors w/out crashing the machine in the process.
Maybe the techniques for programming the exploit program described here are well known to more experienced programmers, but I found the article extremely interesting and enlightening. I've been taught for years about the superiority of Java's type system as a security measure, and I know that a lot of theoretical work and proofs have been done to show that Java's type system is secure, but this exploit manages to get around the type safety with such a simple trick that I'm kicking myself for not having seen it myself. It's almost elegant, the way they get it done.
This (excellent) paper alludes to the usual situation that cheaper machines tend not to use ECC in memory modules and in other parts of their architecture in order to save on manufacturing costs.
:-)
Note however that this common perception is not strictly speaking entirely accurate or necessary, because if a system is designed to meet a given level of reliability then a machine with ECC may end up being cheaper than one without ECC, because the error detection and correction can make up for reduced reliability in the rest of the hardware.
As an example, some components may be run closer to their operating limits, possibly partially overclocked, or power supplies may be less well regulated and hence electronic noise margins may be slightly compromised, or the system may be designed with substandard cooling, and so on. ECC could help mitigate some of the effects of such presumably cheaper designs, while still maintaining the reliability of better implementions.
So, there's slightly more to the "ECC only found in better systems" argument than at first meets the eye. As usual, caveat emptor.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
This is good stuff. Although the experiment used physical access to stress the memory, the theory could be used as an exploit in real situations in ways that the narrow of mind (like me) cannot conceive.
Perhaps this is not a method of practical attack on a machine. But it may be just a matter of creative thinking.
The key take away is to not disallow the possiblity.
Threats you discard as harmless is a logical place for an attacker to begin. Remeber the Maginot line.
I expect posters to not read the article (well, ppt), but even the submitter didn't read it?
The article does mention x-rays, saying "not enough energy to change a DRAM capacitor." Yet everyone talks about x-rays...
I found the phrase from the article "screw driver to remove hard drive" amusing when I first read it. Then I realized they meant "screwdriver". I thought initially they were referring to a DOS attack by corrupting the device driver!
And any literary work can be obtained with an infinite number of monkeys sitting at an infinite number of typewriters for an infinitely long period of time.
Most serious ciphers attacked using brute force with contemporary technology will probably hold out until the universe's heat death. Not to mention the fact that some experts claim that there simply is not enough energy in the universe to cycle a 128 bit counter through all its states, let alone perform any computations.
Pathman, Free (as in GPL) 3D Pac Man
One use for this sort of thing might be to get a palladium system to do something it's not supposed to. In that case you'd have access to your own machine.
Palladium is just a specialized VM that runs on tamper proof hardware, that's designed to let other people trust the results of some computations performed on your machine.