Linux CAP_SYS_ADMIN to root exploit 2

I've released my first Linux kernel exploit.

Guide to Compiling Custom Kernel Modules in Android

I've spent the better part of today trying to figure out how to compile and load a custom kernel modules in android to aid me in my research.  It has been in entirely frustrating experience, as there is almost no documentation on the topic that I can find.  Below you will find my attempt at a guide.  Hopefully this will help save someone else the hassle.

PREREQUISITES

Disclaimer:  This list may be incomplete, since I've not tried it on a fresh install. Please let me know if I've missed anything.

• Install the general android prereqs found here. 
• Download and un(zip|tar) the android NDK found here.
• Download and un(zip|tar) the android SDK found here.
• Download and untar the kernel source for your device.  This can usually be found on the website of your device manufacturer or by a quick Google search.
• Root your phone.  In order to run custom kernel modules, you must have a rooted phone.
• Plug your phone into your computer.

PREPARING YOUR KERNEL SOURCE

First we must retrieve and copy the kernel config from our device.

$ cd /path/to/android-sdk/tools
$ ./adk pull /proc/config.gz
$ gunzip ./config.gz
$ cp config /path/to/kernel/.config

Next we have to prepare our kernel source for our module.

$ cd /path/to/kernel
$ make ARCH=arm CROSS_COMPILE=/path/to/android-ndk/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin/arm-eabi- modules_prepare

PREPARING YOUR MODULE FOR COMPILATION

We need to create a Makefile to cross-compile our kernel module.  The contents of your Makefile should be similar to the following:

obj-m := modulename.o
KDIR := /path/to/kernel
PWD := $(shell pwd)
CCPATH := /path/to/android-ndk/toolchains/arm-eabi-4.4.0/prebuilt/linux-x86/bin
default:
$(MAKE) ARCH=arm CROSS_COMPILE=$(CCPATH)/arm-eabi- -C $(KDIR) M=$(PWD) modules

COMPILING AND INSTALLING YOUR MODULE

$ cd /path/to/module/src
$ make
$ cd /path/to/android-sdk/tools/
$ ./adb push /path/to/module/src/modulename.ko /sdcard/modulename.ko

RUNNING YOUR MODULE

$ cd /path/to/android-sdk/
$ ./adb shell
$ su
# insmod /sdcard/modulename.ko

CONCLUSION

Ineviditibly you'll run into some errors that you will need to sort out, as I did with both my droid 2 and evo devices.  Feel free to post in the comments if you run into any major problems, and I'll try my best to help you out.

FrozenCache Woes

There was a talk given very recently at 27c3 that I was very much looking forward to.  Juergen Pabel gave a talk about his ideas on mitigating cold boot attacks on cryptographic keys.  Since cold boot attacks are possible due to flaws properties of physical hardware they remain a largely unsolved problem.

Pabel's idea is that you can store sensitive data, such as keys, in the CPU's cache, disable cacheing, and zero the data from memory.  This should leave us with the key stored in a usable state in the CPU.  It's a good concept, but unfortunately it doesn't seem to be much more than a concept at this point.

Not surprisingly, CPUs have caches for a reason and when they are disabled, performance suffers.  In Pabel's demo, he was running what seemed like nothing more than a terminal to enable and disable his proof-of-concept and even that was painfully slow.  I realize that Pabel was not presenting a full solution, and I know how far from complete many POCs are, but I'm not sure how much optimization can actually be done.

x86 processor's simply weren't designed for this sort of cache abuse.  They don't offer enough control over the cache for this method to really be feasible.  There are no obvious ways to disable only the parts of the cache of our choosing, and no way to prevent others from flushing the cache and either destroying our sensitive data or dumping it to RAM.

What we really need is a hardware-tailored solution to this problem.  I think there is a need for a dedicated piece of hardware, either built into the CPU or with fast access to it, that could be used as forensically secure storage for sensitive data.  Similar solutions seem to work reasonably well in consoles (unless you are into epic math fails like Sony).

Overall, cold boot attacks aren't a huge problem, since they require physical access to pull off, but with an increase in government asshat-ery at airports it would be nice to have a solution.

UPDATE:// Juergen was kind enough to address my concerns in the comments.  Read on.