[OLPC Security] Securing the laptop: DoS

Jim Gettys jg at laptop.org
Mon Sep 11 09:54:44 EDT 2006


On Sun, 2006-09-10 at 14:51 -0400, Simson Garfinkel wrote:
> Carl-Daniel,
> 
> Thank you for this message. I'm in the process of preparing a few  
> security documents and will be addressing some of these issues. In  
> general, you do a good job outlining some of the threats that we've  
> been considering. However, what you haven't done is given me a threat  
> model --- who do you see launching these threats, and on what scale?
> 
> 1. Attacks on the battery appear to be unsolvable. How would you  
> address them?

Kids are also pretty smart; and we'll be making power use information as
available as we can.

Also, a lot of the power management on battery won't be "automatic", but
driven by the kid's input activity, rather than the execution of
applications.  Right now, there are way too many Linux apps waking up at
random times and suspend/resume too slow to think about doing it in a
way that allows for more automatic behavior.
> 
> 2. Our primary concern regarding writes to the NAND flash have to do  
> with flash lifetime, rather than using writes as a way of draining  
> batteries.
> 
> 	You write:
> 
> >   * Opening a file and running a {modify, fsync} endless loop on it
> >     should be able to kill the flash chip in minutes
> 
> Are you sure about your calculation here?  My experience with flash  
> tells me that we are unlikely to get write speeds faster than 1  
> megabyte/second. 

NAND flash is much faster for write than NOR flash is.

I don't know yet exactly how fast we'll be, as while we have Cafe's NAND
controller running, it isn't yet taking advantage of what the controller
will do.

> If the flash is 512MB, and if we have 100,000  
> rewrites for every page, then it will take 512 seconds to do a  
> complete write, or 100,000 * 512 = 50 million seconds to fail the  
> flash (assuming we are going through JFFS2).  10x the bandwidth to  
> the flash would give us a failure in 5 million seconds, which is  
> still roughly 2 months. Since full-speed writing to the flash would  
> make the machine completely unresponsive, and since the machine would  
> need to be constantly charged, I'm not sure that this is a realistic  
> threat.
> 
> If the attack software has root, then it could bypass JFFS2 and just  
> rewrite critical sectors repeatedly. Now the threat is more realistic  
> --- assuming 1 megabyte/second write speed, a single 4k page could  
> now be rewritten 256 times a second. So now we might be able to get  
> it to fail in a little more than 5 minutes.
> 
> I'm not sure how JFFS2 would handle the failure of key pages here or  
> there, but overwriting the partition table would probably be pretty  
> bad. We've been discussing using some kind of security system so that  
> even processes running as root cannot do raw writes to the flash.  
> These brief calculations indicate that this is needed.

Dave can enlighten.

> 
> 3. Regarding DoS in a wireless environment: Are you worried about a  
> single malicious laptop user, or a worm that propagates and tries to  
> DoS a community or country? Since we are using 2.4Ghz unlicensed  
> technology, we can't prevent a small-scale DoS attack: microwave  
> ovens, illegal 802.11 amplifiers, cordless phones, and even  
> communications equipment operated by some governments all present  
> threats to wireless connectivity.
> 
> 	If you are worried about a large-scale worm doing a DoS attack ---  
> well, there are a lot of things that a worm could do, and running a  
> wireless DoS is just one of them. We need to start attacking this  
> problem by minimizing the opportunities for worms in general.
> 
> 4. Regarding malicious firmware to the wireless chip: Yep, this is a  
> problem. My understanding is that we will not have source code to the  
> wireless firmware. How do you think this should be resolved?
> 
> 5. Power management:
> 
> 	You wrote:
> >   * Switching on/off components can result in electic transients
> >     which have (with the right timing) the ability to kill a power
> >     supply or voltage regulating circuits (I remember exploding
> >     capacitors around 1996 when malicious code sent the Pentium
> >     processor to sleep and back in rapid succession)
> 
> I'd love to get a reference to this, as I never heard of it and I  
> would like to use this information in an upcoming presentation.
> 
> Also, if this was a problem in 1996, why is it no longer a problem  
> today?
> 
> 6. BIOS Flashing.
> 
> You wrote:
> > ! Not sure whether LinuxBIOS should really mount the NAND flash
> >   before disabling BIOS flashing
> >   * If someone figures out a way to exploit JFFS2, he would be able
> >     to circumvent all BIOS flashing checks because we mount JFFS2
> >     on the NAND flash to look for BIOS updates while BIOS write is
> >     still enabled
> 
> One alternative is to have a pre-allocated section of the NAND flash  
> that is only used for this purpose. Another alternative, I guess, is  
> to put the BIOS update in RAM and do a reboot that doesn't wipe out  
> the RAM. (I'm assuming that it would be easier for the Linux bios to  
> look for a digitally-signed file in RAM than to load up JFFS2 and  
> risk that exploit.) Do you think that such an approach is warranted?
> 
> We see to be depending awfully hard on JFFS2. On the other hand, file  
> systems are pretty well-defined creatures. Are you familiar with  
> model checking technology? Do you think that it is worth while to do  
> some model checking on the JFFS2 implementation and try to find bugs  
> and possible exploits in it?

JFFS2 is clearly our generation 1 file system; not clear what we will
use for gen 2.

> 
> _______________________________________________
> Security mailing list
> Security at laptop.org
> http://mailman.laptop.org/mailman/listinfo/security
-- 
Jim Gettys
One Laptop Per Child




More information about the Security mailing list