Page History

...

A security flaw exists in the code shown below resulting from the absence of proper canonicalization measures on the file path. This allows an attacker to traverse the filesystem and possibly write to a file of his choice, with the privileges of the vulnerable program. For example, it maybe possible to overwrite the password file (such as the /etc/passwd, common to many POSIX based systems) or a device file such as the mouse which in turn can aid further exploitation or cause a denial of service to occur.

/*  Program running with elevated privileges where argv[1] is supplied by the user */

FILE *fp = fopen(argv[1],"w");     

/*  argv[2] is also specified by the user and may be "foo:*:100:200:8A-74(home):/home/foo:/usr/bin/sh"; 
 *  or some other specially crafted input  
 */

char x[100];
strncpy(x,argv[2],100);
x[100] = '\0';

fwrite(x, sizeof(x[0]), sizeof(x)/sizeof(x[0]), fp);   /*  Write operation to an unintended file like /etc/passwd gets executed  */

...

The chdir() system call may be susceptible to a race condition if called before chroot(). This is because an attacker with sufficient privileges can delete the 'jail' directory so that the chdir() operation fails and then recreate it so that chroot() succeeds. Consequently, the program will not start in its sandboxed environment (~/chroot/jail) and will not have its current working directory not set to ~/chroot/jail. One mitigation strategy is to incorporate error checking to detect if chdir() failed. A more fool proof method is to use chdir() after chroot() so that it guarantees that the current working directory will be set to the chroot'ed directory, that is the new root.

...

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

\[[Wheeler 03|AA. C References#Wheeler 03]\]