FreeBSD security researcher CTurt, known for his recent work in the PS4 kernel exploit, outlines a recent FreeBSD kernel vulnerability found in iotcl handlers. In addition, check out his article on vulnerabilities in FreeBSD compatibility layers.
Every FreeBSD keyboard driver exposes its own
ioctlinterface to allow it to be configured from userland (through the
kbdcontrolutility for example). Typically, these
ioctlhandlers will implement any specific commands for the hardware, such as enabling or disabling LEDs, and will delegate the rest of the commands to a common handler, called
I discovered a vulnerability in this common handler, which has been present since the driver’s introduction in 1999.
Due to a poor default
sysctlvariable, this bug can be triggered by an unprivileged user, so long as at least one keyboard driver is running (by default the
atkbddriver is used), making its impact critical.
I decided to report this bug to the FreeBSD Security Team on April 22, 2016, the day after I had discovered it, and was able to exploit it about a week later. It has been assigned CVE-2016-1886 and Security Advisory 16:18.
In this article I will provide an explanation of the bug, and some of the methods which I considered for exploitation, including the one I had success with: using the corrupted
lenmember of a
keytabto trigger a powerful two way heap and stack overflow.
Original post: http://cturt.github.io/SETFKEY.html
Analysis of stack disclosure vulnerabilities in FreeBSD compatibility layers
Arguably one of FreeBSD’s most renowned features is its compatibility layers. In particular, FreeBSD provides compatibility layers for 32-bit Linux binaries and for legacy 4.3BSD software. These are usually enabled by building a custom kernel with the
COMPAT_43configuration options, however the Linux compatibility layer is also implemented as a separate kernel module, which can be loaded at runtime instead (
Original post: http://cturt.github.io/compat-info-leaks.html