[OLPC Security] Securing the laptop: DoS

[MBurns]

Hi Carl-Daniel,

Let me do my best to respond to a couple of these points. You've raised some
good ones.

On 9/7/06, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
> 1. Power management
> - Current plans focus on hardware and software ability to conserve
>   power so that children have a reasonable chance of keeping the
>   laptop powered for ten times longer than it needs to be charged
>   (by physical effort on part of the children and/or other charging
>   methods).
> ! An attacker might look for ways to drain the battery faster than
>   expected to reduce the use/charge ratio. Examples:
>   * Run javascript endless loops in the browser
>   * Abuse the fact that certain (D)HTML constructs are extremely
>     cpu-intensive in the default browser
>   * Force automatical reload of a render-heavy local web page with
>     maximum reload rate
>   * Use browser plugins (flash/gnash etc.) to escape detection of
>     any of the above points


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


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

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

2. Network DoS
> - Wireless firmware development so far seems to be focused on getting
>   mesh routing and other nifty features to work nicely. That's great.
> ! Wireless uses a shared medium (that's bad enough in itself, though
>   not fixable) and additionally can suffer from the exposed/hidden
>   station problems (there are ways around that, though). This creates
>   the following problems:
>   * Any node can completely block wireless communication of all other
>     nodes in its range (subject to all sharing the same channel), and
>     that's the best case
>   * Not only will communication between any two nodes in the range of
>     the evil node be blocked, but communication from inside the range
>     with nodes outside of the range is equally impossible
>   * Assuming that nodes outside of the evil range are trying to reach
>     nodes inside the range and the outside nodes retry sending packets
>     regularly, congestion will happen in an area up to three times
>     the range of the evil node


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.

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

  * If broadcast/multicast is relayed over the mesh, equally bad things
>     can happen


The standard discovery method for wireless mesh networks is to do a
controlled broadcast, of sorts. I'm interested to hear why multicast on this
type of network would necessarily bad.


I hope this answered some of your questions. As mentionedm any of the
problems of standard laptops being deployed in mass are going to be
significantly reduced because of the control over signing application to run
or not. I'm looking forward to your thoughts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.laptop.org/pipermail/security/attachments/20060908/2890a366/attachment.html