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!"

This just in!

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.

Re:This just in!

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.

Re:This just in!

If somebody intent on breaking through the smart card's security has access to the smart card, then sooner or later the security WILL be broken.

Get a clue. The whole point of a smart card is to keep the data safe even in the event of physical tampering. For this purpose, the processor of a smart card is enclosed in a black box which will chemically self-destruct if you try to tamper with it. Much research on smart cards goes into ensuring that security can not be broken in spite of physical access.

Some pointers:

• Smart card FAQ [nist.gov]
• Design principles for tamper resistant smart card processors [nec.com]
• Low cost attacks on tamper resistant smart card devices [nec.com]

Brute force

Any encryption can still be broken through though brute force.

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.

Re:This just in!

Any encryption can still be broken through though brute force.

This is simply not true. One-time pads are 100% unbreakable, and they will always be unbreakable (at least mathematically speaking), no matter how sophisticated technology gets in the future. For those who are unfamiliar with the concept, a one-time pad is a cryptographically random string of 1's and 0's, which is at least of the same length of the message itself. Two parties have a secure channel in which to exchange these pads; for example, if Alice and Bob wish to use one-time pads, Alice can generate a list of 10,000 cryptographically random strings, put them in a suitcase that is handcuffed to her wrist, and deliver them to Bob in person. Bob and Alice then have a set of one-time pads that they can use for all future communication. Each time they encrypt a message with one of the pads, they discard the pad and never use it again. Because the pad is at least the length of any messages they might pass back and forth, there is no way to analyze the encrypted message for patterns. It is mathematically impossible. You could easily come up strings of 1's and 0's that would ``decrypt'' the message into anything, be it passages from the Bible, or Ogg Vorbis encoded music. You would have no idea which set of 1's and 0's produced the actual original message. This is truly unbreakable encryption on a mathematical level.

Most companies claiming that their encryption is ``unbreakable'' are using one-time pads; the problem is reduced to finding a secure channel of communications in which to transmit those pads. This is usually not a feasible assumption, which is why we all prefer using, for example, Diffie-Hellman key exchange, which depends on the difficulty of math involving discrete logarithms. The encryption we now use is breakable, but it is hard enough to break that it is generally considered secure.

Re:This just in!

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.

Re:This just in!

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.. [ibm.com] of course, for it to be useful, you need it protected against key recovery attacks. [slashdot.org]

Re:This just in!

"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."

I would imagine that nasty EMI spikes you may couple to the inside of the box, or medical radioactive sources would work too.

Just a guess, but I have sure had my share of EMI and radiation induced problems.

Re:This just in!

Well, there are already many error-induction attacks agains smart cards (some references in the article), that don't involve JVM running untrusted code.

So if I can break smart card event if is does not run any my [untrusted] code, who cares about attack to smart card that allows to run untrusted code? Besides, I've never seen any smartcard that actually does this stupid thing.

A better target for attack may be a server at a nuclear reactor facility that has natural high rate of memory failures :)

Re:This just in!

Page 7, Paragraph 3:

"To attack machines without physical access, the attacker can rely on natural memory errors."

This paper showed some means an attacker could physically cause a memory error, but it never said that such intervention was required to stage the attack. My guess is that this would be most useful with those "low load" ram chips that ran on slashdot a while back.

This attack doesn't look very effective

The pie chart in the article suggests that the exploit can only take place about 30% of the time the attack is used. It is more likely that the memory error will go undetected by the hack. If the attack can be tried again, and again, and again, I suppose it would work.

Re:This attack doesn't look very effective

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.

seriously

Funny to see this here -- I (and Sun) know all too well about this phenomenon, but I am bound to relative secrecy by NDA.

So, I can't share my team's research results that clearly show that this is a bigger problem than most raders probably realize. Nor can I share the steps (advanced ECC, logic-BIST, etc) we're taking to prevent this before it gets well-known enough to be a problem.

But I can say: this is indeed a scoop, way to go ./!

Secrecy my arse.

It's been known for a *very, very* long time that semiconductors are light sensitive. It's been known for a reasonably long time that the tiny capacitors that make up dynamic RAM are very sensitive to light. In fact, there was a project in Byte magazine in the late 1970s that used a 4116 DRAM chip with the top cut off as a black-and-white CCD camera. It worked remarkably well.

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?

the implications!!

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!

Rather useless because of a few points

If we have physical access or full system access why not just change the JVM code letting us do whatever we want? and if u just wanna stop it and you have full privildges why not just shut the system down? and if we got physical access why not just pull the power plug? This would be usefull if it didn't need full access or physical access.

A quick workaround...

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. :-)

*.ppt

Ahhh....... Power Point How I Hate it.....

Open office did a decent job on it though

Re:*.ppt

A non-animated PDF version here [documents.cern.ch].

Link is valid for 7 days :-)

End of Slashdot

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.

Re:End of Slashdot

They actually posted a *link* to a *PowerPoint* document in a Slashdot article! Worse yet, no one seems concerned.

Noone reads the articles, so they probably didn't even notice. OK, *I* didn't notice.

Re:End of Slashdot

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.

New nifty trick for a hacker book

You wouldn't necessarily need physical access to the machine itself. It might be possible to perform this exploit by gaining access to a machine's air conditioning unit and disabling it at an inconvenient time. That could raise heat enough to cause RAM performance to degrade and make the success of the exploit more likely.

If the air conditioner went out at midnight, most system administrators wouldn't know until the morning.

I'm reminded of Knuth's quote

"Beware of bugs in the above code; I have only proved it correct, not tried it."

Apparently, the security of the JVM type system has been subject to machine-checked proofs. Yet, a single bit error in memory can be exploited with 70% probability.

Scientific paper

looks like it was written in crayon (well the titles at least)!

This just in...

...you can fuck up a monitor with a big ass magnet!

(There are some things you just never forget from your high school physics lab)

Re:This just in...

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.

In other news.

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'.

best line from the article

Fortunately for the attacker, few users are surprised these days when applications use hundreds of megabytes to accomplish trivial tasks.

More elegant way to break a VM

Anybody remember the User Mode Linux [securiteam.com] 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.

viva las vegas

If you can manage to sneak an Xray thing in your keychain. If you know where a slot machine's memory is.

Yes no problem...

we just ask the little monkeys inside the memory chip who are in charge of steering the data to guide our thermal rays to just the right CMOS gates used by the JVM process so as not to crash the computer... Real practical exploit NOT.

Make clip on lamps illegal

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....

Next Spy Gadget?

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 Computer Cases

"New LEAD cases from lian li to protect your system from intuders" Just another thing to worry about when it comes to security.

Alex descends into hell for a bottle of milk

How many websites would have an article that begins:
"A very cool scientific paper..."

Oh dear, we really are geeks, aren't we.

a side note about developement of ecc

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.

More likely a system crash would occur

The idea of blasting the memory (or any other component) with 'cosmic rays' would more likely result in a system crash. It's not possible to flip a targetted/specific bit in memory....more likely you would corrupt something in kernel resulting in a crash/oops/panic/etc...

This attack doesn't sound very useful....though does make an interesting paper.

Hundreds of megabytes

From the article:

Because the attack requires very large amounts of memory to operate efficiently, the application in which it's hidden would itself have to be a memory hog. Fortunately for the attacker, few users these days are surprised when applications use hundreds of megabytes to accomplish trivial tasks.

Makes you think about ICQ, doesn't it?

Atari 2600 & a screwdriver...

Reminds me when I was bored, and decided to take a look at the inside of a new (at the time) Atari 2600.

Even at that age, I knew the system wasn't too complex...one chip-per-game, less than a couple dozen pins teasingly poking out the back. Hmmmm...about the width of a screwdriver. TV connected, power on, and screwdriver in hand, in went my Adventure game cartridge. Pin 1+2, garbage, reset. Pin 2+3, more garbage, reset. Pin 3+4...hmmm. After a while, I moved on to short pieces of wire.

Some pin combinations made the walls dissapear, dragons flicker (and become harmless). Others rearranged the contents of the rooms and/or where the exits went to.

The exploit described in the article is similar. If you have a focused enough energy disruption I'd expect you would get some odd results in almost any electronics. If you make secure devices, this is one more thing to design for.

ECC for making machines .... **cheaper** !

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. :-)

Powerpoint???

Sorry. My browser does not render powerpoint.

Excellent Smithers!!!

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!

In the lab today, in the wild tomorrow...

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 [straightdope.com].

Article in short

The article says that if you can get close enough to zap a box with xrays and simultaneously get the box to let your Java code use 60% of the memory and if the machine does not hang then you have a 70% chance of getting root. And the RAM has to be non ECC RAM.
Looks like all xSeries servers from IBM and Dell(Power Edges) and HP ship only with ECC RAM , and ECC errors are actually logged by software.
So forget walking into Las Vegas Casinos with a Xray machine.

Even submitters don't read the article

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!

palladium

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.

Nothing new in the article...

Let me conclude from reading the article:
-Memory errors can allow a system running a virtual machine to be compromised/corrupted
-Such memory errors are most likely to occur when an attacker has physical access to the machine
-One way to make it less likely, is to use error correction (ECC) on the memory.

Rewritten:
-If a computer's memory is not 100% reliable, you can't fully trust software running on it, to perform as expected
-Physical access to a machine gives an attacker more chance of compromising it
-Having error correction enabled, would make a system more reliable.

So what's new here? Nothing.
I have to give the researchers credit though, for the nice way they worked out how to exploit such hardware errors.

Neons

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.

Know what is really scary?

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?

google ppt cache render...

For those who don't do PPT or PDF.. I threw this through google http://216.239.39.100/search?q=cache:YV5cbDGeKscC: www.cs.princeton.edu/~sudhakar/papers/memerr.pdf&h l=en&ie=UTF-8 I think that is the same presentation. It renders like crap, but you can atleast read it...

-- AcquaCow

NASA has been researching this for a long time

Aerospace researchers have been investigating the effects of different types of radiation on computers and other electronics for decades. Why would a virtual machine be any different, whether on a PC board, or on a smart card?

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!

I told you so!

The article uses OOP examples that tell how to hack around by having flipped bits change object pointers that allow you to "see" objects or object portions that you are not supposed to see. The simple solution is to not use OOP. I told you OOP was dangerous :-)

Cosmic Billies?

To
attack a computer to which he has no physical access, he
can convince it to run the program and then wait for a
cosmic ray (or other natural source) to induce a memory
error.

Cosmic Rays... are they like country singers [brcspirit.com] in space or something?

trusted bytecode

I've always thought that the JVM security model was the moral equivalent of eliminating the FDA in favour of tamper resistant pill bottles.

Tamper resistant packaging is a darn good idea. But it's not a good idea to be so impressed by the packaging that we forget that how easily well intentioned people can create combinations of carbon, hydrogen, and oxygen and a few choice flavour additives that kill.

Bottom line: no matter how much rocket science you pour into the packaging, you still have to ask hard questions before ingesting the contents into your body.

Unless you believe that large software companies have entirely different profit motives than large pharmaceuticals.

Author responds + PDF slides available

It was a pleasant surprise to see my paper on /. this morning. Now pdf slides are available here [princeton.edu]. My comments on the views shared here are also available [princeton.edu]. Sudhakar [princeton.edu].

Naturally occuring computer viri

Ever wonder how many naturally occuring computer viri are out there. With all these cosmic rays, overheated hardware, flakey harddrives and software bugs it would be amazing we haven't run into a little 512 byte virus, yet. Eventually, computers will become self aware :^)

One of the systems I worked on had checksums on the data ever point in the system. It was checked in hardware every time it crossed a bus or was stored. This improved the reliability considerably.

-Happy

I don't know if anyone bothered to read the paper,

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.

OH MY GOD!!

Why were we wasting all our time on buffer overflows and cryptography, when the real threat all along has been...

COSMIC RAYS!!

Java vulnerable, through C!

I watched the power-point, because I was really curious how to provide this exploit. Looking at his example, I was really curious when I saw his Java code contained the line "for each pointer p of type A"... Pointer? You don't have direct access to pointers. What is he doing?

Watch further and it all makes sense. He said that Java is vulnerable to these memory errors, and that you can prove it by adding some non-Java code. Well, no S*&t! Has anyone ever doubted that you can do whatever the hell you want from C or ASM?

If you are really worried about it, disable JNI. Not only is it an optional package, but you can force it to always be disabled in the Security Manager.

As a side comment, if you are going to post a nice exploit of Java, please write it in Java.

Malachi

Static electricity

A long time ago, when I worked at a restaurant as a teenager, I saw an employee that was screwing around with an ion ray gun [plans-kits.com] accidentally open a secure time-lock safe. He simply pointed it at the safe from a few inches away and the safe's electronic display started blinking and it just opened.