Onderwerp: tar preserves setuid bit

(essentially the same as the unzip vulnerability CAN-2005-0602 except
that it only works against the root user)

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
tar preserves setuid bit
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D

Software: tar
Version: 1.15.1
Software URL: <www.gnu.org/software/tar/tar.html>
Platform: Unix, Linux.
Severity: Medium

Vulnerable software
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3 D=3D=3D=3D

tar 1.15.1 and previous versions running on unix.

Vulnerability
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

If running as the root user tar restores the original permissions to
extracted files, this includes the setuid bit. No warning is given to
the user that this has happened.

The default behaviour of tar under root is not to change ownership of
the file to root. However owner information is extracted from the tar
file, so a trivialy modified tar file can ensure the owner of the
extracted files is the root user.

This allows for the creation of arbitary setuid executable owned by
the root user if the root user extracts the files from a malliciously
crafted tar file.

---
Imran Ghory

Imran Ghory <imranghory@gmail.com> wrote:
> If running as the root user tar restores the original permissions to
> extracted files, this includes the setuid bit. No warning is given to
> the user that this has happened.

From the default man page for tar:

The owner, modification time, and mode are restored (if possible);

This isn't specific to GNU, it's *expected behaviour* for every version of tar.
In fact, a failure to conform to this behaviour breaks essential functionality
of tar. If the root user doesn't know what this tool does or what it's for,
then don't run it.

What part of 'Tape ARchive' wasn't clear? Would you be happy if your backup and
restore procedures failed to actually restore files in their original condition?
Sheesh.
--
Neil (mckellar@telusplanet.net)

On 8/5/05, Neil McKellar <mckellar@telusplanet.net> wrote:
> Imran Ghory <imranghory@gmail.com> wrote:
> > If running as the root user tar restores the original permissions to
> > extracted files, this includes the setuid bit. No warning is given to
> > the user that this has happened.
>=20
> From the default man page for tar:
>=20
> The owner, modification time, and mode are restored (if possible);
>=20
> This isn't specific to GNU, it's *expected behaviour* for every version o=
f tar.
> In fact, a failure to conform to this behaviour breaks essential functio=
nality
> of tar.=20

I'm not saying that it shouldn't have the behaviour, rather that it
should warn the user.

Howeber the only reason I posted this "bug" was because a number of
unix/linux vendors have decided that the same issue in unzip (which I
cited earlier : CAN-2005-0602) should be considered a vulnerability
and have issued patches to change the behaviour. Hence they may (or
may not) decide to take similar action with tar,

> What part of 'Tape ARchive' wasn't clear? Would you be happy if your bac=
kup and
> restore procedures failed to actually restore files in their original con=
dition?

The number of people who use tar for archival purposes is minimal
compared to those who use it for distribution purposes. Of course you
could argue that misusing an archival tool as a distribution tool is
the source of this potential problem, but the fact is that it is used
for distribution purposes and thus is a potentinal attack vector.

Imran Ghory

On Fri, Aug 05, 2005 at 12:52:50AM +0100, Imran Ghory wrote:
> The default behaviour of tar under root is not to change ownership of
> the file to root. However owner information is extracted from the tar
> file, so a trivialy modified tar file can ensure the owner of the
> extracted files is the root user.
>
> This allows for the creation of arbitary setuid executable owned by
> the root user if the root user extracts the files from a malliciously
> crafted tar file.
>

So what? When using tar to make backups this is what you need.

The default behavior of GNU tar (and others) not to change the ownership
of extracted files to self when running as root is well documented.

The only attack I see in your case is when the attacker is a local user
who gives root a tar with a setuid root program in it and root untars it
in a place where the attacker can run it. While I'm sure such situations
exist, I think they are rare, entirely the fault of the admin, and not
worth changing the default behavior of tar over.

On Fri, 5 Aug 2005, Imran Ghory wrote:

> I'm not saying that it shouldn't have the behaviour, rather that it
> should warn the user.
>
> Howeber the only reason I posted this "bug" was because a number of
> unix/linux vendors have decided that the same issue in unzip (which I
> cited earlier : CAN-2005-0602) should be considered a vulnerability
> and have issued patches to change the behaviour. Hence they may (or
> may not) decide to take similar action with tar,

I thought this was a little different. According to unzip advisory, normal
unzip does this behaviour. But with tar you usually use the -p switch --
so you have to make a simple effort to do the setuid/setgid. Also you'd
need to be root to set it to setuid.

It is not documented well in the gtar manual page:

-p, --same-permissions, --preserve-permissions
extract all protection information

But then I read GNU tar-1.15.1 README which says:

About *security*, it is probable that future releases of `tar' will have
some behavior changed. There are many pending suggestions to choose from.
Today, extracting an archive not being `root', `tar' will restore suid/sgid
bits on files but owned by the extracting user. `root' automatically gets
a lot of special privileges, `-p' might later become required to get them.

I tested and as root it did automatically preserve the setuid and I was
surprised by this behaviour as I had always used -p switch before.

The man page for tar from NetBSD (not gtar) says:

-p, --preserve-permissions, --preserve
Preserve user and group ID as well as file mode regardless
of the current umask(2). The setuid and setgid bits are
only preserved if the user is the superuser. Only meaning-
ful in conjunction with the -x flag.

With NetBSD's tar you are required to use the -p switch.

I don't know when GNU tar changed -- or maybe I had always used some
patched GNU tar that forced this -- but maybe it should expect -p also.

Jeremy C. Reed

BSD News, BSD tutorials, BSD links
http://www.bsdnewsletter.com/