Bug 579475 - (CVE-2010-0624) VUL-0: CVE-2010-0624: tar,cpio: heap based overflow in tar/cpio "rmt"
(CVE-2010-0624)
VUL-0: CVE-2010-0624: tar,cpio: heap based overflow in tar/cpio "rmt"
Status: RESOLVED FIXED
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: General
unspecified
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Security Team bot
Security Team bot
wait_qa maint:released:11.0:31863 m...
:
Depends on:
Blocks: 608034
  Show dependency treegraph
 
Reported: 2010-02-12 12:25 UTC by Marcus Meissner
Modified: 2023-01-20 08:43 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Meissner 2010-02-12 12:25:09 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/
Comment 4 Michal Seben 2010-02-15 16:31:16 UTC
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)
Comment 5 Michal Seben 2010-02-15 16:33:29 UTC
so, we have to fix "rmt" application in star package
Comment 6 Michal Seben 2010-02-22 14:56:29 UTC
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)
Comment 7 Marcus Meissner 2010-02-22 16:17:41 UTC
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.
Comment 8 Michal Seben 2010-02-25 10:08:31 UTC
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
Comment 9 Marcus Meissner 2010-02-25 10:57:24 UTC
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.
Comment 10 Michal Seben 2010-02-25 12:53:46 UTC
(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
Comment 11 Marcus Meissner 2010-02-25 12:55:43 UTC
can you tell that to upstream (as far as the original reporter also told them)?
Comment 12 Michal Seben 2010-02-25 13:24:45 UTC
ok 
when this bug will be marked as public, I will ask to upstream
Comment 13 Michal Seben 2010-02-25 13:34:22 UTC
Sergey Poznyakoff <gray@gnu.org.ua> is upstream, his answer is in Comment 1
could I contact him before CRD date directly ?
Comment 14 Marcus Meissner 2010-02-25 13:37:27 UTC
sounds like a good idea, please do
Comment 15 Michal Seben 2010-03-01 12:20:35 UTC
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
Comment 16 Michal Seben 2010-03-05 18:35:03 UTC
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)
Comment 17 Sebastian Krahmer 2010-03-10 13:53:04 UTC
Bug went public via full-disclosure.
Comment 18 Michal Seben 2010-03-10 20:36:50 UTC
ok, I created submitrequests against rest products (11.0,11.1,11.2,Factory) for tar and cpio packages
Comment 19 Ludwig Nussel 2010-03-11 12:15:39 UTC
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.
Comment 20 Swamp Workflow Management 2010-04-30 07:20:24 UTC
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)
Comment 21 Ludwig Nussel 2010-04-30 07:33:38 UTC
released
Comment 22 Swamp Workflow Management 2010-05-02 12:11:34 UTC
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)
Comment 23 Swamp Workflow Management 2010-05-02 12:11:50 UTC
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)
Comment 24 Swamp Workflow Management 2010-05-02 12:12:07 UTC
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)
Comment 25 Swamp Workflow Management 2010-05-03 11:25:51 UTC
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)
Comment 26 Swamp Workflow Management 2010-05-03 11:26:09 UTC
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)
Comment 27 Swamp Workflow Management 2010-05-03 11:26:42 UTC
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)
Comment 28 Bernhard Wiedemann 2016-04-15 10:46:55 UTC
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