DragonflyBSD release 5.2.1 is here, BPF kernel exploit writeup, Remote Debugging the running OpenBSD kernel, interview with Patrick Mooney, FreeBSD buildbot setup in a jail, dumping your USB, and 5 years of gaming on FreeBSD.
Headlines
DragonFlyBSD: release52 (w/stable HAMMER2, as default root)


DragonflyBSD 5.2.1 was released on May 21, 2018
> Big Ticket items:



Meltdown and Spectre mitigation support
Meltdown isolation and spectre mitigation support added. Meltdown mitigation is automatically enabled for all Intel cpus. Spectre mitigation must be enabled manually via sysctl if desired, using sysctls machdep.spectremitigation and machdep.meltdownmitigation.
HAMMER2
H2 has received a very large number of bug fixes and performance improvements. We can now recommend H2 as the default root filesystem in non-clustered mode.
Clustered support is not yet available.
ipfw Updates
Implement state based "redirect", i.e. without using libalias.
ipfw now supports all possible ICMP types.
Fix ICMPMAXTYPE assumptions (now 40 as of this release).
Improved graphics support
The drm/i915 kernel driver has been updated to support Intel Coffeelake GPUs
Add 24-bit pixel format support to the EFI frame buffer code.
Significantly improve fbio support for the "scfb" XOrg driver. This allows EFI frame buffers to be used by X in situations where we do not otherwise support the GPU.
Partly implement the FBIOBLANK ioctl for display powersaving.
Syscons waits for drm modesetting at appropriate places, avoiding races.




PS4 4.55 BPF Race Condition Kernel Exploit Writeup




Note: While this bug is primarily interesting for exploitation on the PS4, this bug can also potentially be exploited on other unpatched platforms using FreeBSD if the attacker has read/write permissions on /dev/bpf, or if they want to escalate from root user to kernel code execution. As such, I've published it under the "FreeBSD" folder and not the "PS4" folder.



Introduction



Welcome to the kernel portion of the PS4 4.55FW full exploit chain write-up. This bug was found by qwerty, and is fairly unique in the way it's exploited, so I wanted to do a detailed write-up on how it worked. The full source of the exploit can be found here. I've previously covered the webkit exploit implementation for userland access here.



FreeBSD or Sony's fault? Why not both...



Interestingly, this bug is actually a FreeBSD bug and was not (at least directly) introduced by Sony code. While this is a FreeBSD bug however, it's not very useful for most systems because the /dev/bpf device driver is root-owned, and the permissions for it are set to 0600 (meaning owner has read/write privileges, and nobody else does) - though it can be used for escalating from root to kernel mode code execution. However, let’s take a look at the make_dev() call inside the PS4 kernel for /dev/bpf (taken from a 4.05 kernel dump).



seg000:FFFFFFFFA181F15B lea rdi, unk_FFFFFFFFA2D77640
seg000:FFFFFFFFA181F162 lea r9, aBpf ; "bpf"
seg000:FFFFFFFFA181F169 mov esi, 0
seg000:FFFFFFFFA181F16E mov edx, 0
seg000:FFFFFFFFA181F173 xor ecx, ecx
seg000:FFFFFFFFA181F175 mov r8d, 1B6h
seg000:FFFFFFFFA181F17B xor eax, eax
seg000:FFFFFFFFA181F17D mov cs:qword_FFFFFFFFA34EC770, 0
seg000:FFFFFFFFA181F188 call make_dev



We see UID 0 (the UID for the root user) getting moved into the register for the 3rd argument, which is the owner argument. However, the permissions bits are being set to 0x1B6, which in octal is 0666. This means anyone can open /dev/bpf with read/write privileges. I’m not sure why this is the case, qwerty speculates that perhaps bpf is used for LAN gaming. In any case, this was a poor design decision because bpf is usually considered privileged, and should not be accessible to a process that is completely untrusted, such as WebKit. On