800+ IT
News
als RSS Feed abonnieren📚 CVE-2020-7454: Killing Two Birds with One Bug in libalias
💡 Newskategorie: Hacking
🔗 Quelle: thezdi.com
At the beginning of February 2020, the ZDI received a submission detailing a bug in Oracle VirtualBox that could lead to an out-of-bounds access in the libalias packet aliasing library. It was reported to us by the researcher Vishnu Dev TJ and eventually assigned CVE-2020-7454 when patched. When analyzing the submission, I found the bug existed in FreeBSD as well. This blog covers CVE-2020-7454 on both VirtualBox and FreeBSD and shows how the maintenance of third-party or shared code can be a difficult task.
For those not familiar, libalias is a library for the aliasing and de-aliasing of IP packets. It is also intended for masquerading and network address translation (NAT). With its masquerading and NAT features, it’s understandable why it would be used by VirtualBox for various functions. However, libalias originates from FreeBSD. VirtualBox maintains its own fork of the library. Unfortunately, this vulnerability is shared between the versions. It leads to an out-of-bounds (OOB) access in the FreeBSD kernel and user mode. The bug was addressed in VirtualBox 6.1.6 and FreeBSD-SA-20:12.
Looking at Oracle VirtualBox
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.
Conclusion
This case study shows that the maintenance of third-party or shared code is a difficult task. Even if the source code is patched or updated, those changes must be made to the upstream products as well. And even when you are in sync with the third-party, a vulnerability in the shared code has twice the impact since it affects both products. Oracle VirtualBox is becoming more popular with user and security researchers alike. Thanks again to Vishnu Dev TJ for reporting this and other VirtualBox bugs. We look forward to seeing more from him in the future.
Until then, you can find me on Twitter @_wmliang_, and follow the team for the latest in exploit techniques and security patches.
...