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.
Anybody remember the User Mode Linux VM escape exploit?
Seems more elegant than nuking your machine.
At DefCon X, Gobbles announced a simmiler vulnerability in vmware, though no exploit or advisory has been released so far. For anyone that assumes they're just fear mongering, They also announced the zero day apache bug there, which I'm sure you all remember.
Pain lasts, kid. Its how you know you're alive. Sometimes I think this growing up thing is just pain management-TheMaxx
Holy crap he signed an NDA! Mod him up more! He has more nothings to say!
If you can manage to sneak an Xray thing in your keychain. If you know where a slot machine's memory is.
God spoke to me
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?
At first I thought "why don't you just fire a gun instead of expensive x-rays". But once X-ray emitting devices becomes small enough, this could be a new spy gadget. Walk up to the metal detector in the airport. Point your pencil (with built in X-rays) to the scanner and zap it. Then walk right in.
Or, it can be used for lesser evil stuff as well. In the office. Find the cubicle with the guy that just hates computers. Every time you walk by him to get a cup of coffee, zap his computer with your device. Try to time it so he loses maximum amount of work. Then sit back and watch him go postal.
"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.
I loaded the .ppt into my java port of Power point.
Then as soon as I turned on my 50 watt reading lamp to set the atmosphere, It all crashed ?
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 the last step I needed in my Java trojan I've been writing. Now all I need to do is go to everyone's house with my x-ray machine, and I'm in like Flint!
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.
Good. Maybe all those kids with neon lights in their cases will have the same problem. I'm sure case modding was fun for awhile, but when every mod has to include the basic package of lights, fans, etc., it becomes too stock. Just like every '89 Civic I see with cut springs & an F1 wing. Yes, I am grumpy when I wake up.
Yea, doing this from remote would be a little harder.....
RING RING, "Hi, um my name is 'Bob', Im from 'The Internet Company'. We think there is a problem and we need you to help us here. Um, we need you to set your computer next to your microwave for a minute. Oh, no can do?...ok, um, you got like a 50 watt lamp you can stick next to your computer case? Ok, good, yea, do that. Oh yea, and go to this java web site.....yea, I can wait..."
I GUESS you could do some social engineering to get someone to comply. Seems like it would easier to sent out a couple hundred "I make this game, its my first. Hope you like." emails with BO in them to get one to bite.
Tequila: It's not just for breakfast anymore!
The fact that most desktop/laptop and some server computers shipping today have no type of memory error detection or correction.
Back in the older days _all_ computers shipped with at least parity memory. Today you get no checking unless you buy a workstation or server class machine.
Did you ever notice that when you build an IBM system on-line that they make it very clear that the system uses non-parity memory where other companies never mention this? I think they know that someday someone will bring forth litigation on this subject and they want to make sure everything was clearly stated.
Did you ever wonder how much data is corrupted my bad memory chips? Remember that memory sizes are increasing all the time so one would think that the probability for an error is higher.
Did you ever wonder why Apple didn't use ECC memory in their xserve rack mount server?
It is often questioned on this site as to why spacecraft do not use the latest/greatest computing equipment available. It is because the flight-capable designs have proven themselves tolerant of harsh environments, including alpha/beta/X radiation. (And other things, like low power consumption, heat generation, etc.)
It would be nice to know that a smart card with all of my personal information could survive the places my wallet has been. I need quad redundancy and forward error correction in my pocket!
It was a pleasant surprise to see my paper on /. this morning. Now pdf slides are available here . My comments on the views shared here are also available .
Sudhakar .
But technically this isn't an attack on all sand-box virtual machines, just the early-binding ones like the JVM, which assume a program is safe to run after a single check at compile/link time. Late-bound (or dynamically typed) VM-based languages such as Smalltalk and Lisp aren't as vulnereable to this - only the memory allocation and other atomic system functions that are assumed "safe" are vulnereable, and typically there are only a couple of dozen of these (and a random cooking of which is very likely to crash the VM or the machine by their nature). Of course, randomly messing with the memory will cause program errors and undesired results, and compilers that do a lot of inlining and type assumption optimizations increase the risk.
In the great CONS chain of life, you can either be the CAR or be in the CDR.