# Old but Gold

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:

* &#x20;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
* &#x20;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:

* &#x20;The Driver’s Sym-Link post installation is created as **\\\\.\DBUtil\_2\_3**
* &#x20;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:

<figure><img src="/files/eIFp9xjwPZDcR5LkPeA5" alt=""><figcaption><p>The buffer required to communicate with the vulnerable IOCTL's</p></figcaption></figure>

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 ](https://learn.microsoft.com/en-us/windows/win32/api/ioapiset/nf-ioapiset-deviceiocontrol)call.
*

```
<figure><img src="/files/Yjecmla2fR8KRmkdHAEe" alt=""><figcaption><p>Construction of the DeviceIoControl request</p></figcaption></figure>
```

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.

&#x20;

&#x20;


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://spikysabra.gitbook.io/kernelcactus/old-but-gold.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
