Bugzilla – Bug 579475
VUL-0: CVE-2010-0624: tar,cpio: heap based overflow in tar/cpio "rmt"
Last modified: 2023-01-20 08:43:01 UTC
not public, via direct contact, CRD 2010/03/10 Resent-Message-Id: <201002121221.o1CCLLUw021254@verein.lst.de> Date: Fri, 12 Feb 2010 10:48:05 +0100 From: Jakob Lell <jakob@cs.tu-berlin.de> User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) To: Sergey Poznyakoff <gray@gnu.org.ua> Cc: Robert Buchholz <rbu@gentoo.org>, Nico Golde <nion@debian.org>, Kees Cook <kees@ubuntu.com>, Jan Lieskovsky <jlieskov@redhat.com>, Marcus Meissner <mm@lst.de>, Oden Eriksson <oeriksson@mandriva.com> Subject: CVE-2010-0624: Heap-based buffer overflow in GNU Tar and GNU Cpio Resent-From: mm@lst.de Resent-Date: Fri, 12 Feb 2010 13:21:21 +0100 Resent-To: meissner@suse.de Hi, I am writing this mail to Sergey Poznyakoff <gray@gnu.org.ua> from the GNU Tar and GNU Cpio projects, Robert Buchholz <rbu@gentoo.org> from Gentoo, Nico Golde <nion@debian.org> from Debian, Kees Cook <kees@ubuntu.com> from Ubuntu, Jan Lieskovsky <jlieskov@redhat.com> from Redhat, Marcus Meissner <mm@lst.de> from Suse and Oden Eriksson <oeriksson@mandriva.com> from Mandriva. Please confirm me that you have received this email. I'd suggest to do a coordinated release of security updates for Linux Distributions and a new version of Tar/Cpio on the GNU page on 2009/03/10. Please tell me if this date is ok for you. I'm going to post my advisory to bugtraq on the release date. Here is a preliminary version of the advisory: Problem description: The rmt (remote mag tape protocol) client implementation of GNU Tar/Cpio contains a heap-based buffer overflow which possibly allows arbitrary code execution. The vulnerability is in the function rmt_read in lib/rtapelib.c: /* Read up to LENGTH bytes into BUFFER from remote tape connection HANDLE. Return the number of bytes read on success, SAFE_READ_ERROR on error. */ size_t rmt_read__ (int handle, char *buffer, size_t length) { char command_buffer[COMMAND_BUFFER_SIZE]; size_t status; size_t rlen; size_t counter; sprintf (command_buffer, "R%lu\n", (unsigned long) length); if (do_command (handle, command_buffer) == -1 || (status = get_status (handle)) == SAFE_READ_ERROR) return SAFE_READ_ERROR; for (counter = 0; counter < status; counter += rlen, buffer += rlen) { rlen = safe_read (READ_SIDE (handle), buffer, status - counter); if (rlen == SAFE_READ_ERROR || rlen == 0) { _rmt_shutdown (handle, EIO); return SAFE_READ_ERROR; } } return status; } The function first writes to the server how many bytes it wants to read using sprintf() and do_command(). Then it reads the number of bytes available into the variable status using get_status(). In the for loop, the function reads status bytes from the server into the buffer. However, it doesn't check whether status is actually less than or equal the length of the buffer (which is given in the parameter length). So a malicious rmt server can overwrite data on the heap following the buffer. Successful exploitation of this could possibly lead to arbitrary code execution. Attack vector: This problem can of course be exploited when using an untrusted/compromised rmt server. This is not that a big problem since rmt is relatively rarely used today and the rmt server is in most cases considered trustworthy. However, this vulnerability can also be triggered when trying to extract a tar file with a colon in the filename. In this case, tar interprets the part before the colon as a hostname (or user@hostname) and opens a rsh connection to this host. This may also be exploited if the user uses the aunpack script from atool [1] to extract a tar file. Many users of GNU Tar or atool don't know that rmt exists and that tar treats filenames containing a colon differently. So a user might run tar or aunpack on a file which he has received via email or downloaded from a web page. Many users enter filenames using bash auto-completion and thus might not even notice that there is anything wrong with the filename. For Cpio, this attack vector does not work since Cpio requires the option --rsh-command to use rmt. Tar has /usr/bin/rsh compiled in as default value. It is also possible that there are scripts out there which automatically call Tar to extract a file with a name provided by an untrusted source. This is not a problem if the script passes the filename with an (absolute or relative) path or uses the --force-local option. Notes on rsh/ssh: GNU Tar uses /usr/bin/rsh to execute the rmt server implementation (/usr/bin/rmt) on the server. On most modern linux systems /usr/bin/rsh is just a symlink to ssh. So an attempt to exploit this vulnerability might make ssh ask the user whether to add a new key to the known_hosts file. This gives users the possibility to cancel the program and thus prevent successful exploitation. However, the problem can still be exploited if the attacker has compromised a machine which is already in the users known_hosts file or if the user has set StrictHostKeyChecking to "no" in his ssh configuration. Regards Jakob Lell [1] atool is a script for managing file archives of various types http://www.nongnu.org/atool/
in our (sles/opensuse) case only package "star" - provides/contains "rmt" binary star,cpio and dump packages, in our case, doesn't contain rmt binary ( but of course they could use it)
so, we have to fix "rmt" application in star package
argh .. i read this bug report again and I am little bit confused,please ignore my previous posts the problematic (or exploitable) part of code is included in client parts (tar and cpio binaries), this piece of code, could be abused when we connect to untrusted/compromised server which contain modified rmt binary But I don't understand, how could fix svn patch from Comment 1 this issue - this patch contain only fix for rmt code from server part, and this issue is about compromised server part - (exploitable) client part stayed untouched: :http://git.savannah.gnu.org/cgit/paxutils.git/log/lib/rtapelib.c I could reproduce this bug using two machines, after disabling firewall Marcus: are there any other informations about this bug ? could I contact Sergey Poznyakoff about this topic ? (I see this bug is not public)
as far as I understand: tar xf HOSTNAME: reads the tar file from $HOSTNAME, by using lib/rtapelib.c. Thats why the fix to rmt_read() fixes this issue. (lib/rtapelib.c is used for both "tar" and "rmt"). similar for cpio I guess.
how I understand this issue : LOCAL123:~ #tar xf REMOTE123: -starts tar on LOCAL123, -then tar use rsh connection to start /usr/libexec/rmt on REMOTE123 (fnc rmt_open__), -using rmt_read__ (rtapelib.c) we read output from remote connection from rmt, if rmt binary on REMOTE123 is modified it could "send" malicious information about buffer size to LOCAL123,so we could abuse security bug in rmt_read__ (in tar on LOCAL123) This problem can of course be exploited only when using an untrusted/compromised rmt server, in this case LOCAL123 > > reads the tar file from $HOSTNAME, by using lib/rtapelib.c. Thats why the fix > to rmt_read() fixes this issue. (lib/rtapelib.c is used for both "tar" and > "rmt"). > rmt_read__ is not fixed see git (still the same code): http://git.savannah.gnu.org/cgit/paxutils.git/tree/lib/rtapelib.c patch from Comment 1 (bottom last line in comment) http://git.savannah.gnu.org/cgit/paxutils.git/commit/?id=23f51327 fix only rmt.c code which is used to build rmt binary - and in this bug we are replacing rmt binary with malicious code, as you see on Comment 3
it can be exploited if you can specify the filename that is passed to "tar" and that would contain ":" ... so it should not be directly exploitable I hope. not sure what the NEEDINFO meissner is for, but all packages will need the fix I think.
(In reply to comment #9) > it can be exploited if you can specify the filename that is passed to "tar" and > that would contain ":" ... so it should not be directly exploitable I hope ok i will prepare fix (I want just say, that update to newer tar,cpio or svn code doesn't fix this issue) > > > not sure what the NEEDINFO meissner is for, but all packages will need the fix > I think. sorry for NEEDINFO
can you tell that to upstream (as far as the original reporter also told them)?
ok when this bug will be marked as public, I will ask to upstream
Sergey Poznyakoff <gray@gnu.org.ua> is upstream, his answer is in Comment 1 could I contact him before CRD date directly ?
sounds like a good idea, please do
I send mail to Sergey as you suggest and I received answer today, it's pretty quick : >Thank you. I have installed this patch: > http://git.savannah.gnu.org/cgit/paxutils.git/commit/?id=9bc39283 I checked this diff and now fix looks ok for me, according to previous posts i think we should fix cpio and tar package, affected are all products, in next few days, I will prepare fix
1,ok i prepared fixes for tar and cpio packages for all affected products but i created submit request only against SLE products, this bug is not public so I can't use open buildservice, I will create sr for openSUSE products after CRD 2010/03/10 2,we have few planned updates for cpio package for sles9 (bnc#371077,bnc#367575) so I suppose we will release them together (anja added to CC)
Bug went public via full-disclosure.
ok, I created submitrequests against rest products (11.0,11.1,11.2,Factory) for tar and cpio packages
ok. thanks. However, since for cpio one must explicitly enable the option to use rmt let's queue that up until something else justifies a cpio update.
Update released for: tar, tar-debuginfo, tar-debugsource, tar-lang Products: openSUSE 11.0 (debug, i386, ppc, x86_64) openSUSE 11.1 (debug, i586, ppc, x86_64) openSUSE 11.2 (debug, i586, x86_64)
released
Update released for: tar, tar-debuginfo, tar-debugsource Products: SLE-DEBUGINFO 11 (i386, ia64, ppc64, s390x, x86_64) SLE-DESKTOP 11 (i386, x86_64) SLE-SERVER 11 (i386, ia64, ppc64, s390x, x86_64)
Update released for: tar Products: Novell-Linux-POS 9 (i386) Open-Enterprise-Server 9 (i386) SUSE-CORE 9 (i386, ia64, ppc, s390, s390x, x86_64)
Update released for: tar Products: SLE-DESKTOP 10-SP3 (i386, x86_64) SLE-SAP-APL 10-SP3 (x86_64) SLE-SERVER 10-SP3 (i386, ia64, ppc, s390x, x86_64)
Update released for: cpio Products: Novell-Linux-POS 9 (i386) Open-Enterprise-Server 9 (i386) SUSE-CORE 9 (i386, ia64, ppc, s390, s390x, x86_64)
Update released for: cpio, cpio-debuginfo, cpio-debugsource, cpio-lang Products: SLE-DEBUGINFO 11 (i386, ia64, ppc64, s390x, x86_64) SLE-DESKTOP 11 (i386, x86_64) SLE-SERVER 11 (i386, ia64, ppc64, s390x, x86_64)
Update released for: cpio, cpio-debuginfo Products: SLE-DEBUGINFO 10-SP3 (i386, ia64, ppc, s390x, x86_64) SLE-DESKTOP 10-SP3 (i386, x86_64) SLE-SAP-APL 10-SP3 (x86_64) SLE-SERVER 10-SP3 (i386, ia64, ppc, s390x, x86_64)
This is an autogenerated message for OBS integration: This bug (579475) was mentioned in https://build.opensuse.org/request/show/34544 11.1:Test / tar https://build.opensuse.org/request/show/34545 11.2:Test / tar https://build.opensuse.org/request/show/34548 Factory / tar https://build.opensuse.org/request/show/34550 Factory / cpio https://build.opensuse.org/request/show/34595 11.0:Test / tar https://build.opensuse.org/request/show/45476 11.1 / cpio https://build.opensuse.org/request/show/45477 11.2:Test / cpio