If exploited, these flaws can allow attackers to gain unauthorized access to sensitive information or generally cause problems
A few days ago the news broke that a vulnerability was detected (already listed under CVE-2023-4273) in the driver for the exFAT file system supplied in the Linux kernel.
The problema lies in the fact that the controller allows when mounting a specially designed partition, (for example, by plugging in a malicious USB Flash), hit a stack overflow, and run your code with kernel rights.
The problem is: the code assumes that filename inputs always produce a concatenated filename that fits 255 characters (limit is 258 characters, includes 1 extra character for a null byte and 2 extra characters for conversion) . Storing more than 255 characters of filename in a set of directory entries is a filesystem format violation, but is accepted by the Linux driver, but also causes a stack overflow (because the filename is concatenated into a variable allocated by the stack).
Regarding vulnerability, it is mentioned that, this ands exploited due to size check failure copying a filename to a stack-allocated buffer results in a kernel stack overflow if a very long filename is supplied that exceeds the filesystem limit of 255 characters.
The exfat_extract_uni_name() function stops copying characters to the destination buffer once a null character (0x0000) is encountered and returns the number of characters copied. But the caller ignores the return value and advances the pointer 15 characters (30 bytes) for the next iteration. Therefore, it is possible to skip (leave intact) 14 characters or 28 bytes in one iteration.
Vulnerability is present in a function that performs long name reconstruction cyclically reading records with file name parts from the directory index and merging the resulting name parts into the final long name.
The size check in the code for that function was performed relative to each entry with a name part, but did not cover the final name (for example, the name can be split into 100 parts and reach 1500 characters instead of 258 characters in the buffer).
El investigador who discovered the vulnerability was able to prepare a prototype exploit which allows you to increase your privileges on the system. When tested on a VirtualBox virtual machine, the exploit works 100% of the time, but when run in a normal environment running on top of hardware, the chance of it being triggered drops to about 50%.
In particular, my exploit overwrites a stack-allocated pointer to a null-terminated string, so the following attempt to add a terminating null character to this string actually becomes the primitive "write a null byte to location of memory chosen by the attacker.
It is also mentioned that the vulnerability could be used to compromise kernels booted in UEFI Secure Boot mode, since it mentions that an image containing a vulnerable kernel, with a corresponding init script (and the exploit, of course), which boots before a real operating system, is placed on a bootable drive. When booted, this image loads a malicious (and unsigned) kernel module, which establishes its control over kernel mode and then switches to the real operating system (for example, using the kexec call).
Finally it is worth mentioning that the problem was fixed in the versions of Linux that are still supported. At the time of the vulnerability disclosure, the most current Linux Kernel version was Linux version 6.4.10, but the new version 6.5 already has the fix.
For those interested in tracking the solution in the different distributions, they can do so from the following pages: Debian, Ubuntu, RHEL, SUSE y fedora
If you are interested in knowing more about it, you can check the details in the following link