In the e2fsck utility supplied as part of the package , (), which allows you to execute an attacker's code when checking a file system containing specially designed directories. The vulnerability was confirmed in releases 1.43.3 to 1.45.4. Vulnerability fixed in update . In distribution kits the problem still remains uncorrected (, , , , ).
The vulnerability is caused by an error in the mutate_name() function in the rehash.c file, which is used when rebuilding the hash tables associated with a directory, ensuring that all files in the directory are matched to the directory. Corruption of the hash_entry structure associated with a directory could result in an attacker writing data to an area outside the allocated buffer. If several files with the same name are identified in the hash table as being linked to a directory, the e2fsck utility renames the duplicate files by adding ~0, ~1, etc. to the name. To temporarily store the new name during such a renaming, a buffer of 256 bytes in size is allocated on the stack.
The size of the data to be copied is determined by the expression "entry->name_len & 0xff", but the value of entry->name_len is loaded from a structure on disk rather than calculated from the actual size of the name. If the size is zero, then the array index takes the value -1 and conditions are created for integer overflow through the lower boundary of the buffer (integer underflow) and overwriting other data on the stack with the value β~0β. For 64-bit systems, exploitation of the vulnerability is assessed as unlikely and requires no restrictions on the stack size (ulimit -s unlimited). For 32-bit systems, exploitation is considered possible, but the result is highly dependent on how the executable was compiled by the compiler.
To carry out an attack, an attacker needs to corrupt the data in a certain way in the partition with the ext2, ext3 or ext4 file system. Since this operation requires superuser privileges, the vulnerability poses a threat when the e2fsck utility scans external drives or externally received FS images.
Source: opennet.ru