Re: Circumventing kernel signing
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@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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Circumventing kernel signing
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. 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@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Circumventing kernel signing
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. -- Mix a little foolishness with your serious plans; it's lovely to be silly at the right moment. -- Horace ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Circumventing kernel signing
Bernardo Innocenti wrote: > John Richard Moser wrote: > >> VECTOR 1: kexec() >> [...] >> VECTOR 2: unsigned module >> [...] > > Unless we disable things such as /dev/mem, I also see a much > wider attack vector, where one can inject arbitrary code in > the kernel and recreate the conditions of these. And there > are many alternative strategies based on commonly available > interfaces. > Thank you for seeing that one. grsecurity has code to resist this type of attack (allows writing to /dev/mem in video memory range, but nowhere else); I don't know how else to do it. > Some people seem to believe that one can give root access to > a system and at the same time keep it locked down. While this > seems possible in theory, I'm still waiting to see a practical > implementation that resists Random J. Hacker while preserving > the user's and application's expectations of what root can > normally do. > 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. -- 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Circumventing kernel signing
John Richard Moser wrote: > VECTOR 1: kexec() > [...] > VECTOR 2: unsigned module > [...] Unless we disable things such as /dev/mem, I also see a much wider attack vector, where one can inject arbitrary code in the kernel and recreate the conditions of these. And there are many alternative strategies based on commonly available interfaces. Some people seem to believe that one can give root access to a system and at the same time keep it locked down. While this seems possible in theory, I'm still waiting to see a practical implementation that resists Random J. Hacker while preserving the user's and application's expectations of what root can normally do. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Circumventing kernel signing
So far I have come up with two untested, theoretical ways to circumvent the kernel signing mechanism and boot an unsigned kernel. These are both dead simple so I'll keep the explanation short. Both require an activation key, neither require a developer's key; in other words, if you can boot normally, you can do this. First, here is how I understand the current boot process. Open Firmware -> Load kernel -> Check digital signature on kernel -> Bail if invalid/missing -> Execute kernel -> Check for activation key -> Bail if invalid/missing -> Execute init After this point, we're done with checks. Beyond here the laptop's owner has root access, but can't really replace the kernel. This exercise only addresses replacing the kernel; I do not attempt to address replacing the base system or running unsigned applications. My two attack vectors are kexec() and unsigned module based; the unsigned module method just suggests that it's possible to rewrite kexec() as a module, possibly an ugly one but it's doable nonetheless. The solutions to these are simple as well: * kexec() * CONFIG_KEXEC=n * OR add code in kexec() to check for a signed kernel * Module rewrite of kexec() * Sign modules and boot with 'enforcemodulesig' Beyond this point is fluff. It's what I just said, but with bigger words. VECTOR 1: kexec() Open Firmware -> Load kernel -> Check digital signature on kernel -> Bail if invalid/missing -> Execute kernel -> Check for activation key -> Bail if invalid/missing -> Execute init -> S00bootkernel -> kexec -l vmlinuz --command-line=nos00 -> kexec -e -> Execute kernel ~# cat /boot/config* | grep "CONFIG_KEXEC" CONFIG_KEXEC=y A user could load a copy of the kexec binary for i486 onto the system, and execute a new kernel. Further, the user could replace the entire system but keep the AK in /security/ and set up a S00bootkernel init script to load and execute a new kernel if the current version is the OLPC version. This would allow the user to boot a stripped-down Debian or Ubuntu Server system with their own custom built kernel, using the OLPC kernel as a boot loader; it would also realistically allow loading BSD or Minix or any other OS, if the OS could physically boot on the XO. VECTOR 2: unsigned module Open Firmware -> Load kernel -> Check digital signature on kernel -> Bail if invalid/missing -> Execute kernel -> Check for activation key -> Bail if invalid/missing -> Execute init -> S00bootkernel -> modprobe my-hacked-kexec-module -> kexec -l vmlinuz --command-line=nos00 -> kexec -e -> Execute kernel As far as I can tell, OLPC does not sign modules. Fedora and RHEL use signed modules and will refuse to load unsigned or invalidly signed modules if the kernel gets the "enforcemodulesig" command line parameter. kexec() is not black magic and can be forced in as a module. It just has to modify the syscall() table and take over the world (i.e. freeze every other process in the kernel, abduct the scheduler). Someone would have to possibly rewrite kexec() in an ugly way, but it could be done. Aside from needing a little more programming skill or a modularized kexec() implementation, this is the same attack vector as Vector 1. -- 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
