CVE-2023-4692, CVE-2023-4693: grub2: OOB write, read via specially crafted NTFS filesystem

[Solar Designer <solar () openwall com>]

Hi,

A couple of issues in GRUB relevant to setups with Secure Boot got fixed:

https://lore.kernel.org/all/ZRxK8s4nQV2jBq%2F9 () tomti i net-space pl/

Daniel, I'd appreciate it if you post things like this to oss-security
going forward.  Thank you!

> Date: Tue, 3 Oct 2023 19:10:10 +0200
> From: Daniel Kiper <daniel.kiper () oracle com>
> To: grub-devel () gnu org
> Cc: dfirblog () gmail com
> Subject: [SECURITY PATCH 0/6] GRUB2 NTFS driver vulnerabilities - 2023/10/03
>
> Hi all,
>
> This patch set contains a bundle of fixes for various security flaws discovered
> in the GRUB2 NTFS driver code recently. The most severe ones, i.e. potentially
> exploitable, have CVEs assigned and are listed at the end of this email.
>
> Details of exactly what needs updating will be provided by the respective
> distros and vendors when updates become available.
>
> Full mitigation against all CVEs will require updated shim with latest SBAT
> (Secure Boot Advanced Targeting) [1] data provided by distros and vendors.
> This time UEFI revocation list (dbx) will not be used and revocation of broken
> artifacts will be done with SBAT only. For information on how to apply the
> latest SBAT revocations, please see mokutil(1). Vendor shims may explicitly
> permit known older boot artifacts to boot.
>
> Updated GRUB2, shim and other boot artifacts from all the affected vendors will
> be made available when the embargo lifts or some time thereafter.
>
> I am posting all the GRUB2 upstream patches which fix all security bugs found
> and reported up until now. Major Linux distros carry or will carry soon one
> form or another of these patches. Now all the GRUB2 upstream patches are in
> the GRUB2 git repository [2] too.
>
> I would like to thank Maxim Suhanov for responsible disclosure and preparation
> of patches required to fully fix all known issues.
>
> Daniel
>
> [1] https://github.com/rhboot/shim/blob/main/SBAT.md
>
> [2] https://git.savannah.gnu.org/gitweb/?p=grub.git
>     https://git.savannah.gnu.org/git/grub.git
>
> *******************************************************************************
>
> CVE-2023-4692 grub2: OOB write when parsing the $ATTRIBUTE_LIST attribute for the $MFT file
> 5.3/AV:L/AC:H/PR:H/UI:N/S:C/C:N/I:H/A:N
>
> There is an out-of-bounds write in grub-core/fs/ntfs.c. An attacker may
> leverage this vulnerability by presenting a specially crafted NTFS filesystem
> image leading to GRUB's heap metadata corruption. Additionally, in some
> circumstances, the attack may also corrupt the UEFI firmware heap metadata.
> As a result arbitrary code execution and secure boot protection bypass may
> be achieved.
>
> Reported-by: Maxim Suhanov
>
> *******************************************************************************
>
> CVE-2023-4693 grub2: OOB read when reading data from the resident $DATA attribute
> 5.3/AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
>
> There is an out-of-bounds read at grub-core/fs/ntfs.c. A physically present
> attacker may leverage that by presenting a specially crafted NTFS file system
> image to read arbitrary memory locations. A successful attack may allow
> sensitive data cached in memory or EFI variables values to be leaked presenting
> a high confidentiality risk.
>
> Reported-by: Maxim Suhanov
>
> *******************************************************************************
>
>  grub-core/fs/ntfs.c | 121 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------------
>  1 file changed, 105 insertions(+), 16 deletions(-)
>
> Maxim Suhanov (6):
>       fs/ntfs: Fix an OOB write when parsing the $ATTRIBUTE_LIST attribute for the $MFT file
>       fs/ntfs: Fix an OOB read when reading data from the resident $DATA attribute
>       fs/ntfs: Fix an OOB read when parsing directory entries from resident and non-resident index attributes
>       fs/ntfs: Fix an OOB read when parsing bitmaps for index attributes
>       fs/ntfs: Fix an OOB read when parsing a volume label
>       fs/ntfs: Make code more readable

The two issues are described in more detail in the individual commits:

> Subject: [SECURITY PATCH 1/6] fs/ntfs: Fix an OOB write when parsing the $ATTRIBUTE_LIST attribute for the $MFT file
> Date: Tue,  3 Oct 2023 19:12:23 +0200
>
> From: Maxim Suhanov <dfirblog () gmail com>
>
> When parsing an extremely fragmented $MFT file, i.e., the file described
> using the $ATTRIBUTE_LIST attribute, current NTFS code will reuse a buffer
> containing bytes read from the underlying drive to store sector numbers,
> which are consumed later to read data from these sectors into another buffer.
>
> These sectors numbers, two 32-bit integers, are always stored at predefined
> offsets, 0x10 and 0x14, relative to first byte of the selected entry within
> the $ATTRIBUTE_LIST attribute. Usually, this won't cause any problem.
>
> However, when parsing a specially-crafted file system image, this may cause
> the NTFS code to write these integers beyond the buffer boundary, likely
> causing the GRUB memory allocator to misbehave or fail. These integers contain
> values which are controlled by on-disk structures of the NTFS file system.
>
> Such modification and resulting misbehavior may touch a memory range not
> assigned to the GRUB and owned by firmware or another EFI application/driver.
>
> This fix introduces checks to ensure that these sector numbers are never
> written beyond the boundary.
>
> Fixes: CVE-2023-4692

> Subject: [SECURITY PATCH 2/6] fs/ntfs: Fix an OOB read when reading data from the resident $DATA attribute
> Date: Tue,  3 Oct 2023 19:12:24 +0200
>
> From: Maxim Suhanov <dfirblog () gmail com>
>
> When reading a file containing resident data, i.e., the file data is stored in
> the $DATA attribute within the NTFS file record, not in external clusters,
> there are no checks that this resident data actually fits the corresponding
> file record segment.
>
> When parsing a specially-crafted file system image, the current NTFS code will
> read the file data from an arbitrary, attacker-chosen memory offset and of
> arbitrary, attacker-chosen length.
>
> This allows an attacker to display arbitrary chunks of memory, which could
> contain sensitive information like password hashes or even plain-text,
> obfuscated passwords from BS EFI variables.
>
> This fix implements a check to ensure that resident data is read from the
> corresponding file record segment only.
>
> Fixes: CVE-2023-4693

Alexander