I recently completed a round of bug hunting in Linux filesystems, where I found a series of mostly minor security issues. Filesystems are a great place to start looking for kernel bugs, since the code is relatively easy to understand and review. I discovered and reported issues in btrfs (CVE-2010-1636), ext4 (CVE-2010-2066), gfs2 (CVE-2010-1641, CVE-2010-2525), and xfs (CVE-2010-2226).
btrfs features an ioctl called btrfs_clone_file, which creates an on-disk copy of a file after being passed a file descriptor to that file. In this case, the ioctl did not check that the file descriptor was opened for reading, allowing a user to clone a file that had been opened write-only (and subsequently read it).
Back in 2009, it was discovered that the ext4_move_extents ioctl was vulnerable to a serious issue (CVE-2009-4131) that allowed copying arbitrary contents into arbitrary files. I found a less severe issue in the same ioctl – while the code had been corrected to prevent writing to files without write permissions, there was no check to see if the donor file had been flagged append-only. Using this, a user could overwrite append-only files from the beginning.
The first bug (CVE-2010-1641) was simple – gfs2 did not check ownership of files before setting extended flags (such as append-only, immutable, etc.), allowing any user to set these flags for any file.
The second bug (CVE-2010-2525) was far more serious, but difficult to identify in the code. On 2.6.32 kernels, gfs2 allowed any user to set ACLs for any file, completely bypassing all file permissions. To make things more difficult, there was also a bug causing erroneous ACL behavior, which was pinned down as being due to a failure to properly update inode permissions when applying an ACL.
My final bug from this series is essentially identical to the issue in btrfs. xfs supports an ioctl called XFS_SWAPEXT that swaps the data forks of two files on disk. Like btrfs, no checking for read permissions was performed, allowing a user to copy a write-only file owned by another user and subsequently read it.
Diving into fs/ was a great learning experience for me. For those interested in doing work in this area, I definitely recommend focusing on extended attributes, flags, and ACLs, since these features often seem to be included as an afterthought and are often not rigorously tested. Ioctls are worth auditing, since they provide a direct interface for the user to interact with kernel code. Sometimes, an ioctl interface for a particular piece of filesystem functionality has not been audited as thoroughly as the traditional vfs code paths.
This entry was posted on Saturday, July 10th, 2010 at 10:49 am and is filed under Kernel, Linux. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.