Your message dated Thu, 29 Sep 2005 08:02:07 -0700
with message-id <[EMAIL PROTECTED]>
and subject line Bug#306693: fixed in cpio 2.6-6
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 28 Apr 2005 01:49:29 +0000
>From [EMAIL PROTECTED] Wed Apr 27 18:49:28 2005
Return-path: <[EMAIL PROTECTED]>
Received: from master.debian.org [146.82.138.7]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DQy9g-0001LR-00; Wed, 27 Apr 2005 18:49:28 -0700
Received: from ip024.subnet65.gci-net.com ([127.0.0.1]) [216.183.65.24]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DQy9f-0001dr-00; Wed, 27 Apr 2005 20:49:27 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: [EMAIL PROTECTED]
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: cpio: allows extracting insecure pathnames (leading slash = / and
dotdot =
..)
Cc: [EMAIL PROTECTED], [email protected]
X-Mailer: reportbug 3.8
Date: Wed, 27 Apr 2005 18:47:41 -0700
X-Debbugs-Cc: [EMAIL PROTECTED]
Message-Id: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-4.9 required=4.0 tests=BAYES_30,HAS_PACKAGE,
NO_REAL_NAME,OUR_MTA_MSGID,X_DEBBUGS_CC autolearn=no
version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
Package: cpio
Version: 2.5-1.2
Severity: normal
Hi,
OK, several related issues here. You probably already see where I am
going, but please humor me for a minute just in case. Not sure if I'm
supposed to file with debian or with cpio's own bug lair.
I believe (IMHO) that this is a security issue and should be fixed
soon. Anybody can create an archive and put it on the net that lots
of trusting people will run cpio -i on to inadvertently write a file
in, say, /etc/cron.daily.
~# touch /etc/cron.daily/aaa
~# find /etc/cron.daily/aaa|cpio -o>a.cpio
1 block
~# \rm -v /etc/cron.daily/aaa
removed `/etc/cron.daily/aaa'
Imagine that that file is buried deep in a huge archive of files with
innocent relative pathnames, and was made executable first. Now the
unsuspecting user (who should, but does not, know better), does this:
~# cpio -t < a.cpio
.... lots of innocent files
/etc/cron.daily/aaa
.... lots of innocent files
1 block
~# cpio -i < a.cpio #oops, forgot an option
1 block
And does not do this:
~# ls -l /etc/cron.daily/aaa
-rw------- 1 root root 0 Apr 27 18:23 /etc/cron.daily/aaa
~# \rm -v /etc/cron.daily/aaa
removed `/etc/cron.daily/aaa'
Note that the user should have used the --no-absolute-filenames
option, but did not. So you could say it's preventable. But consider
what happens if the pathname is relative:
~# find ../../../../../../../../../../../../etc/cron.daily/aaa | cpio -o>a.cpio
Now that option will not help. To prevent that requires preprocessing
the archive with cpio -t and grep '\.\.'. How many users do that?
Especially on a large archive?
OK, here are my comments:
First, there is no way that I know of within cpio -o to prohibit
absolute pathnames and .. in a pathname. This is important to flag
mistakes in the input and to prevent somebody who runs cpio -i
(including unfixed versions of cpio) from inadvertently installing
your files in unexpected (i.e. not below pwd) places. IMHO safety
should be the default, but an option would be OK if necessary.
Prohibiting ^/ and \.\. is easy in a shell, but it should be built in
to make error handling easier. Of course, this doesn't solve the
security problem. It just avoids mistakes.
Second, more importantly, cpio -o does not by default prohibit
absolute filenames. The option --no-absolute-filenames is an OK
workaround, but IMHO it should be the default.
Third, even more importantly, cpio -o does not by default or via an
option appear to check for .. in pathnames. Using .. in the archive
is rarely needed, and IMHO it should be disallowed by default. At
least, it should be an option. (If it is disallowed by default, a nop
option to disallow should probably still be provided so that other
versions of cpio will (ideally) balk at an unrecognized option,
tipping the user to be more careful.)
Finally, I have a related wishlist item, which is an option to cpio -o
archives in which all pathnames, whether relative or absolute, are
converted to fully canonical (but NOT symlink-dereferenced unless -L
is used) relativized absolute pathnames. By this I mean that cpio -o
with this option should canonicalize relative paths into absolute
paths, but remove the leading / (except for /, of course). This
ensures best safety for unsuspecting cpio -i users, and is a commonly
needed uniform format.
It might be argued that --canonical should be up to the pipeline that
calls cpio -o, but in practice, getting these safety and security
issues right in all cases, including when NULs delimit files, and
including portability concerns, is nontrivial.
I am aware that these issues often apply to other archivers also, but
have not filed reports there. Over the years they have slowly been
addressing some of them, but not all of them.
I'd like a CC:/BCC: on any and all discussion about this topic, if
possible.
Thanks. And thanks for cpio; it is my favorite archiver.
gmail ! gambarimasu+reportbug
P.S. There is another can of worms, which I won't open (much) for
symlinks (e.g. the -L option) and ancillary issues like overwriting of
existing files, trailing slash, and the known issue of what to do for
directories that come after the files in the directories. For
example, normally we want symlinks not to be dereferenced, so
canonicalizing .. must not also do that by default. People want a
variety of things here, so the more orthogonality the better. For
example, most of the time we want /home/me/mysymlink/mydir/myfile to
be archived with the mysymlink intact, and /home/me/mysymlink to be
archived simply as a symlink, but some people might want defined (in
the man page) behavior for trailing slash, such as archiving the
referent if there is a trailing slash. Of course, it would be nice if
find had options to control some of these things without preprocessing
of the command line and postprocessing of the output. Overall, I
would like to see a bit more documentation in the cpio man page that
defines what happens if, e.g. a non-writable dir is extracted before
its files (e.g. just how critical is it that cpio -i be called with
find -depth or find | sort -r), or a trailing slash is used. All of
these issues are related in one way or another.
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages cpio depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
-- no debconf information
---------------------------------------
Received: (at 306693-close) by bugs.debian.org; 29 Sep 2005 15:08:14 +0000
>From [EMAIL PROTECTED] Thu Sep 29 08:08:12 2005
Return-path: <[EMAIL PROTECTED]>
Received: from katie by spohr.debian.org with local (Exim 3.36 1 (Debian))
id 1EKzvD-0003yB-00; Thu, 29 Sep 2005 08:02:07 -0700
From: Clint Adams <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
X-Katie: $Revision: 1.56 $
Subject: Bug#306693: fixed in cpio 2.6-6
Message-Id: <[EMAIL PROTECTED]>
Sender: Archive Administrator <[EMAIL PROTECTED]>
Date: Thu, 29 Sep 2005 08:02:07 -0700
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-CrossAssassin-Score: 2
Source: cpio
Source-Version: 2.6-6
We believe that the bug you reported is fixed in the latest version of
cpio, which is due to be installed in the Debian FTP archive:
cpio_2.6-6.diff.gz
to pool/main/c/cpio/cpio_2.6-6.diff.gz
cpio_2.6-6.dsc
to pool/main/c/cpio/cpio_2.6-6.dsc
cpio_2.6-6_sparc.deb
to pool/main/c/cpio/cpio_2.6-6_sparc.deb
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [EMAIL PROTECTED],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Clint Adams <[EMAIL PROTECTED]> (supplier of updated cpio package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [EMAIL PROTECTED])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Format: 1.7
Date: Thu, 29 Sep 2005 10:22:52 -0400
Source: cpio
Binary: cpio
Architecture: source sparc
Version: 2.6-6
Distribution: unstable
Urgency: critical
Maintainer: Clint Adams <[EMAIL PROTECTED]>
Changed-By: Clint Adams <[EMAIL PROTECTED]>
Description:
cpio - GNU cpio -- a program to manage archives of files
Closes: 305372 306693
Changes:
cpio (2.6-6) unstable; urgency=critical
.
* Forward-port Martin Pitt's security patch from Ubuntu:
- SECURITY UPDATE: Modify permissions of arbitrary files, path traversal.
- copyin.c, copypass.c: Use fchmod() and fchown() before closing the output
file instead of chmod() and chown() after closing it. This avoids
exploiting this race condition with a hardlink attach to chmod/chown
arbitrary files. [CAN-2005-1111]. closes: #305372.
- copyin.c: Separate out path sanitizing to safer_name_suffix(): Apart from
leading slashes, filter out ".." components from output file names if
--no-absolute-filenames is given, to avoid path traversal.
[CAN-2005-1229]
closes: #306693.
Files:
e1fb620aa56b17bfbe8f70876b3203a3 547 utils important cpio_2.6-6.dsc
2be1de38e402b437d2837bccf8d45c2a 102926 utils important cpio_2.6-6.diff.gz
cc3987982fb748d7929582a5c5d136f7 126126 utils important cpio_2.6-6_sparc.deb
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Debian!
iD8DBQFDO/3Z5m0u66uWM3ARAoaAAJ9IUw1h5OJNWhyZotEwvI4llUWVBgCfftMJ
NsZ43q1jkoaausRC9t5S9qY=
=YrrY
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
