Circumventing kernel signing

John Richard Moser nigelenki at comcast.net
Thu Jan 3 09:29:13 EST 2008



Mitch Bradley wrote:
> At some point, when these fairly obvious loopholes that we have known 
> about since forever are closed, we plan to change the key so new 
> machines will only run the more secure OS versions.  Old machines will 
> continue to be vulnerable until they are upgraded to new firmware with 
> the new key, and some old machine may always be vulnerable.
> 
> Meanwhile, I reiterate my earlier claim that a no-modules kernel will be 
> easier to secure.  Even if you require signed modules, the extra 
> complexity creates attack opportunities.  Each additional door is a 
> ingress opportunity.
> 

Anything you build into the kernel similarly increases attack 
opportunity.  For example, an IPv6 and IPv4 kernel and the networking 
infrastructure.  You might load IPv6 to support a 6bone network, and 
load net; then find there's an IPv4 stack bug and you can kill iptables 
and get a kernel level exploit.  Not vulnerable, of course, since you're 
running IPv6 and not IPv4.  Of course, with everything built in, you 
have IPv6 and IPv4 all the time, and a worm can use IPv6 to spread to 
its nearest neighbor and then crawl out from there even if there's no 
real routing.

This is an absurd claim, I know (though Linux has had an IPv4 flaw, and 
OpenBSD has had an IPv6 remote exploit); but claiming module loading 
itself provides an attack opportunity is just as absurd if not moreso 
when dealing with signed modules.  Your most likely attack opportunity 
is by far a flawed hashing algorithm or implementation; it's likely the 
same algorithm as in OFW, possibly implemented off the same reference 
code, and the attack for it (generating a collision by tweaking a 
modified binary) is going to work either way.

So in short, yes, even with signed modules you still have module loading 
itself to wonder about; but the potential attack opportunity here is as 
absurdly small as finding a way to alter PGP signed messages (which was 
done once; implementation flaw in how GPG checks signatures, allowing an 
attacker to append unsigned content to a signed message while GPG 
reported the whole message as signed).

> Asheesh Laroia wrote:
>> On Thu, 3 Jan 2008, John Richard Moser wrote:
>>
>>   
>>> I did not address the mass of other crap you could do to the system with
>>> root.  I was only addressing evading the OFW security implementation for
>>> only booting signed OSes.
>>>     
>> Here's another vector:
>>
>> 1. On a laptop that comes from the factory with the above security holes 
>> fixed, install a current (as of Jan 2 2008) signed release (which is 
>> signed with the same key, and therefore okay according to the XO)
>>
>> 2. Notice that it has (at least) the security holes described in this 
>> thread.
>>
>> 3. kexec or modprobe your way to a different OS!
>>
>> (4. Profit!)
>>
>> -- Asheesh.
>>
>>   
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
> 

-- 
Bring back the Firefox plushy!
http://digg.com/linux_unix/Is_the_Firefox_plush_gone_for_good
https://bugzilla.mozilla.org/show_bug.cgi?id=322367



More information about the Devel mailing list