Each RPCSEC_GSS data packet is validated by a routine which checks a signature in the packet. This routine copies a portion of the packet into a stack buffer, but fails to ensure that the buffer is sufficiently large, and a malicious client can trigger a stack overflow. Notably, this does not require the client to authenticate itself first.
As kgssapi.ko's RPCSEC_GSS implementation is vulnerable, remote code execution in the kernel is possible by an authenticated user that is able to send packets to the kernel's NFS server while kgssapi.ko is loaded into the kernel.
In userspace, applications which have librpcgss_sec loaded and run an RPC server are vulnerable to remote code execution from any client able to send it packets. We are not aware of any such applications in the FreeBSD base system.
The rtsock_msg_buffer() function serializes routing information into a buffer. As a part of this, it copies sockaddr structures into a sockaddr_storage structure on the stack. It assumes that the source sockaddr length field had already been validated, but this is not necessarily the case, and it's possible for a malicious userspace program to craft a request which triggers a 127-byte overflow.
In practice, this overflow immediately overwrites the canary for the rtsock_msg_buffer() stack frame, resulting in a panic once the function returns.
The bug allows an unprivileged user to crash the kernel by triggering a stack buffer overflow in rtsock_msg_buffer(). In particular, the overflow will corrupt a stack canary value that is verified when the function returns; this mitigates the impact of the stack overflow by triggering a kernel panic.
Other kernel bugs may exist which allow userspace to find the canary value and thus defeat the mitigation, at which point local privilege escalation may be possible.
The rtsol(8) and rtsold(8) programs do not validate the domain search list options provided in router advertisement messages; the option body is passed to resolvconf(8) unmodified.
resolvconf(8) is a shell script which does not validate its input. A lack of quoting meant that shell commands pass as input to resolvconf(8) may be executed.
In some cases, the `tcp-setmss` handler may free the packet data and throw an error without halting the rule processing engine. A subsequent rule can then allow the traffic after the packet data is gone, resulting in a NULL pointer dereference.
Maliciously crafted packets sent from a remote host may result in a Denial of Service (DoS) if the `tcp-setmss` directive is used and a subsequent rule would allow the traffic to pass.
By default, jailed processes cannot mount filesystems, including nullfs(4). However, the allow.mount.nullfs option enables mounting nullfs filesystems, subject to privilege checks.
If a privileged user within a jail is able to nullfs-mount directories, a limitation of the kernel's path lookup logic allows that user to escape the jail's chroot, yielding access to the full filesystem of the host or parent jail.
In a jail configured to allow nullfs(4) mounts from within the jail, the jailed root user can escape the jail's filesystem root.
If two sibling jails are restricted to separate filesystem trees, which is to say that neither of the two jail root directories is an ancestor of the other, jailed processes may nonetheless be able to access a shared directory via a nullfs mount, if the administrator has configured one.
In this case, cooperating processes in the two jails may establish a connection using a unix domain socket and exchange directory descriptors with each other.
When performing a filesystem name lookup, at each step of the lookup, the kernel checks whether the lookup would descend below the jail root of the current process. If the jail root directory is not encountered, the lookup continues.
In a configuration where processes in two different jails are able to exchange file descriptors using a unix domain socket, it is possible for a jailed process to receive a directory for a descriptor that is below that process' jail root. This enables full filesystem access for a jailed process, breaking the chroot.
Note that the system administrator is still responsible for ensuring that an unprivileged user on the jail host is not able to pass directory descriptors to a jailed process, even in a patched kernel.
`bhyveload -h <host-path>` may be used to grant loader access to the <host-path> directory tree on the host. Affected versions of bhyveload(8) do not make any attempt to restrict loader's access to <host-path>, allowing the loader to read any file the host user has access to. In the bhyveload(8) model, the host supplies a userboot.so to boot with, but the loader scripts generally come from the guest image. A maliciously crafted script could be used to exfiltrate sensitive data from the host accessible to the user running bhyhveload(8), which is often the system root.
grub2-bhyve, as used in FreeBSD bhyve before revision 525916 2020-02-12, does not validate the address provided as part of a memrw command (read_* or write_*) by a guest through a grub2.cfg file. This allows an untrusted guest to perform arbitrary read or write operations in the context of the grub-bhyve process, resulting in code execution as root on the host OS.
grub2-bhyve, as used in FreeBSD bhyve before revision 525916 2020-02-12, mishandles font loading by a guest through a grub2.cfg file, leading to a buffer overflow.
Wi-Fi Protected Access (WPA and WPA2) allows reinstallation of the Group Temporal Key (GTK) during the four-way handshake, allowing an attacker within radio range to replay frames from access points to clients.