Analysis and Exploitation of a Linux Kernel Vulnerability

FYI: If you're comfortable with Gentoo, the jump to Hardened Gentoo[1] is an easy one[2] and gives TrustedBSD[3] a run for its money w/r/t out-of-the-box security. It has the SElinux MAC, role based access controlled stuff from GRsec alternatively [you can mix and match GRsec + SElinux except for RBAC and SElinux's ACL system), grsec's ASLR at runtime, modified versions of musl/uclibc, stack protection support (why anyone would write software that could possibly be EIP exploited with countless ASan damn well integrated into some compilers, I haven't a clue), and a whole host more.

Some interesting academic work: http://hmarco.org/data/OnTheEffectivness-NX-SSP-RenewSSP-and...

While SSP is not enough, (use PIE too): http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.ht...

A fun toy: https://github.com/JhetoX/VectorAttackScanner

[1]https://wiki.gentoo.org/wiki/Project:Hardened

[2]https://wiki.gentoo.org/wiki/Hardened/Introduction_to_Harden...

[3]Granted I haven't used it in ages, it's still the benchmark I use in my mind, back when Linux 2.2 was rife with out-of-the-box ROP vulns.

Arch seems to be kosher

  $ uname -r
  4.3.3-2-ARCH

No root:

  $ ./cve_2016_0728 PP_KEY
  uid=1000, euid=1000
  Increfing...
  finished increfing
  forking...
  finished forking
  caling revoke...
  uid=1000, euid=1000

Only took about 25 minutes on a Lenovo core i7. That's kind of scary.

EDIT: Actually it seems that atomic_t is 64 bits long with x86_64 these days, so no hope of overflowing.

Freedom of the Press Foundation (disclosure: I am an employee) ships grsecurity kernels for SecureDrop. You have to build them yourself, but it really isn't that hard to do. We're working on making this easier for everybody by publishing guides [0] to building your own grsecurity kernel, as well as developing an Ansible playbook to automate building hardened kernels [1].

This is all still a work in progress, but expect a blog post once what we have is more polished.

A relatively easy-to-follow blog post was recently published that guides you through building a grsecurity kernel for a Debian desktop installation: [2].

grsecurity was operating a service last year that would allow you to request custom built kernels for a small price, although I can't find it now so it may have been taken offline. This is an ideal solution, and is actually better than packaging the kernels in an distribution's repository, because some of grsecurity's security features are more effective when everybody is running a unique kernel (e.g. RANDSTRUCT).

Finally, the linux-hardening group is working on upstreaming select PaX features into the mainline kernel [3], including PAX_REFCOUNT, which is the protection that would've mitigated this particular vulnerability.

[0]: https://gist.github.com/ageis/a91f36ca99c252291a00 [1]: https://github.com/freedomofpress/grsec/ [2]: https://micahflee.com/2016/01/debian-grsecurity/ [3]: http://lwn.net/Articles/668876/

Yes sorry. I will make the cheap excuse that I am recovering from food poisoning and don't quite have it all together. Thankfully I don't manage nuclear weapons, so we are all safe for now.

Did not get root on my test box (OpenSuSE 13.2 64bit) with kernel 3.16.6-2-default

  uid=10000, euid=10000
  Increfing...
  finished increfing
  forking...
  finished forking
  caling revoke...
  uid=10000, euid=10000
  sh-4.2$