mirror of
https://git.FreeBSD.org/src.git
synced 2024-12-19 10:53:58 +00:00
0061238fb0
directory entries that is caused by uninitialized directory entry padding written to the disk. It can be viewed by any user with read access to that directory. Up to 3 bytes of kernel stack are disclosed per file entry, depending on the the amount of padding the kernel needs to pad out the entry to a 32 bit boundry. The offset in the kernel stack that is disclosed is a function of the filename size. Furthermore, if the user can create files in a directory, this 3 byte window can be expanded 3 bytes at a time to a 254 byte window with 75% of the data in that window exposed. The additional exposure is done by removing the entry, creating a new entry with a 4-byte longer name, extracting 3 more bytes by reading the directory, and repeating until a 252 byte name is created. This exploit works in part because the area of the kernel stack that is being disclosed is in an area that typically doesn't change that often (perhaps a few times a second on a lightly loaded system), and these file creates and unlinks themselves don't overwrite the area of kernel stack being disclosed. It appears that this bug originated with the creation of the Fast File System in 4.1b-BSD (Circa 1982, more than 36 years ago!), and is likely present in every Unix or Unix-like system that uses UFS/FFS. Amazingly, nobody noticed until now. This update also adds the -z flag to fsck_ffs to have it scrub the leaked information in the name padding of existing directories. It only needs to be run once on each UFS/FFS filesystem after a patched kernel is installed and running. Submitted by: David G. Lawrence <dg@dglawrence.com> Reviewed by: kib MFC after: 1 week |
||
---|---|---|
.. | ||
dir.c | ||
ea.c | ||
fsck_ffs.8 | ||
fsck.h | ||
fsutil.c | ||
gjournal.c | ||
globs.c | ||
inode.c | ||
main.c | ||
Makefile | ||
Makefile.depend | ||
pass1.c | ||
pass1b.c | ||
pass2.c | ||
pass3.c | ||
pass4.c | ||
pass5.c | ||
setup.c | ||
suj.c | ||
utilities.c |