Zip 2,31 bad default file-permissions vulnerability

[Imran Ghory]

=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
Zip bad default file-permissions vulnerability
=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: Zip
Version: 2.31
Software URL: <http://www.info-zip.org/Zip.html>
Platform: Unix, Linux.
Vulnerability type: File permission, privacy.
Severity: Medium. Allows local user to read files belonging to the
gzip user which they couldn't otherwisre.

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

Zip 2.31 and previous versions running on unix.

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

A zip file created by Zip 2.3.1 has the permissions 644 by default,
Therefore any file compressed becomes world readable.

Particularly at risk are backup systems which zip password files,
databases and other confidential files which are only meant to be
readable by a single user or group.

Workaround
=3D=3D=3D=3D=3D=3D=3D=3D

None at the moment, It should be straightforward to fix in the source
by setting the umask correctly.

--
Imran Ghory

[Lupe Christoph]

Quoting Imran Ghory <imranghory@gmail.com>:
> On 8/4/05, Lupe Christoph <lupe@lupe-christoph.de> wrote:
> > Quoting Imran Ghory <imranghory@gmail.com>:

> > > A zip file created by Zip 2.3.1 has the permissions 644 by default,
> > > Therefore any file compressed becomes world readable.

> > Zip 2.3 works correctly:
> > $ (umask 0; zip test.zip feedlist.opml; ls -l test.zip; rm test.zip)
> > adding: feedlist.opml (deflated 80%)
> > -rw-rw-rw- 1 lupe lupe 3156 Aug 4 10:52 test.zip

> A clarification: Zip obeys the umask, the example I gave was due to
> most unix distributions having a default umask which makes new files
> world readable. Contrast this with gzip/bzip2 which will ignore the
> umask and preserve the permissions of the file being compressed.

You may argue that a default umask of 022 is too permissive, but when
you do, be prepared for a lot of flak.

You should not compare zip to bzip or gzip even though the names are
similar but to tar. What should zip do when you pack multiple files
with differing permissions?

What zip does is entirely correct.

Lupe Christoph
--
| lupe@lupe-christoph.de | http://www.lupe-christoph.de/ |
| "... putting a mail server on the Internet without filtering is like |
| covering yourself with barbecue sauce and breaking into the Charity |
| Home for Badgers with Rabies. Michael Lucas |

[Imran Ghory]

On 8/4/05, Lupe Christoph <lupe@lupe-christoph.de> wrote:
> Quoting Imran Ghory <imranghory@gmail.com>:
>=20
> > A zip file created by Zip 2.3.1 has the permissions 644 by default,
> > Therefore any file compressed becomes world readable.
>=20
> Zip 2.3 works correctly:
> $ (umask 0; zip test.zip feedlist.opml; ls -l test.zip; rm test.zip)
> adding: feedlist.opml (deflated 80%)
> -rw-rw-rw- 1 lupe lupe 3156 Aug 4 10:52 test.zip

A clarification: Zip obeys the umask, the example I gave was due to
most unix distributions having a default umask which makes new files
world readable. Contrast this with gzip/bzip2 which will ignore the
umask and preserve the permissions of the file being compressed.

Imran Ghory

[Lupe Christoph]

Quoting Imran Ghory <imranghory@gmail.com>:

> A zip file created by Zip 2.3.1 has the permissions 644 by default,
> Therefore any file compressed becomes world readable.

Zip 2.3 works correctly:
$ (umask 0; zip test.zip feedlist.opml; ls -l test.zip; rm test.zip)
adding: feedlist.opml (deflated 80%)
-rw-rw-rw- 1 lupe lupe 3156 Aug 4 10:52 test.zip
$ (umask 077; zip test.zip feedlist.opml; ls -l test.zip; rm test.zip)
adding: feedlist.opml (deflated 80%)
-rw------- 1 lupe lupe 3156 Aug 4 10:52 test.zip

HTH,
Lupe Christoph
--
| lupe@lupe-christoph.de | http://www.lupe-christoph.de/ |
| "... putting a mail server on the Internet without filtering is like |
| covering yourself with barbecue sauce and breaking into the Charity |
| Home for Badgers with Rabies. Michael Lucas |

[Stephen C Woods]

One can make a very convincing for umask -the actual definition is
real permission = (~umask & file-permissions), it's easy enough to
modify your .profile/.login/.cshrc to add a line umask 77.

The problem is the zip uses a default mode of 666 (not knowing
anything about permissions by definition -it's a DOS program for Pete's
sake, you know single user file server).

<scw>

On Thu, Aug 04, 2005 at 01:01:23PM +0100, Imran Ghory wrote:
> On 8/4/05, Lupe Christoph <lupe@lupe-christoph.de> wrote:
> > Quoting Imran Ghory <imranghory@gmail.com>:
> >
> > > A zip file created by Zip 2.3.1 has the permissions 644 by default,
> > > Therefore any file compressed becomes world readable.
> >
> > Zip 2.3 works correctly:
> > $ (umask 0; zip test.zip feedlist.opml; ls -l test.zip; rm test.zip)
> > adding: feedlist.opml (deflated 80%)
> > -rw-rw-rw- 1 lupe lupe 3156 Aug 4 10:52 test.zip
>
> A clarification: Zip obeys the umask, the example I gave was due to
> most unix distributions having a default umask which makes new files
> world readable. Contrast this with gzip/bzip2 which will ignore the
> umask and preserve the permissions of the file being compressed.
>
> Imran Ghory
>

--
-----
Stephen C. Woods; UCLA SEASnet; 2567 Boelter hall; LA CA 90095; (310)-825-8614
Unless otherwise noted these statements are my own, Not those of the
University of California. Internet mail:scw@seas.ucla.edu

[Lupe Christoph]

On Thursday, 2005-08-04 at 15:17:35 -0700, Stephen C Woods wrote:

> The problem is the zip uses a default mode of 666 (not knowing
> anything about permissions by definition -it's a DOS program for Pete's
> sake, you know single user file server).

I still don't understand why this is a problem. If it were a problem, it
would be one of humongous dimensions because it affects all programs
that use open(..., 0666) to create non-executable files potentially
containing sensitive contents. For example all editors. And all shells
because any redirection could create such a file.

If you work on confidential information, your umask should be 077. In a
bank I worked for this was prescribed for the superuser account. Made
for a lot of admin problems because root rarely creates files with
confidential information, but frequently files that must be readable
for anyone...

Lupe Christoph
--
| You know we're sitting on four million pounds of fuel, one nuclear |
| weapon and a thing that has 270,000 moving parts built by the lowest |
| bidder. Makes you feel good, doesn't it? |
| Rockhound in "Armageddon", 1998, about the Space Shuttle |

[Imran Ghory]

On 8/5/05, Lupe Christoph <lupe@lupe-christoph.de> wrote:
>=20
> I still don't understand why this is a problem. If it were a problem, it
> would be one of humongous dimensions because it affects all programs
> that use open(..., 0666) to create non-executable files potentially
> containing sensitive contents.=20

In cases where a "secure" file has permissions degraded yes, for
example CAN-2005-1920 where an editor was creating a a backup with
less secure permissions than the original.

> For example all editors. And all shells
> because any redirection could create such a file.

Permission handling in shells is generally accepted to be insecure due
to other issues such as lack of atomicity.

Imran