CVE-2020-7454: Killing Two Birds with One Bug in libalias

The following analysis is based on VirtualBox 6.1.4. The root cause of the bug is in the AliasHandleUdpNbtNS() function, which is responsible for parsing the NetBIOS Name Service packet on UDP port 137. The relevant part is shown below in simplified form.

At (1) in the code snippet above, uh_ulen is the UDP header length field, which is sent from the untrusted guest OS. The maximum possible value is 0xFFFF. By using a large uh_ulen value, an attacker can generate an overly large ‘pmaxvalue. Next, if the UDP packet contains Answer Resource Records and its type is specified as NetBIOS General Service, execution will reach theAliasHandleResourceNB()` function:

At (2) in the code snippet above, the while loop attempts to look for the old address in the packet and replace it with the new address until pmax. Since pmax is a large value, an out-of-bounds read will occur at (3). Furthermore, it may also write OOB at (4) if the old address is found.

An attacker on the guest OS can construct an invalid UDP header length to trigger the OOB access on the host OS. The UDP port 137 is open in the default configuration of VirtualBox. To address this bug, Oracle added a validation for the UDP header length shown at (1) in Snippet 1 above.

Looking at FreeBSD 12.1

As mentioned above, the libalias library originates from FreeBSD. While analyzing the submission in Oracle VirtualBox, I discovered this bug also affects FreeBSD when using ipfw for NAT. The ipfw packet filter contains two different methods of accomplishing NAT: one in kernel and one in user space. Both implementations use the same functions provided by libalias. This means that the bug can be triggered either in the kernel or in the userland program (natd), depending on the NAT configuration.

Here is the related configuration for FreeBSD 12.1 Release needed to trigger the bug in the kernel:

The OOB access happens in alias_nbt.ko, which is a loaded kernel module.

If the NAT configuration is based on userland, the OOB access happens in libalias_nbt.so in the context of the natd process. Both scenarios may be triggered remotely without authentication.

During my analysis I found an additional surprise. The libalias library in FreeBSD contains another variant of the same bug within the handling of CuSeeMe protocol, which listens on UDP port 7648 by default.

However, this bug does not exist in VirtualBox, which means the patch for FreeBSD is different than the one for VirtualBox. A validation is added in both the UdpAliasIn() and UdpAliasOut() functions, which is the appropriate level to handle UDP packets. It effectively patches any protocol that contains this kind of bug.