Date: Thu, 08 Jan 2015 02:43:27 +0300 From: Alexander Cherepanov <cherepan@...me.ru> To: oss-security@...ts.openwall.com Subject: Directory traversals in cpio and friends? Hi! I've taken a look at how dir traversals are dealt with in several implementations of tar and cpio. The picture is kinda strange. First of all, I believe it's usually agreed that archivers must not touch files outside the current directory by default. Is there an authoritative link for this? Then, it seems there are 3 main ways to exploit dir traversals in through archives: 1) via absolute paths, the column 'abs' below; 2) via relative paths with '..', the column 'rel' below; 3) via symlinks to directories, the column 'link' below. Software: 1) GNU tar and cpio, called 'tar' and 'cpio' below, tested versions from Debian jessie and git head; 2) BSD tar and cpio (based on libarchive), called 'bsdtar' and 'bsdcpio' below, tested versions from Debian jessie and git head; 3) OpenBSD-derived(?) pax, with tools called 'paxtar', 'paxcpio' and 'pax' below, tested versions from Debian jessie and FreeBSD 10.0-RELEASE-p12. The results of tests of tar and cpio archives against various commands follow. '=' means that the corresponding file is not extracted, 'x' means that it is extracted. IMHO secure configuration should list three '=', insecure configuration should list three 'x', everything else is inconsistent. The list created by the attached scripts. === tar === abs rel link cmd = = = tar -x x x x tar -x -P = = = bsdtar -x x x x bsdtar -x -P = x x paxtar -x x x x paxtar -x -P x x x pax -r === cpio === abs rel link cmd x x x cpio -i = = x cpio -i --no-absolute-filenames x = = bsdcpio -i x x x bsdcpio -i --insecure x x x paxcpio -i tar and bsdtar are ok. Good. But not much. Question 1. Perhaps there are some reasons why all cpio variants (unlike tar) extract files with absolute paths by default? Question 2. BSD folks which are behind pax* tools don't consider directory traversal a vulnerability, do they? The only 'x' in the line for `cpio -i --no-absolute-filenames` seems to be a clear vuln. Reported here: https://bugs.debian.org/774669 and now sent to upstream ml. -- Alexander Cherepanov #!/bin/sh type=$1 shift dir=`mktemp -d` cd $dir # Prepare test archive (hope paths will not be mangled). # Assume that `mktemp` creates files in /tmp/ . ln -s /tmp dir abs=`mktemp` rel=`mktemp` link=`mktemp` if [ "$type" = cpio ]; then echo "\ $abs ../`basename $rel` dir dir/`basename $link`" | cpio -o > arc 2> /dev/null else tar -cPf arc $abs ../`basename $rel` dir dir/`basename $link` fi rm $abs $rel dir $link # Extract if [ "$type" = cpio ]; then "$@" < arc else "$@" -f arc fi 2> /dev/null for file in $abs $rel $link; do if [ -f "$file" ]; then printf -- "x " rm "$file" else printf -- "= " fi done echo "$@" cd - > /dev/null rm -r $dir #!/bin/sh echo "=== tar ===" echo "abs rel link cmd" echo '\ tar -x tar -x -P bsdtar -x bsdtar -x -P paxtar -x paxtar -x -P pax -r' | \ while read cmd; do ./test-tar-1.sh tar $cmd done echo echo "=== cpio ===" echo "abs rel link cmd" echo '\ cpio -i cpio -i --no-absolute-filenames bsdcpio -i bsdcpio -i --insecure paxcpio -i' | \ while read cmd; do ./test-tar-1.sh cpio $cmd done
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ