Old but Gold

Re-visiting - CVE-2021-21551

Back at 2019, a few security researchers from across the globe have discovered upon a CVE which only came to fruition on 2021, that CVE A.K.A CVE-2021-21551, regards Dells driver dbutil_2_3.sys.

In particular we would like to mention: Kasif Dekel, Satoshi Tanda, Yarden Shafir and Nique Nissim which were the OG’s that have discovered this amazing vulnerability.

Another honorable mention goes out to Connor McGarr for making a great writeup regarding exploitation of this CVE.

This Driver, which is in a major part of Dell’s BIOS utilities and has existed in hundreds of millions of computers, has been found to contain some major flaws.

As we do not intend to re-write all the existing articles which have been written on this subject, here are the major key issues this driver creates if installed:

  • Insufficient access control – Input / Output Control (IOCTL) requests can be called from all privileges without a well-defined ACL to prevent low privileged users to call code that is running in kernel mode

  • Upon Reversing said driver, and the IOCTL calls, it has been found that specific calls eventually result in memmove routines which allow a user to move memory around the kernel space.

The first issue is self-explanatory, a low privileged user should not be able to call such routines without ACL to stop it.

The second issue, is a little less trivial, though as wonderful and talented researches have proved, if one better understands the way in which the call is constructed, and is able to determine from those memmove operations, which data goes where, then Read / Write Abilities are created.

Without going into the nitty gritty, all those great names mentioned above, have previously reversed those functions, and provided us with enough information to conclude the following points:

  • The Driver’s Sym-Link post installation is created as \\.\DBUtil_2_3

  • An IOCTL call resides in the entry point 0x9B0C1EC4 which allows read operations

  • An IOCTL call resides in the entry point 0x9B0C1EC8 which allows write operations

  • The following Buffer contains the relevant data that is needed in order for the IOCTL codes to branch to the relevant memmove call that we are targeting:

The buffer required to communicate with the vulnerable IOCTL's

This buffer is constructed from padding, the target address to read/write from, and a pointer to the buffer to read into or write from.

  • Interaction with the driver is later made by using all the above points, and connecting them all in a DeviceIoControl call.

  • Construction of the DeviceIoControl request

As mentioned in the intro for this article, this CVE has been previously used in order to elevate privileges, steal tokens, and to read / write Callbacks for Process / Thread creations, Image loading, and Handle Creations / Handle duplications.

After reading some code written to exploit this vulnerability, including the wonderfully made EDRsandBlast by Wavestone, Cheeky-Blinder by br-sn and STFUEDR by lawiet, it has become clear to us that much more can be done in regards to which areas of the kernel we are reading or writing.

With our curiosity sparked, and with a PDB of NtosKrnl.exe, we went on a journey to tell our own story regarding this CVE.

And here we are today, serving you some fresh exploits that will make you think a little more severely of this CVE.

Last updated