CVE-2020-7468: Turning Imprisonment to Advantage in the FreeBSD ftpd chroot Jail

In July, we received a local privilege escalation bug in FreeBSD from an anonymous researcher. The target is the file transfer protocol daemon (, that is designed to restrict the file system access of authenticated users. The feature is implemented using the “chroot” system call, a security technique commonly known as a “chroot jail”. A chroot jail functions by confining a process to a restricted portion of the filesystem. By exploiting a vulnerability in the implementation, though, an attacker can actually use this imprisoned state to gain an enormous advantage, escalating their privileges from a restricted FTP account to `root`. This allows the attacker to execute arbitrary code on the system. This vulnerability was present in the FreeBSD FTP daemon for a long time. It can be tracked back to FreeBSD 6.3-Release. The bug is assigned as  was released in September.

The Vulnerability

The root cause of the vulnerability is the flawed handling of chroot() inside freebsd/libexec/ftpd/ftpd.c. Here is a simplified version of the vulnerable function:

If an FTP user attempts to log in and is configured to be jailed inside a chroot jail in /etc/ftpchroot, ftpd will call the chroot and chdir syscalls as shown above. If the chdir syscall fails, the code jumps to label bad. In this situation, ftpd still awaits a new login, but the connection is already locked inside the chroot jail. This causes incorrect behavior during the next login attempt on that connection.

Exploitation

In order to force the chdir syscall to fail during login, an attacker can change the permissions on their home directory by using the command chmod 0. Additionally, the attacker would upload a specially prepared file named etc/spwd.db relative to their home directory. This file is a modified password database of a regular FreeBSD system containing a known password for the root user. After a chdir failure, ftpd is locked inside the chroot jail, so that all subsequent file system accesses are made relative to the user’s home folder instead of the true root of the filesystem. As a result, when performing authentication for a subsequent login, ftpd reads the attacker’s spwd.db instead of the legitimate /etc/spwd.db located relative to the true root of the filesystem. At this point, the attacker can log in as root with the known password.
The next step is to upload /etc/pam.d/ftpd and /usr/lib/pam_opie.so.5. The first file forces ftpd to load serval dynamic libraries, including the second file, during the login process. The second file is designed to break the chroot jail with the obtained root permission and execute a reverse shell. Then, the attacker can execute arbitrary code as root.
Here is a summary of the steps of the exploit.

1. Log in as a restricted FTP account.


2. Upload etc/spwd.db containing a known root password.


3. Execute chmod 0.


4. Log in as the restricted FTP account again. During login, chdir fails, leaving the ftpd process locked in the chroot jail.


5. Log in as root with the known password.


6. Upload /etc/pam.d/ftpd and /usr/lib/pam_opie.so.5, which contains a reverse shell.


7. Log in as the restricted FTP account again. As before, chdir fails, leaving the ftpd process locked in the chroot jail.


8. Log in as root with the known password. ftpd executes the reverse shell.

The Patch

To address this vulnerability, FreeBSD made a simple change. If the chdir syscall fails, ftpd will now close the connection immediately.

Conclusion

This is a logic bug for privilege escalation. Because of this, this bug is quite reliable, unlike the FreeBSD privilege escalation we blogged about in , and follow the team for the latest in exploit techniques and security patches.