CVE-2022-23088: Exploiting A Heap Overflow In The Freebsd Wi-Fi Stack
In April of this year, FreeBSD patched a 13-year-old heap overflow in the Wi-Fi stack that could allow network-adjacent attackers to execute arbitrary code on affected installations of FreeBSD Kernel. This bug was originally reported to the ZDI program by a researcher known as m00nbsd and patched in April 2022 as FreeBSD-SA-22:07.wifi_meshid. The researcher has graciously provided this detailed write-up of the vulnerability and a proof-of-concept exploit demonstrating the bug.
Tale of two hypervisor bugs - Escaping from FreeBSD bhyve
VM escape has become a popular topic of discussion over the last few years. A good amount of research on this topic has been published for various hypervisors like VMware, QEMU, VirtualBox, Xen and Hyper-V. Bhyve is a hypervisor for FreeBSD supporting hardware-assisted virtualization. This paper details the exploitation of two bugs in bhyve - FreeBSD-SA-16:32.bhyve  (VGA emulation heap overflow) and CVE-2018-17160  (Firmware Configuration device bss buffer overflow) and some generic techniques which could be used for exploiting other bhyve bugs. Further, the paper also discusses sandbox escapes using PCI device passthrough, and Control-Flow Integrity bypasses in HardenedBSD 12-CURRENT
The FreeBSD-linuxulator explained (for users)
First, the linuxulator is not an emulation. It is “just” a binary interface which is a little bit different from the FreeBSD-“native”-one. This means that the binary files in FreeBSD and Linux are both files which comply to the ELF specification.
FreeBSD'fy ZFS zlib zalloc/zfree callbacks
The previous code came from OpenSolaris, which in my understanding require allocation size to be known to free memory. To store that size previous code allocated additional 8 byte header. But I have noticed that zlib with present settings allocates 64KB context buffers for each call, that could be efficiently cached by UMA, but addition of those 8 bytes makes them fall back to physical RAM allocations, that cause huge overhead and lock congestion on small blocks. Since FreeBSD’s free() does not have the size argument, switching to it solves the problem, increasing write speed to ZVOLs with 4KB block size and GZIP compression on my 40-threads test system from ~60MB/s to ~600MB/s.
Fixing up KA9Q-unix, or "neck deep in 30 year old codebases.."
Anyhoo, I’ve finally been mucking around with AX.25 packet radio. I’ve been wanting to do this since I was a teenager and found out about its existence, but back in high school and .. well, until a few years ago really .. I didn’t have my amateur radio licence. But, now I do, and I’ve done a bunch of other stuff with a bunch of other radios. The main stumbling block? All my devices are either Apple products or run FreeBSD - and none of them have useful AX.25 stacks. The main stacks of choice these days run on Linux, Windows or are a full hardware TNC.
The advisory describes that FreeBSD 12.0 introduced a bug in this mechanism. As the file descriptor information is sent via a socket, the sender and the receiver have to allocate buffers for the procedure. If the receiving buffer is not large enough, the FreeBSD kernel attempts to close the received file descriptors to prevent a leak of these to the sender. However, while the responsible function closes the file descriptor, it fails to release the reference from the file descriptor to the file object. This could cause the reference counter to wrap.
Provide protection against starvation of the ll/sc loops when accessing userpace.
Casueword(9) on ll/sc architectures must be prepared for userspace constantly modifying the same cache line as containing the CAS word, and not loop infinitely. Otherwise, rogue userspace livelock kernel.
Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service issues
Netflix has identified several TCP networking vulnerabilities in FreeBSD and Linux kernels. The vulnerabilities specifically relate to the minimum segment size (MSS) and TCP Selective Acknowledgement (SACK) capabilities. The most serious, dubbed “SACK Panic,” allows a remotely-triggered kernel panic on recent Linux kernels.
powerpc64 architecture support in FreeBSD ports
For my project, I build the whole ports tree using Poudriere and fix the compilation errors I meet. In this paper, I specify challenges met during porting software to work on POWER processors on FreeBSD and show how most problems can be solved.
Trivial stuff, if only people cared. Relevant beyond narrow scope of FreeBSD PowerPC as well.
This syscall would only performs additional sanitary checks if we are removing a directory entry which corresponds to the inode stored which refers to the file descriptor.
Less Known pkg(8) Features
In this entry I will try to describe less known pkg(8) features.
Below you will find the updated Rosetta Stone between old pkg_* tools compared to current pkg(8) framework.
The Super Capsicumizer 9000
capsicumizer is a sandbox launcher that imposes Capsicum capability mode onto an unsuspecting program, allowing “sysadmin style” or “oblivious” sandboxing (i.e. no source code modifications, all restrictions added externally).
The future of ZFS in FreeBSD
This shift means that there will be little to no net new development of Illumos. While working through the git history of ZoL I have also discovered that many races and locking bugs have been fixed in ZoL and never made it back to Illumos and thus FreeBSD. This state of affairs has led to a general agreement among the stakeholders that I have spoken to that it makes sense to rebase FreeBSD’s ZFS on ZoL.
Also some background: https://lists.freebsd.org/pipermail/freebsd-current/2018-December/072430.html
FreeBSD 12.0-RELEASE Now Available
I spent a couple of years evangelizing about Capsicum. I wrote many articles about it. So, it is very natural that I would also like to update you on this blog about the progress of the Capsicum project in FreeBSD, because this is what I’m doing in my free time. That said I feel that this blog wouldn’t be completed without some introduction to what Capsicum is. This post should fill this gap. Over the next weeks and months we will extend this topic and discuss different parts of Capsicum.
Dive into syscall handling on freeBSD AMD64
PS4 5.05 BPF Double Free Kernel Exploit Writeup
Welcome to the 5.0x kernel exploit write-up. A few months ago, a kernel vulnerability was discovered by qwertyoruiopz and an exploit was released for BPF which involved crafting an out-of-bounds (OOB) write via use-after-free (UAF) due to the lack of proper locking. It was a fun bug, and a very trivial exploit. Sony then removed the write functionality from BPF, so that exploit was patched. However, the core issue still remained (being the lack of locking). A very similar race condition still exists in BPF past 4.55, which we will go into detail below on.
Dumping a PS4 Kernel in "Only" 6 Days
What if a secure device had an attacker-viewable crashdump format? What if that same device allowed putting arbitrary memory into the crashdump? Amazingly, the ps4 tempted fate by supporting both of these features! Let’s see how that turned out…
Software compatibility and our own "User-Agent" problem
The problem that the people working on FreeBSD found is that if they tried to run configure in an environment in which lld is installed as the standard linker, lld would be determined by configure as if it were an ancient Unix linker like 30 years ago. Further investigation revealed that the configure script runs the linker in the background with the --help option, and determines it as a modern linker only when the displayed help message contains “GNU” or “with BFD”. What this means is that only GNU linkers are considered modern in the environment, and all the other linkers are considered terribly outdated.
When life gives you autotools...
FreeBSD/EC2 on C5 instances
there are still a few kinks which need to be worked out for FreeBSD to run smoothly on C5 instances. I strongly recommend that you read the rest of this blog post before you use FreeBSD on EC2 C5 instances. (Or possibly skip to the end if you’re not interested in learning about any of the underlying details.)