The product uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.
Improper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process's current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called.
Threat Mapped score: 1.8
Industry: Finiancial
Threat priority: P4 - Informational (Low)
N/A
N/A
| Phase | Note |
|---|---|
| Implementation | REALIZATION: This weakness is caused during implementation of an architectural security tactic. |
Intro: Consider the following source code from a (hypothetical) FTP server:
Body: This code is responsible for reading a filename from the network, opening the corresponding file on the local machine, and sending the contents over the network. This code could be used to implement the FTP GET command. The FTP server calls chroot() in its initialization routines in an attempt to prevent access to files outside of /var/ftproot. But because the server does not change the current working directory by calling chdir("/"), an attacker could request the file "../../../../../etc/passwd" and obtain a copy of the system password file.
chroot("/var/ftproot"); ... fgets(filename, sizeof(filename), network); localfile = fopen(filename, "r"); while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) { fwrite(buf, 1, sizeof(buf), network); } fclose(localfile);