[OLPC Security] Securing the laptop: DoS

[Simson Garfinkel]

On Oct 7, 2006, at 11:17 PM, John Moser wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Simson L. Garfinkel wrote:
>> This is pretty easy to defeat: just bust the cache so that the system
>> doesn't know the difference between data that's going to be  
>> overwritten
>> and data that isn't.
>
> The wha?  How do you do that?  The system should keep track of a  
> number
> of things (I'm assuming neither that this is nor is not how cache  
> works;
> I don't really know.  These properties just make sense to me):
>
>  - Individual files.  These are having data changed; data being  
> changed
>    in the same spot in the same file should be overwritten in memory
>    until written back to disk.  You can even allocate space-- or  
> decide
>    where allocations go, but not actually write that to disk.
>
>  - Files being deleted.  If you write to a file 300 times, then delete
>    it, don't write those writes to disk.  If you create a file, delete
>    it, create it again, delete it... only write the final set of files
>    still alive back to disk in the end.
>
>  - Meta-data.  If you update atime, size, etc, keep that information,
>    update it each time in memory, sync it back when appropriate.

What if the malware creates 1000 files, each one 256K in size, then  
starts to delete the files from the beginning? By the time the  
malware has gotten to the end of the first 1000 files, they have been  
flushed from the cache to memory. The system just doesn't have enough  
buffer, if you assume that the flash is bigger than RAM. If the flash  
is smaller than RAM, then this isn't a problem.



>
> My thinking is that to beat this, you have to create a very big  
> file or
> a large set of files, and write over them in a bunch of different  
> places
> a lot, to scatter writes in different sectors so that the NAND has to
> erase/program those sectors.  You won't fill the cache with dirty just
> by writing to the same place a lot of times.

If you write in the same place, JFFS2 spreads it out to different  
places. So it doesn't matter if you are writing to the same file or  
writing to different files; JFFS2 makes all of the sectors age together.

>
> Essentially, if there's room for 60 megs of cache, you have to  
> write 60
> megs of data minus whatever else is legitimately cached and likely to
> stay there through the attack.  While the system is writing cache back
> to disk, the attacking program is probably going to be blocked by
> write(), because the kernel has nowhere to put the extra data.
>
>> Hell, use a PNG so that the system can't tell the difference.
>
> PNG??  Image?  Can't tell the difference between what and what?

Pseudorandom Number Generator. The system can't tell the difference  
between random user data and malicious program data.




-------------- 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/20061007/05580926/smime.bin