LinuxLists.cc - [PATCH] zlib double-free bug

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

On Mon, Mar 18, 2002 at 03:49:46PM +0100, J.A. Magallon wrote:

> The only rest it leaves in 19-pre3 are:
>
> ./arch/ppc/boot/lib/zlib.c
> ./arch/ppc/boot/include/zlib.h
>
> Patch already does:
>
> --- linux-2.4.19-pre2-ac2/arch/ppc/config.in Sun Mar 3 18:54:31 2002
> +++ linux-2.4.19-pre2-ac2-zlib/arch/ppc/config.in Tue Mar 5 08:57:31 2002
> @@ -396,6 +396,8 @@
> source net/bluetooth/Config.in
> fi
>
> +source lib/Config.in
> +
> mainmenu_option next_comment
> comment 'Kernel hacking'
>
>
> So wouldn't it be better to kill ppc/.../zlib and make it use also the
> shared copy ?

Not really. The arch/ppc/boot version (and arch/mips/boot'ish too, when
it gets merged) are slightly different from the in-kernel ones by ~1
line, so that they allow things to be decompressed to 0x0. My plan for
2.5 is to get the PPC version using the lib/zlib_deflate stuff (by dummy
files doing #include too), maybe. But either way it's a non-issue (if
you can't trust the 'zImage' binary, you've got bigger problems than
someone trying to expliot a bug before Linux is running).

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

2002-03-18 16:38:01

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

[email protected] said:
> Someone posted it was here:
> ftp://ftp.kernel.org/pub/linux/kernel/people/dwmw2/shared-zlib/

Also bk://linux-mtd.bkbits.net/zlib-2.4 and in 2.4.19-ac.

After it's been in -ac for a while without mishap I'll ask Marcelo to
consider it - possibly for 2.4.20-pre1.

--
dwmw2

2002-03-18 22:39:10

by Paul Mackerras

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

David Woodhouse writes:

> After it's been in -ac for a while without mishap I'll ask Marcelo to
> consider it - possibly for 2.4.20-pre1.

Yep, that sounds good to me. For now, I think my patch should go in
for 2.4.19.

Anyone who is using PPP with Deflate compression on an older 2.4.x
kernel (or for that matter a 2.2.x kernel) should apply my patch
also, or at least the part of it that affects drivers/net/zlib.c.

Paul.

2002-03-19 05:22:13

by Paul Mackerras

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

Someone pointed me at a previously-posted patch for the zlib
vulnerability. While I was looking at that patch I realized that both
that patch and mine were buggy in different ways. My patch was
freeing s->sub.trees.blens after that word had been overwritten by an
assignment to s->sub.decode.codes, whereas with the previously-posted
patch, it is still possible to get a double-free (if inflate_codes_new
returns NULL, it will leave s->mode == DTREE but s->sub.trees.blens
has already been freed).

Here is a new patch which should fix both those problems.

Paul.

diff -urN linux-2.4.19-pre3/arch/ppc/boot/lib/zlib.c pmac/arch/ppc/boot/lib/zlib.c
--- linux-2.4.19-pre3/arch/ppc/boot/lib/zlib.c Mon Mar 18 13:34:47 2002
+++ pmac/arch/ppc/boot/lib/zlib.c Tue Mar 19 15:46:09 2002
@@ -1,5 +1,5 @@
/*
- * BK Id: SCCS/s.zlib.c 1.10 01/11/02 10:46:07 trini
+ * BK Id: SCCS/s.zlib.c 1.9 12/05/01 16:19:42 mporter
*/
/*
* This file is derived from various .h and .c files from the zlib-0.95
@@ -928,7 +928,10 @@
{
r = t;
if (r == Z_DATA_ERROR)
+ {
+ ZFREE(z, s->sub.trees.blens, s->sub.trees.nblens * sizeof(uInt));
s->mode = BADB;
+ }
LEAVE
}
s->sub.trees.index = 0;
@@ -964,6 +967,7 @@
if (i + j > 258 + (t & 0x1f) + ((t >> 5) & 0x1f) ||
(c == 16 && i < 1))
{
+ ZFREE(z, s->sub.trees.blens, s->sub.trees.nblens * sizeof(uInt));
s->mode = BADB;
z->msg = "invalid bit length repeat";
r = Z_DATA_ERROR;
@@ -991,7 +995,10 @@
if (t != Z_OK)
{
if (t == (uInt)Z_DATA_ERROR)
+ {
+ ZFREE(z, s->sub.trees.blens, s->sub.trees.nblens * sizeof(uInt));
s->mode = BADB;
+ }
r = t;
LEAVE
}
diff -urN linux-2.4.19-pre3/drivers/net/zlib.c pmac/drivers/net/zlib.c
--- linux-2.4.19-pre3/drivers/net/zlib.c Sat Apr 28 23:02:45 2001
+++ pmac/drivers/net/zlib.c Tue Mar 19 15:45:40 2002
@@ -14,7 +14,7 @@
*/

/*
- * ==FILEVERSION 971210==
+ * ==FILEVERSION 20020318==
*
* This marker is used by the Linux installation script to determine
* whether an up-to-date version of this file is already installed.
@@ -772,7 +772,7 @@
windowBits = -windowBits;
}
if (memLevel < 1 || memLevel > MAX_MEM_LEVEL || method != Z_DEFLATED ||
- windowBits < 8 || windowBits > 15 || level < 0 || level > 9 ||
+ windowBits < 9 || windowBits > 15 || level < 0 || level > 9 ||
strategy < 0 || strategy > Z_HUFFMAN_ONLY) {
return Z_STREAM_ERROR;
}
@@ -3860,10 +3860,12 @@
&s->sub.trees.tb, z);
if (t != Z_OK)
{
- ZFREE(z, s->sub.trees.blens);
r = t;
if (r == Z_DATA_ERROR)
+ {
+ ZFREE(z, s->sub.trees.blens);
s->mode = BADB;
+ }
LEAVE
}
s->sub.trees.index = 0;
@@ -3928,11 +3930,13 @@
#endif
t = inflate_trees_dynamic(257 + (t & 0x1f), 1 + ((t >> 5) & 0x1f),
s->sub.trees.blens, &bl, &bd, &tl, &td, z);
- ZFREE(z, s->sub.trees.blens);
if (t != Z_OK)
{
if (t == (uInt)Z_DATA_ERROR)
+ {
+ ZFREE(z, s->sub.trees.blens);
s->mode = BADB;
+ }
r = t;
LEAVE
}
@@ -3945,6 +3949,7 @@
r = Z_MEM_ERROR;
LEAVE
}
+ ZFREE(z, s->sub.trees.blens);
s->sub.decode.codes = c;
s->sub.decode.tl = tl;
s->sub.decode.td = td;
diff -urN linux-2.4.19-pre3/fs/jffs2/zlib.c pmac/fs/jffs2/zlib.c
--- linux-2.4.19-pre3/fs/jffs2/zlib.c Mon Sep 24 09:31:33 2001
+++ pmac/fs/jffs2/zlib.c Tue Mar 19 15:46:47 2002
@@ -14,7 +14,7 @@
*/

/*
- * ==FILEVERSION 971210==
+ * ==FILEVERSION 20020318==
*
* This marker is used by the Linux installation script to determine
* whether an up-to-date version of this file is already installed.
@@ -772,7 +772,7 @@
windowBits = -windowBits;
}
if (memLevel < 1 || memLevel > MAX_MEM_LEVEL || method != Z_DEFLATED ||
- windowBits < 8 || windowBits > 15 || level < 0 || level > 9 ||
+ windowBits < 9 || windowBits > 15 || level < 0 || level > 9 ||
strategy < 0 || strategy > Z_HUFFMAN_ONLY) {
return Z_STREAM_ERROR;
}
@@ -3860,10 +3860,12 @@
&s->sub.trees.tb, z);
if (t != Z_OK)
{
- ZFREE(z, s->sub.trees.blens);
r = t;
if (r == Z_DATA_ERROR)
+ {
+ ZFREE(z, s->sub.trees.blens);
s->mode = BADB;
+ }
LEAVE
}
s->sub.trees.index = 0;
@@ -3928,11 +3930,13 @@
#endif
t = inflate_trees_dynamic(257 + (t & 0x1f), 1 + ((t >> 5) & 0x1f),
s->sub.trees.blens, &bl, &bd, &tl, &td, z);
- ZFREE(z, s->sub.trees.blens);
if (t != Z_OK)
{
if (t == (uInt)Z_DATA_ERROR)
+ {
+ ZFREE(z, s->sub.trees.blens);
s->mode = BADB;
+ }
r = t;
LEAVE
}
@@ -3945,6 +3949,7 @@
r = Z_MEM_ERROR;
LEAVE
}
+ ZFREE(z, s->sub.trees.blens);
s->sub.decode.codes = c;
s->sub.decode.tl = tl;
s->sub.decode.td = td;

2002-03-19 10:46:11

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

On Tue, 19 Mar 2002, Paul Mackerras wrote:

> David Woodhouse writes:
>
> > After it's been in -ac for a while without mishap I'll ask Marcelo to
> > consider it - possibly for 2.4.20-pre1.
>
> Yep, that sounds good to me. For now, I think my patch should go in
> for 2.4.19.

Absolutely - sorry, I didn't mean to imply otherwise.

For the record - it's not worth bothering with fs/jffs2/zlib.c; if they
can corrupt your file system on the medium, why bother with cracking zlib?
:)

--
dwmw2

2002-03-19 13:54:21

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

On Tue, 19 Mar 2002, David Woodhouse wrote:

> For the record - it's not worth bothering with fs/jffs2/zlib.c; if they
> can corrupt your file system on the medium, why bother with cracking zlib?
> :)

To preempt anyone else objecting to this...

I mean, given that we have a CRC on jffs2 nodes anyway, so the chances of
any accidentally corrupted input actually being fed to the decompressor
are virtually zero, it's not worth patching the 2.4.19 zlib when I want to
put the shared zlib into 2.4.20 anyway.

I'm not going to object to anyone else doing so, but I can't be bothered
to do it myself, as it would have virtually zero benefit and would mean
I'd have to update the shared-zlib patches for 2.4.

Infinitely more people (i.e. at least one) have been bitten by the fact
that you can't build both ppp_deflate and jffs2 into a 2.4 kernel.

--
dwmw2

2002-03-19 18:07:04

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

Followup to: <Pine.LNX.4.44.0203191044150.26226-100000@passion.cambridge.redhat.com>
By author: David Woodhouse <[email protected]>
In newsgroup: linux.dev.kernel
>
> On Tue, 19 Mar 2002, Paul Mackerras wrote:
>
> > David Woodhouse writes:
> >
> > > After it's been in -ac for a while without mishap I'll ask Marcelo to
> > > consider it - possibly for 2.4.20-pre1.
> >
> > Yep, that sounds good to me. For now, I think my patch should go in
> > for 2.4.19.
>
> Absolutely - sorry, I didn't mean to imply otherwise.
>
> For the record - it's not worth bothering with fs/jffs2/zlib.c; if they
> can corrupt your file system on the medium, why bother with cracking zlib?
> :)
>

Removable media?

-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>

2002-03-19 19:14:55

by Dave Jones

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

> > For the record - it's not worth bothering with fs/jffs2/zlib.c; if they
> > can corrupt your file system on the medium, why bother with cracking zlib?
> Removable media?

If attacker has physical access to the media, there are far simpler
ways of corrupting it than zlib exploitation. 8-)

--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs

2002-03-19 19:37:18

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

Dave Jones wrote:

> > > For the record - it's not worth bothering with fs/jffs2/zlib.c; if they
> > > can corrupt your file system on the medium, why bother with cracking zlib?
> > Removable media?
>
> If attacker has physical access to the media, there are far simpler
> ways of corrupting it than zlib exploitation. 8-)
>

Right, but you don't want someone to insert a removable medium and have
the system crash in response.

-hpa

2002-03-19 19:50:48

by Dave Jones

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

On Tue, Mar 19, 2002 at 11:36:19AM -0800, H. Peter Anvin wrote:

> Right, but you don't want someone to insert a removable medium and have
> the system crash in response.

My understanding from one of dwmw2's earlier posts was that jffs2
has crc's that would prevent this happening anyway (or at least make
it nigh on impossible)
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs

2002-03-19 19:59:48

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

Dave Jones wrote:

> On Tue, Mar 19, 2002 at 11:36:19AM -0800, H. Peter Anvin wrote:
>
> > Right, but you don't want someone to insert a removable medium and have
> > the system crash in response.
>
> My understanding from one of dwmw2's earlier posts was that jffs2
> has crc's that would prevent this happening anyway (or at least make
> it nigh on impossible)
>

I doubt that. We're talking about corrupting the kernel VM.

-hpa

2002-03-19 20:09:48

by Dave Jones

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

On Tue, Mar 19, 2002 at 11:59:07AM -0800, H. Peter Anvin wrote:

> > My understanding from one of dwmw2's earlier posts was that jffs2
> > has crc's that would prevent this happening anyway (or at least make
> > it nigh on impossible)
> I doubt that. We're talking about corrupting the kernel VM.

Ignore me, I'm losing my mind.

--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs

2002-03-19 20:35:59

by Nicolas Pitre

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

On 19 Mar 2002, H. Peter Anvin wrote:

> Followup to: <Pine.LNX.4.44.0203191044150.26226-100000@passion.cambridge.redhat.com>
> By author: David Woodhouse <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > For the record - it's not worth bothering with fs/jffs2/zlib.c; if they
> > can corrupt your file system on the medium, why bother with cracking zlib?
> > :)
> >
>
> Removable media?

Most if not all removable media are not ment to be used with JFFS2.

Nicolas

2002-03-20 09:47:19

by Helge Hafting

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

Nicolas Pitre wrote:

> > Removable media?
>
> Most if not all removable media are not ment to be used with JFFS2.

Nothing is _meant_ to be exploited either. Someone could
create a cdrom with jffs2 (linux don't demand that cd's use iso9660)
with an intent to make trouble. crc's and such would match the
bad compressed stuff. Nothing unusual seems to happen, but
using the cd installs a back door as the fs uncompresses stuff.

Helge Hafting

2002-03-20 14:46:27

by Nicolas Pitre

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

On Wed, 20 Mar 2002, Helge Hafting wrote:

> Nicolas Pitre wrote:
>
> > > Removable media?
> >
> > Most if not all removable media are not ment to be used with JFFS2.
>
> Nothing is _meant_ to be exploited either. Someone could
> create a cdrom with jffs2 (linux don't demand that cd's use iso9660)

But JFFS2 demands to be used with AN MTD device, not a block device. And
most MTD device, if not all of them, on which JFFS2 is used aren't
removable.

Nicolas

2002-03-20 16:00:35

by Martin Hermanowski

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

On Wed, Mar 20, 2002 at 10:45:42AM +0100, Helge Hafting wrote:
> Nicolas Pitre wrote:
>
>>> Removable media?
>>
>> Most if not all removable media are not ment to be used with JFFS2.
>
> Nothing is _meant_ to be exploited either. Someone could
> create a cdrom with jffs2 (linux don't demand that cd's use iso9660)
> with an intent to make trouble. crc's and such would match the
> bad compressed stuff. Nothing unusual seems to happen, but
> using the cd installs a back door as the fs uncompresses stuff.

What about ZISOFS? IIRC the files are compressed with gzip und
decompressed on the fly.

MfG
Martin

--
PGP/GPG encrypted mail preferred, see header
,--
| Nur tote Fische schwimmen mit dem Strom
`--

2002-03-20 16:19:05

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

On Wed, Mar 20, 2002 at 04:59:33PM +0100, Martin Hermanowski wrote:
> On Wed, Mar 20, 2002 at 10:45:42AM +0100, Helge Hafting wrote:
> > Nicolas Pitre wrote:
> >
> >>> Removable media?
> >>
> >> Most if not all removable media are not ment to be used with JFFS2.
> >
> > Nothing is _meant_ to be exploited either. Someone could
> > create a cdrom with jffs2 (linux don't demand that cd's use iso9660)
> > with an intent to make trouble. crc's and such would match the
> > bad compressed stuff. Nothing unusual seems to happen, but
> > using the cd installs a back door as the fs uncompresses stuff.
>
> What about ZISOFS? IIRC the files are compressed with gzip und
> decompressed on the fly.

ZISOFS falls into the same case that 2.5 does.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

2002-03-21 20:15:08

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

Followup to: <[email protected]>
By author: Nicolas Pitre <[email protected]>
In newsgroup: linux.dev.kernel
>
> On Wed, 20 Mar 2002, Helge Hafting wrote:
>
> > Nicolas Pitre wrote:
> >
> > > > Removable media?
> > >
> > > Most if not all removable media are not ment to be used with JFFS2.
> >
> > Nothing is _meant_ to be exploited either. Someone could
> > create a cdrom with jffs2 (linux don't demand that cd's use iso9660)
>
> But JFFS2 demands to be used with AN MTD device, not a block device. And
> most MTD device, if not all of them, on which JFFS2 is used aren't
> removable.
>

Isn't this whole discussion a bit silly? If I'm not mistaken, we're
talking about a one-line known fix here...

-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>

2002-03-21 21:08:35

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

On Thu, Mar 21, 2002 at 12:14:33PM -0800, H. Peter Anvin wrote:
> Followup to: <[email protected]>
> By author: Nicolas Pitre <[email protected]>
> In newsgroup: linux.dev.kernel
> >
> > On Wed, 20 Mar 2002, Helge Hafting wrote:
> >
> > > Nicolas Pitre wrote:
> > >
> > > > > Removable media?
> > > >
> > > > Most if not all removable media are not ment to be used with JFFS2.
> > >
> > > Nothing is _meant_ to be exploited either. Someone could
> > > create a cdrom with jffs2 (linux don't demand that cd's use iso9660)
> >
> > But JFFS2 demands to be used with AN MTD device, not a block device. And
> > most MTD device, if not all of them, on which JFFS2 is used aren't
> > removable.
>
> Isn't this whole discussion a bit silly? If I'm not mistaken, we're
> talking about a one-line known fix here...

It's getting there. The 'issue' is that the best way to fix it (maybe
2.4.20-pre1 even) is to backport the 2.5 zlib which doesn't have this
problem and removes most of the copies of zlib from the kernel. If it's
not really a problem now, why fix it? (Tho it should be a safe fix now
that Paul has produced a patch which doesn't suffer from random oopses
or other problems).

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

2002-03-21 21:25:46

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

On Thu, Mar 21, 2002 at 02:03:56PM -0700, Tom Rini wrote:
> On Thu, Mar 21, 2002 at 12:14:33PM -0800, H. Peter Anvin wrote:
> > Followup to: <[email protected]>
> > By author: Nicolas Pitre <[email protected]>
> > In newsgroup: linux.dev.kernel
> > >
> > > On Wed, 20 Mar 2002, Helge Hafting wrote:
> > >
> > > > Nicolas Pitre wrote:
> > > >
> > > > > > Removable media?
> > > > >
> > > > > Most if not all removable media are not ment to be used with JFFS2.
> > > >
> > > > Nothing is _meant_ to be exploited either. Someone could
> > > > create a cdrom with jffs2 (linux don't demand that cd's use iso9660)
> > >
> > > But JFFS2 demands to be used with AN MTD device, not a block device. And
> > > most MTD device, if not all of them, on which JFFS2 is used aren't
> > > removable.
> >
> > Isn't this whole discussion a bit silly? If I'm not mistaken, we're
> > talking about a one-line known fix here...
>
> It's getting there.

Correction, it is there since it's been fixed in 2.4.19-pre4 anyhow.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

2002-03-21 22:02:23

by Alan

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

> It's getting there. The 'issue' is that the best way to fix it (maybe
> 2.4.20-pre1 even) is to backport the 2.5 zlib which doesn't have this

2.4.19ac has the shared zlib already. The zlib sharing stuff wasnt a 2.5
patch backported - its a 2.4 fix that went forward

2002-03-22 00:11:29

by Corey Minyard

[permalink] [raw]

Subject: Re: [PATCH] zlib double-free bug

Alan Cox wrote:

>>It's getting there. The 'issue' is that the best way to fix it (maybe
>>2.4.20-pre1 even) is to backport the 2.5 zlib which doesn't have this
>>
>
>2.4.19ac has the shared zlib already. The zlib sharing stuff wasnt a 2.5
>patch backported - its a 2.4 fix that went forward
>
Since I did the original shared zlib patch and I did it to 2.5, either
we have two patches floating around or you are incorrect. If we have
two patches, we need to resolve the situation.

-Corey

2002-03-22 07:30:10