[OLPC Security] Securing the laptop: DoS

[Simson Garfinkel]

Minor comments below:

On Sep 8, 2006, at 10:02 AM, MBurns wrote:

> Malicious websites could very well be a problem. However, children  
> are pretty smart, and I believe they would make the connection to a  
> particular site being open, and degraded performance. Maybe we can  
> tune our browser to block some scripts (I am a big fan of NoScript  
> plugin for firefox).

Children are pretty smart, but I don't think that most children in  
our target market will be able to make the connection between a site  
being open and degraded performance. My 10-year-old daughter would be  
unable to make that connection, for example.

Our real hope here is that most of the computation is going to be  
done on the machines, not on the net, as internet bandwidth is going  
to be more limited than computational resources.

Also, websites don't need to be malicious to drain your battery. Any  
website with good flash animations will suffice.


>
>   * Offer applications for download which keep the CPU busy (you get
>     the pattern...)
>   * Offer applications which keep the connection to the DCON busy
>
> AFAIK, applications can only be ran/installed if they are  
> cryptographically signed by a pre-approved key, that is saved on  
> the BIOS chip. Having this in use should essentially eliminate  
> third-parties from spreading malicious programs. This does not,  
> however, stop a user from writing/running *his own* software.

Incorrect. We're only considering mandatory crypto signing with a pre- 
approved key for the BIOS itself, not for applications. One of the  
proposals that I'm making is that all code must be signed, but it's  
going to be pretty easy to add a new key to your keystore. (In fact,  
it may even be automatic.)

>
>   * USB access/polling/scanning also can use a lot of power
>   * Wireless also uses more power if transmitting continuously,
>     so applications might flood the network in order to keep the
>     transmitter busy
>   * Writes to NAND flash also require some power...
>
> This is something that needs to be worried about. There was a post  
> to the Networking@ list that talked about the possibility of nodes  
> intelligently turning off their forwarder/router capabilities, in  
> dense networks that don't significantly benefit from them. As an  
> extension of that, a rudimentary packetshaper may or may not be out  
> of the question. If only signed programs are being allowed to run,  
> the fear of malicious code execution is signicifantly lower, but I  
> am a fan of having multiple layers of security.

Actually, only allowing signed code to run doesn't really take care  
of the malicious code execution problem. That's because most systems  
verify the signatures when a program is started, not when it is  
running. As a result, buffer-overflows and other code-injection  
attacks circumvent signature checks.

I want signed code for author attribution and identity management,  
but not because it will significantly lower the risk of worms. We've  
seen plenty of exploits for signed programs in the wild.

> This is the problem my mind has been chewing on for the last 2  
> days. How do you work around the limitations of a single shared  
> media/channel (where you essentially have a hub, where only 1 node  
> can talk at any given moment). My thoughts ranged from Bluetooth- 
> esque channel hopping, to dual antennae, that let 2 channels to be  
> listened to simultaneously. But part of this is a social problem.  
> If a rogue laptop (not necessarily an OLPC-branded one) is  
> transmitting rogue gibberish to flood the radio waves, they are  
> roughly within 300 feet of you. Dealing with them directly, or  
> getting up and moving are both practical solutions.

Two comments here:

1 - The problem that you describe in the first part of your paragraph  
is called the "hidden node" problem. Hidden nodes that can't see  
everyone sort of look like noise.

2 - The problem that you are discussing in the second part of your  
paragraph is why we use a spread-spectrum technology with exponential  
back-off. Direct Sequence spread spectrum isn't nearly as robust as  
frequency hopping spread spectrum, but it does work even in the face  
of channel noise.  It works with degraded performance, but it does work.

>
> ! Now if the attacker has some intelligence and is not only jamming
>   the radion channel as stated above, it gets worse:
>   * Pushing data over the mesh to some distant node reachable only
>     via at least a dozen hops should keep traffic high in all of the
>     traversed cells
>
> This gets back to rogue OLPCs. It is unclear how difficult a  
> standard Dell laptop would be in joining the mesh network. Again,  
> the possibility of packet shaping. Routing nodes should be smart  
> enough, knowing their limited bandwidth, to throttle back some  
> connections if others are suffering. Maybe someone else can comment  
> on how practical this will be.

I don't think that it will be difficult for a standard Dell laptop to  
join the mesh if the laptop has a wireless chip that implements the  
same 802.whatever standard for mesh networking that we are using. I'm  
hoping for some kind of endpoint identification system, though, so  
that the schools don't give Internet access to these Dell laptops  
(unless the schools choose to).




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2413 bytes
Desc: not available
Url : http://mailman.laptop.org/pipermail/security/attachments/20060910/d135a3f1/smime.bin