First published: Mon Oct 29 2007(Updated: )
Jim Meyering found: Assuming an attacker can induce a victim user to copy files created by the attacker, most versions of cp can be abused in such a way that cp unexpectedly overwrites or creates an arbitrary, attacker-chosen file using data provided by the attacker. Of course, the target file must be writable by the user running cp. No release of GNU cp has been vulnerable since fileutils-4.1.2 (released in Nov 2001). The first trick is to arrange to copy two files with the same basename to a single destination: rm -rf a b c; mkdir a b c && > a/1 && > b/1 && cp a/1 b/1 c But by itself, that doesn't accomplish anything notable. However, when symlinks are preserved (add -R -P for Solaris, just -R for HP/UX and *BSD), the first file copied is a symlink (pointing to the target file) and a later file (same basename and same dest dir) contains the desired payload, and it's copied through the symlink that has just been created in the destination directory, you've accomplished the exploit. Here are actual examples: [Note: in the first example, I demonstrate the exploit by writing to the file named "target" in the current directory, but it could just as easily have been /etc/passwd (assuming root is the victim). The Solaris example demonstrates how to overwrite an existing file, $HOME/target. ] NetBSD 1.6: (note the order of arguments to cp, since the 2nd is copied before the first) netbsd$ rm -rf a b c; mkdir a b c && echo payload > b/1 && \ ln -s target a/1 && /bin/cp -R b/1 a/1 c; cat c/target payload FreeBSD 5.0 and 6.1 work the same as above OpenBSD 3.9 is vulnerable in the same way. Solaris 5.10: (note: contrary to above, a/1 can't be a dangling symlink, and here, the arguments are processed in the expected order) solaris$ rm -rf a b c; mkdir a b c && echo payload > b/1 \ && ln -s $HOME/target a/1 && > a/1 && /bin/cp -RP a/1 b/1 c solaris$ cat $HOME/target payload HP/UX 10.20, 11.11, 11.23, 11.31: vulnerable via "/bin/cp -R", with behavior just like that seen on Solaris. In the above examples, it's easy to see that there's a risk of funny business, because of the explicit source file names. But imagine that some user requests of root to copy all files from two of his/her directories to some other directory -- and supplies this command cp -R a/* b/* /some/acceptable/looking/dest/dir Then, the offending symlink and payload files may be obscured by hundreds of other files. And a naive victim, seeing that the user in question owns both source directories, and that the destination directory is inoffensive, might just run the command. Thus writing e.g., any or all of /etc/passwd, /etc/shadow, /root/.profile, etc. Currently embargoed
Affected Software | Affected Version | How to fix |
---|---|---|
GNU Core Utilities cp | >4.1.2 | |
NetBSD cp | ||
FreeBSD cp | >=5.0<=6.1 | |
OpenBSD cp | ||
Solaris cp | ||
HP/UX cp | >=10.20<11.32 |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
The severity of REDHAT-BUG-356471 is high due to its potential for unauthorized file overwriting by an attacker.
To fix REDHAT-BUG-356471, update the affected cp versions to the latest secure versions provided by your operating system vendor.
REDHAT-BUG-356471 affects versions of cp from GNU Core Utilities starting from 4.1.2 and certain versions in FreeBSD, HP/UX, and other operating systems.
Yes, exploiting REDHAT-BUG-356471 can lead to data loss as it can overwrite or create arbitrary files without the user's consent.
A potential workaround for REDHAT-BUG-356471 is to avoid using the cp command to copy untrusted files until the vulnerability is patched.