Multiple vulnerabilities in AMI file system drivers

Background

The same malformed file system structures can cause problems in independently developed file system parsers…

For example, missing boundary checks when parsing the NTFS update sequence array resulted in two vulnerabilities disclosed before: one in the ntfsck tool (from the ntfs-3g package) – CVE-2021-46790, one in the 7-Zip archiver – CVE-2023-52168.

Now, there is a third item in that row: CVE-2022-29974.

This is a pool-based buffer overflow in the AMI NTFS driver, it has the same root cause as two other vulnerabilities mentioned above. And, interestingly, it took more than 2 years for the fix to reach downstream firmware updates…

This post is about 5 vulnerabilities discovered in EFI file system drivers from AMI.

CVE-2022-29974

Here is my report, sent to the AMI BIOS Security Team in 2021:

Hello.
 
# Summary
I have discovered an out-of-bounds write condition in the AMI NTFS driver, version 1.0.0.
A successful exploitation of this condition results in two bytes at a specific, out-of-bounds, offset being overwritten with two bytes chosen by an attacker. The value of these two bytes to be overwritten must be known prior to the exploitation attempt (and they can’t be equal to 0x0000, this means that two bytes together can’t be null).
 
# Description
The NTFS file system implements a multi-sector transfer protection feature. This feature takes multiple sectors to be written to the underlying drive as input and copies the last two bytes of each sector into the array located in the first sector, then replaces the last two bytes of each sector with a placeholder value; these modified sectors are then written to the drive. This array is called an update sequence array (or USA). The feature allows the NTFS driver to detect torn writes when reading from the drive (the last two bytes of a failed sector won't match the placeholder value, which is known because it’s stored in the first sector); if no torn write is detected, original values are restored from the update sequence array into the end of each sector (overwriting the placeholder values). This is used when writing file record segments and index buffers, so they are protected against torn writes.
 
(More details about this feature can be found here: <https://flatcap.org/linux-ntfs/ntfs/concepts/fixup.html>.)
 
Your driver implements this feature, but fails to detect a condition when the number of update sequence array entries is too large for the given buffer.
 
For example, an index buffer is 4096 bytes in length (by default).
Thus, it contains 8 sectors (the sector size is always assumed to be 512 bytes in this case), so the update sequence array must contain 9 entries (1 placeholder value, 8 original values to be restored when reading from the drive).
However, the AMI NTFS driver allows any number of update sequence array entries. An attacker can exploit this to "restore" values (from the update sequence array) beyond the allocated buffer.
 
A vulnerable function is shown in <applyusa.png>.
I have confirmed the vulnerability using QEMU and Tianocore EDK II.
User actions required to trigger the vulnerability are shown in <qemu.png>.
The file system sample required to trigger the vulnerability is <ntfs.raw.gz> (unpack before using).
 
Note that this file system isn’t valid, the following error is shown by The Sleuth Kit: "Error in metadata structure (ntfs_fix_idxrec: More Update Sequence Entries than idx record size)". Also, due to several implementation details of your driver, the file system must have its cluster size set to 2048 bytes (or to a smaller value).
 
The initial state before applying the update sequence array entry is shown in <ida-1.png>.
The last sector before applying the update sequence array entry is shown in <ida-2.png>. The pool footer is also shown here.
The memory region beyond the allocated buffer before applying the update sequence array entry is shown in <ida-3.png>.
The memory region beyond the allocated buffer after applying the update sequence array entry is shown in <ida-4.png>.
The last sector and the memory region beyond the allocated buffer are shown in <ida-5.png>.
 
As you can see, the vulnerable function replaced two bytes after the allocated pool buffer (AF AF => BA AD).
Note that the file system sample requires Tianocore EDK II and debugging enabled, it's expected (when using this sample) that unused memory is filled with the 0xAF pattern (it's impossible to exploit the condition if both bytes to be replaced are equal to 0x00, see line #13 in <applyusa.png>).
 
# Fix
A proposed fix is to check the number of update sequence array entries against the allocated buffer size and bail out if any unexpected value is encountered.

Here are all files attached to that report:

And a bunch of additional screenshots: ida-1.png, ida-2.png, ida-3.png, ida-4.png, ida-5.png, qemu.png.

The PoC file system image is here: ntfs.raw.gz.

Timeline

• On 2021-08-27, I sent the vulnerability report to the AMI BIOS Security Team.
• On 2021-09-03, the AMI BIOS Security Team confirmed that they have received my report.
• On 2021-09-10, the AMI BIOS Security Team stated that “[the vulnerability] has been addressed in the NTFS driver module“.
• On 2021-09-19, the AMI BIOS Security Team stated that “[they] are planning to provide a mitigation to customers by end of October“.
• On 2022-05-02, the following identifier was assigned to the vulnerability: CVE-2022-29974 (CNA: MITRE). It was requested by me.
• On 2024-01-21, I found that the fix isn’t shipped by at least one downstream vendor (in particular, ASUS). Affected ASUS products include: H610M-AYW D4 and PRIME Z790M-PLUS (and, possibly, other products are affected as well). The NTFS fix isn’t there, while other recent security fixes (e.g., for LogoFAIL) are shipped as expected. This was reported to the AMI BIOS Security Team.
• On 2024-02-27, I reported that the fix isn’t shipped by more downstream vendors (in particular, Dell). Affected Dell products include: Latitude 3120 (and, possibly, others as well – it should be noted that not all Dell products use EFI NTFS drivers based on AMI code). The fix isn’t in the latest firmware update. This was reported to the AMI BIOS Security Team.
• On 2024-02-29, the AMI BIOS Security Team stated that “ASUS indicated they will patch these two products to take the NTFS fixes“…

No further communication arrived from the AMI BIOS Security Team specifically about this vulnerability and other affected vendors like Dell.

• On 2024-03-13, I noticed that a fixed version of the driver is shipped by ASUS.

So, it took more than two years to roll out the vulnerability fix (August 2021 – February/March 2024). No public security advisory was ever issued.

---

Another vulnerability in the same function

If you look at the decompiled function shown above, you might notice another vulnerability on line #22.

The code writes two null bytes into a memory location calculated from on-disk data without any boundary checks. The “write a null byte to an attacker-chosen memory location” primitives are known to be dangerous (for example, an attacker can reset a variable that enables some runtime security-related features, thus turning them off).

And I didn’t notice that vulnerability before validating the fix for CVE-2022-29974…

Here is my message, sent on 2024-03-13 to the AMI BIOS Security Team (in this message, I also mention the fix for CVE-2022-29974, because I was replying to their message from 2024-02-29):

Hello.

    1. Thank you. I see the first related firmware update (ASUS H610M-AYW D4 BIOS 3203).

    2. Also, I found another issue in the same function used to apply update sequence array elements.

After the update sequence array elements have been successfully applied, the function assigns zero to the first element (i.e., two bytes) of this array, the first element contains the placeholder value (see <ida-func.png>). There is no boundary check for the array, so an attacker could produce a specially-crafted file system image and zero-out two bytes beyond the allocated buffer (see <ida-before-zeroing.png> and <ida-after-zeroing.png>, also see <ami_ntfs_test_3.raw>, this file system image was attached to a virtual machine debugged as shown on two screenshots just mentioned).
 
These two bytes can be located within the 65535-byte range (the exact offset is attacker-chosen) starting from the first byte of the current file record segment (or the current index buffer), and an attacker must know their value before the attack.
 
So, the idea is that v3 (as shown on <ida-func.png>) points to two bytes to be changed (beyond the allocated buffer), *(a2+6) is 2 (one placeholder value and one "original" value), *v5 is equal to *v3 (v5 points to two bytes at a2+510, this is within the allocated buffer; *v5 is equal to the value at v3 which is going to be changed).
 
I have attached three screenshots and a sample file system image (gzipped).

Here are all files attached to that message:

And two more screenshots: ida-before-zeroing.png, ida-after-zeroing.png.

The PoC file system image is here: ami_ntfs_test_3.raw.gz.

Timeline

• On 2024-03-13, I sent the vulnerability report to the AMI BIOS Security Team.
• On 2024-07-03, the AMI BIOS Security Team says that they started the analysis of this vulnerability.

No further communication arrived from the AMI BIOS Security Team specifically about this vulnerability.

Thus, it took more than 3 months to start the analysis of my vulnerability report…

---

Two more overflows in the AMI NTFS driver

In January 2024, I discovered two more vulnerabilities in the same NTFS driver. Both were reported to the AMI BIOS Security Team, here is my message:

Hello.

I have discovered two vulnerabilities in the AMI NTFS driver, both of them are pool-based buffer overflows occurring when calling the EFI_BOOT_SERVICES.CopyMem() function.

1. One pool-based buffer overflow occurs when parsing the $VOLUME_NAME attribute.

A function used to extract the volume name into a pool-allocated area doesn't validate the Length argument passed for the EFI_BOOT_SERVICES.CopyMem() function (the argument value is simply taken from the corresponding on-disk structure), so a specially-crafted file system image could trigger an out-of-bounds write (see: "volname_func.png").

Date discovered: 2024-01-18.

2. Another pool-based buffer overflow occurs when parsing the resident $ATTRIBUTE_LIST attribute.

A function used to extract data from a resident $ATTRIBUTE_LIST attribute found in a file record segment into a pool-allocated area doesn't validate the Length argument passed for the EFI_BOOT_SERVICES.CopyMem() function (the argument value is simply taken from the corresponding on-disk structure), so a specially-crafted file system image could trigger an out-of-bounds write (see: "attrlist_func.png").

Additionally, the same piece of code contains unsafe arithmetic, which could overflow the size of the attribute data to be copied using the EFI_BOOT_SERVICES.CopyMem() function (see the "attr_data_size_calulated = ..." line on the same screenshot).

Date discovered: 2024-01-19.

3. I have attached two proof-of-concept disk images to this report. See the "ami_ntfs.rar" archive.

The first one, "ami_ntfs_test.raw", corresponds to the $VOLUME_NAME flaw. An attempt to list the volume name for this image would trigger the overflow.
The second one, "ami_ntfs_test_2.raw", corresponds to the $ATTRIBUTE_LIST flaw. An attempt to list the root directory of this volume (or to read the text file within the volume) would trigger the overflow.

Here are all files attached to the report:

The PoC file system images are here: ami_ntfs.rar.

It should be noted that each vulnerability triggers the overflow with attacker-controlled data (this was confirmed by triggering each vulnerability in the debugger). And the amount of bytes overwritten beyond the allocated buffer is huge (and is also attacker-controlled)…

Timeline

• On 2024-01-21, I reported both vulnerabilities to the AMI BIOS Security Team.
• On 2024-01-22, I sent two updated screenshots (having better comments) to the AMI BIOS Security Team.
• On the same day, the AMI BIOS Security Team asked if these are the same vulnerabilities as reported by me in 2021. (Clearly, my answer was “no”.)
• On the same day, the AMI BIOS Security Team stated that they started the investigation.
• On 2024-07-03, the AMI BIOS Security Team stated that these are bugs, not vulnerabilities. And they are going to fix them.
• On the same day, I asked for justification behind the “not a vulnerability” response.

No further communication arrived from the AMI BIOS Security Team about these vulnerabilities. Obviously, such overflows with attacker-controlled data are vulnerabilities, not regular bugs…

---

One overflow in the AMI exFAT driver

I also discovered a vulnerability in another file system driver from AMI – in the AMI exFAT driver.

Here is my report:

Hello.

I have discovered a vulnerability in the AMI exFAT driver, which is a pool-based buffer overflow occurring when calling the EFI_BOOT_SERVICES.CopyMem() function.

A function used to extract the volume name into a pool-allocated area doesn't validate the Length argument passed for the EFI_BOOT_SERVICES.CopyMem() function (the argument value is taken from the corresponding on-disk structure, then multiplied by 2), so a specially-crafted file system image could trigger an out-of-bounds write (see: "volname_func_exfat.png", "before_copymem.png", and "after_copymem.png").

Note that the EFI_BOOT_SERVICES.CopyMem() function is used twice there: in one place, it copies the volume label to a per-volume structure allocated by the AMI exFAT driver; in another place, it copies the volume label to a caller-supplied buffer. The overflow occurs in the former case only (there are proper checks in the latter case).
In the worst case scenario, the on-disk image defines the volume label size as being 255 characters in length, while the specification limit is 11 and the pool-allocated area is limited to 12 characters. Since these are 16-bit characters, the actual overflow is 486 bytes. This is enough to touch the next pool allocation existing in the memory.

Date discovered: 2024-01-23.

I have attached a proof-of-concept disk image to this report. See the "ami_exfat.rar" archive.

Here are all files attached to the report:

And two more screenshots: before_copymem.png, after_copymem.png.

The PoC file system image is here: ami_exfat.rar.

The vulnerability triggers the overflow with at most of 486 bytes of attacker-controlled data.

Timeline

• On 2024-01-25, I sent the vulnerability report to the AMI BIOS Security Team.
• On the same day, I sent two follow-up messages to fix some typos in my report (the report quoted above includes these fixes).
• On 2024-01-28, the AMI BIOS Security Team stated that they started the investigation.
• On 2024-07-03, the AMI BIOS Security Team stated that this is a bug, not a vulnerability. And they are going to fix it.

No further communication arrived from the AMI BIOS Security Team about this vulnerability.

Vulnerable drivers (MD5 hashes for reference)

• c17f84a6f3f16f80b1ace71d7b19cd7b (AMI NTFS driver, shipped by ASUS, affected by CVE-2022-29974)
• b578e8f8db9d699669cb5f63b26912b3 (AMI NTFS driver, shipped by Dell, affected by CVE-2022-29974)
• 43bbcdc0513034ffef62f9be3651f6ef (AMI NTFS driver, shipped by ASUS, containing a fix for CVE-2022-29974, but affected by three other vulnerabilities described)
• 7de308b1e01c1392b73ccb894a69f797 (AMI exFAT driver, shipped by ASUS, affected by the vulnerability described)

Conclusions

1. memcpy()-style overflows and insecure/unsafe pointer arithmetic seem to be common in EFI file system drivers.
2. The AMI BIOS Security Team handles vulnerability reports in an awkward way.

Update (2024-12-10):

I decided to re-check all five vulnerabilities against a random (but recent) firmware update from ASUS.

The following product was selected: Pro WS Z890-ACE SE. The following firmware update was tested: 1101 (2024/12/05).

The results are: all five vulnerabilities are present there.

There is a small change in the code of the AMI exFAT driver, now the overflow touches at most 478 bytes after the allocated buffer (the allocated buffer size is 32 bytes, which is slightly larger than before).

And, still, there is no fix for CVE-2022-29974 (3 years without a fix!).

Here are the screenshots (for two overflows in the volume label field, in the exFAT and NTFS): 1, 2 and 3, 4…

Vulnerable drivers (MD5): 74a7f6ec656344babe1c72566e942eab (exFAT), 890537676b745ab921ce2a6ce35f7d7d (NTFS).

Update (2025-02-10):

On 2025-01-08, I got the following message from the AMI PSIRT:

We have thoroughly reinvestigated the NTFS-related issues you reported and concluded that all three are indeed vulnerabilities. The first two issues have been resolved, and the affected module has already been released. The third issue will be addressed in the upcoming release. Additionally, we will publish advisories for these vulnerabilities.

As of 2025-02-10, no public advisory is available. And no information about the exFAT vulnerability arrived.

Update (2025-10-15):

The following CVE numbers were published yesterday:

• CVE-2025-22831 (Buffer Overflow in NTFS when parsing the VOLUME_NAME);
• CVE-2025-22832 (Buffer Overflow in NTFS when parsing the ATTRIBUTE_LIST);
• CVE-2025-22833 (FixupArray Pointer Validation in NTFS), this is different from CVE-2022-29974;
• CVE-2025-33044 (exFat Memory Corruption Issue).

So, all issues are covered now. Thank you, AMI!