Bug 356471 (CVE-2007-4998) - CVE-2007-4998 cp symlink overwrite
Summary: CVE-2007-4998 cp symlink overwrite
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2007-4998
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-29 14:16 UTC by Mark J. Cox
Modified: 2021-11-12 19:44 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-12-22 22:32:32 UTC
Embargoed:


Attachments (Terms of Use)

Description Mark J. Cox 2007-10-29 14:16:02 UTC
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

Comment 4 Josh Bressers 2008-01-22 19:10:30 UTC
Given the age of this flaw, along with the low severity, I am opening this bug
up to the public.

Comment 5 Tomas Hoger 2008-02-01 15:31:57 UTC
Summary of affected versions of cp shipped in fileutils, coreutils and busybox
packages in Red Hat Enterprise Linux and Fedora:

- fileutils (RHEL2.1 only) - is affected by this problem, but this issue can
  only be used to overwrite existing files, not to create new files

- coreutils
  - RHEL3 - similar to cp version shipped in fileutils package in RHEL2.1, can
    only by used to overwrite existing files;  additionally, warning is printed
    when file is overwritten
  - RHEL4, RHEL5, Fedora - not affected

- busybox
  - RHEL2.1, RHEL3 - affected, cp can be tricked to overwrite existing files or
    create new files
  - RHEL4, RHEL5, F7 - affected, only overwrite of already existing file is
    possible
  - F8 - not affected


Comment 6 Josh Bressers 2008-02-12 18:50:18 UTC
Due to the very low severity of this flaw, and the fact that fixing it changes
how cp works, we don't plan to fix the affected versions.

This flaw is fixed in all packages that ship a cp utility from Fedora 8 onward.


Note You need to log in before you can comment on or make changes to this bug.