My commentary on the slashdot memory error attack discussions.

• Overview :  I show that a single memory error can be used to get type system violation with a high probability. When we have a type system violation, you can write arbitrary code at arbitrary address. So you can use that to turn the security manager off.  It is important to note that the paper describes a version with no typecasts. This is an attack against static-checking.  Success in attacking dynamic checking depends on the exact implementation details. Since the program does not make any runtime type decisions etc. the runtime system may (and is expected to) optimise away all the type system code. Even in the worst case, it should be possible to mount someother attack with a good success probability.
  
• Heat : In the light bulb demonstration, the errors are due to plain heat and not because of photo-electric effect or something. Atleast, my motivation has been heat. In fact, I started using  a hair dryer to heat the memory chips, but found that to be clumsy. A goose-neck heat lamp and a voltage controller to control the intensity of the light is slick, and more importantly, the attack is more gentle. I don't want to flip too many bits and hence crash the virtual machine. An anecdote here.  IBM has a watch that runs Linux.  They noted that their watch crashes once in a while, and they traced it to bits flipping due to photo-electric effect! To save space they had avoided the plastic packaging on the chip. So the chip was exposed to light. They fixed the problem by putting a black paint on the chip.
• Java on smart cards : There are some serious businesses that use Java on a smartcard. IIRC, IBM has a smart card operating system written in Java!  On 13 March 2003, I had a conference call with 6 smart card developers wondering if the attack is applicable to their product. So, the people who make smart cards are interested in the attack. BTW, when I say a smart card, I do mean the smart cards that have a lot of tamper resistance built into them. Yes, there has been lot of smart card breaking going on. But then there is a growing smart card industry, the designers really care about attacks mounted by the owner of smart cards.  The scenarios people are thinking of are like a bank putting some money on the card and digital-signing it. Imagine the incentive the user has to break the card. While smart cards are rarely used in the United States, I believe that smart cards are much more common in Europe.  In smart cards, the user has access to the outside of the card, but not the internals.
  • NASA : [6 June 2003] I was pleasantly surprised when I got this enquiry from NASA, (Yes! National Air and Space Agency) : If the JavaCard disallows a loadable JavaCard applet from running, will this prevent the attack JavaCard applet from running? Or better stated, if the JavaCard requires a loadable JavaCard applet to be FIPS 140-2 validated and authenticated properly (by the NASA unique security domain model using Open Platform (Global Platform) 2.0.1) then the attack JavaCard applet will not be granted access to the JavaCard?
  • There have been enquiries from various other people or organisations too. So I believe the threat is real.
  • Java card software standard : A good introduction is here.
• India :  Now, when I heat the memory chip with a lamp and can get a memory error in about 1-2 minutes.  Now, in India, some places goto 50C in summer. Probably bits are already flipping in my homeland. Now, all I need to do to take over a good number of machines in India is to put this applet up on my webpage and wait for hits from India in summer.  Andrew, you should send me to India to test this hypothesis :-) Computers of a billion people are at stake.
• Physical access : Should I be concerned that some sunlight is falling on my machine and hence flipping bits?  Can someone take over my computer just because I visit their website while some sunlight falls on my machine? (Incidentally, as I type this sentence, sunlight is falling on my laptop.) Should my department be concerned that someone may beam some infrared beam through the glass wall onto our server computers?  So, I don't really need physical access.   Also, what I need is a computer that is not 100% reliable.
• Heat sinks :  What if I have bad heat sink on my machine?  What if the air conditioner fails?  I remember Matt Blaze telling me that once his machine actually crashed due to heat, after complaining about heat in the dmesg logs. Apparently, he closed his room,  started his machine, started the air conditioner (later realising that the duct was blocked, thus the conditioner acted as a heat source) and left for Australia for 10 days.   
• ECC/parity memory :  ECC/parity  memory is typically not used in a desktop. The dell inspiron 8200 laptop  i am typing this on does not have ECC memory. Servers should have ECC. Also, some vendors (Walmart) sell cheap PCs.  They would be under a lot of price pressure, and it may be easier for them to put second grade memory. Anyway, OS/software crashes are pretty common and hence users blame the software and not hardware.  
• Palladium/TCPA:  What if the bits flip in the code that implements the TCPA stuff? I guess the attack may be useful there. I must do more study though.
• Precision of heating : It is not important to flip a targeted/specific bit in memory. If you can target specific memory, all u need to do is to flip a specific bit {corresponding to condition if (hash(password)==xxx)to get root access}.  So far, I use  the lamp to heat the chips randomly.  I have no idea of physically where the errors actually show up.  Sometimes, my machine crashes due to this. The next time I give  demo, I plan to use a laser pointer or something so that I heat a particular chip and thus my tests are more deterministic. Ideas are welcome! Thankfully, so far, the OS/HDD crashes have been minimal.
• System crash :  System (kernel) crashes are surprisingly very rare.  I ran controlled experiments where in each trial I flip a bit and see what happens.  Out of about 3000 trials, the OS/JVM crashed only 45 times.  There were 998 times we I was successful, and 355 times the bits in pointer flipped, but in extreme low/high order bits and hence the JVM crashed. Actually, foolishly, I ran this on my desktop. As a result sound no longer works on my machine and I had to reinstall the OS.
• What if flip bits on HDD :  In the initial phases, I did flip bits in the RAM, which finally got written to HDD and the OS used to crash. So for the demo, I run the OS from a CDROM.  I managed to build a bootable Linux cdrom with my file system. Finally I put the attack applet on a floppy so that it is easy for me change the applet. I expect to give a demo on 13 may 2003 at Oakland Security Conference . Feel free to drop by!
• Denial-of-service aspects : The applet takes huge memory.  So the performance degradation is apparent. The attack is useful if people want to run Java applet screen savers. Or SETI@HOME written in Java.  In both cases, you just wait for an error to occur.
• Portability :  The attack has been tested on IBM and Sun JVMs. I wrote the applet for IBM JVM.  One fine day, I and Andrew realised that the attack should now work on all JVMs. So I ran the applet using Sun JVM and it worked the first time!  I just needed to change the value of the field offset of the integer in the "A" class. This is a parameter that varies from JVM to JVM.  Writing a similar attack for .NET should be trivial. You just need to rewrite my Java code to .NET and it _should_ work.
• Single Event Upsets :  Aerospace community is concerned about bit flips due to cosmic rays, and they are referred to as "Single Event Upsets".
• Xbox : I dunno how to crack an Xbox. I never examined it
• Randomness of my attack : In my attack, I don't care where the errors occur.  I do not make an attempt to flip a targeted/specific bit.
• Fun : I once beamed light on my laptop, while I was half asleep. This is what resulted.  Anyway, the hardware on the laptop works great. I just had to get another memory door for the laptop.
• Experiment CD : I know that you are longing to do the experiment.  It is really simple.  I can give you a copy of the CD and the attack applet. Ofcourse, the heat bulbs are yours. Send me a mail if you are interested. If you want to flip using software, rather than hardware, that can be done too! I have the scripts.
• Slashdot losing its Linux bias? : Isn't it ground breaking that a ppt file got posted to slashdot?  /. editors, wake up!
• Are memory errors often ? : Firstly, reliable data for current chips is hard to come by. To me, it looks like you can expect 1 error per month on a typical desktop machine. It does not matter where the errors occur. The errors can even be in the bus and the processor. Bus speeds are increasing. David Patterson believes that with ever increasing bus speeds, bus errors are going to be an increasing concern. Also, chip voltages are going down and clock freq. are increasing. So the probability of errors in the processor chips is raising. No wonder that Intel is trying to develop soft-error tolerant technologies. The other day I met an expert at Intel who works on recovering a processor from a soft error. He was concerned after seeing my demonstration with the light bulb. (Thankfully for me, the demo worked first time!) He believes that soft errors are going to be a reality 5-10 years from now.  Intel now better put more focus on containing these errors! Hardware reliability  is 100% important.
  
• Demo at Oakland Conference : On May 13th, I demonstrated this attack in the "Oakland Security Conference". There, I shined light on a desktop machine to flip bits in the memory and to take over the virtual machine.
• Disclaimer on smart cards : [9 June 2003] The attack should theoretically work for certain smart cards too. I did not actually implement the attack though. The demo at "Oakland Security Conference" was on a desktop machine.
• The description in some of the media about my research falls in the grey area between trush and fantassy. My attack surely works on desktops with physical access. However, I am not entirely sure about smart cards.  My demo at the conference was on a desktop machine.  I am yet to implement the attack on a smart card. Having said that, I do think that the possibility of an attack on a smart is real.  People who care about security are concerned too.  For example, the other day I had some folks from NASA call me to discuss the possibility of an attack on their smart card.