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!
Bet you didn't even read the abstract. Here's the relevant bit:
Our attack is particularly relevant against smart cards or tamper-resistant computers, where the user has physical access (to the outside of the computer) and can use various means to induce faults; we have successfully used heat.
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?
A non-animated PDF version here.
:-)
Link is valid for 7 days
Okay, but one still needs to be able to get their classes loaded into the VM. Think that makes the situations where this exploit is usable /meaningful unlikely. ( A tamper resistant machine that lets you load code onto it isn't really tamper resistant. ;) )
FWIW dynamic class loading is listed under as an
unsupported feature in the Java Card spec ( jcvm )
-- Regards, d
Some pointers:
Smart Cards will protect themselves to some extent, but the oft quoted voltage draw analysys is something they can't protect against..
What you really need for a physically secure device is an IBM 4758 CryptoCard.. of course, for it to be useful, you need it protected against key recovery attacks.
In a color TV, there are three types of phosphors, red, green and blue. The electron guns (or gun in a trinitron) must be aligned so that they hit the correct phosphors. Otherwise, the colors look off. The guns are typically aligned with an appeture mask or grille, which snaps the electron streams into place above their respective phosphors.
A black-and-white TV has only one type of phosphor, so it is not as important that the electron streams hit the correct, absolute position on the screen. The screen is uniformly coated, and I don't believe there is an appeture screen on these types of screens.
So, what happens when you hold a magnet to the screen? For one, you deflect the electron streams, so you get a temporarily distorted image, and the colors are off because the electron streams are pointing to the wrong phosphors. With B/W, it just doesn't matter; a phosphor is a phosphor.
Additionally, a powerful magnet can permanently distort or magnetize the metal appeture mask/grille, causing permanent damage the the screen's ability to align electron streams to the appropriate phosphors.
And that's it. I may have misspelled appeture. Oh well.
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?
Just to infoome people who may not know:
The file loads just fine in OpenOffice.
OpenOffice is available free (beer and speech) at OpenOffice.org for Windows, Linux, MAC OS X, FreeBSD and Solaris.
I'm sure Apple's Keynote works as well.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
Actually, Schneier points out that if you built a Dyson sphere around the sun to trap all its energy, it MIGHT be enough to cycle a counter through all (2**128) states before it implodes, if your high and low voltages were just barely distinguishable and you can do it fast enough.
Not that it's terribly useful. A 256-bit key would require that you perform the same feat (2**128) times-- which I doubt will happen.
Any encryption can still be broken through though brute force
<sigh> You know, I answered just this same question yesterday... </sigh>
As a thermodynamic minimum it takes 4.4 * 10**-26 joules to set a bit. (Well, it takes that much to erase one bit of information. But that's quibbling.) So multiply that by 256, for the number of bits in an AES key, and you get 1.1 * 10**-23 joules to store a key.
Now multiply this by 2**255, which is the number of AES keys you'd have to try to break it by brute force (on average). You get 6.4 * 10**53 joules of energy needed.
The total annual energy output of the Sun is on the order of 10**34 joules. Multiply that by 10**10 to compute the total energy release over the Sun's entire lifespan (yes, this is a nasty kludge of an estimate, I know the Sun's energy output varies) and you get 10**44 joules of energy.
Which means you've only exhausted one billionth of the damn keyspace.
No, you can't break any encryption through brute force. There just isn't enough energy in the universe to do it, even positing thermodynamically-perfect computers operating at 3.2K.
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.