With the recent zlib bug getting a fair amount of press, I was curious of its potential impact on OpenBSD's security record. Reading through the past couple day's mail, I found I wasn't alone in this curiousity. Todd Miller says, "Actually, I committed a fix for the problem in January. We didn't realize it was a security problem at the time (and neither did the zlib folks)".

From: Qwerty Uiop
To: misc AT openbsd.org
Subject: zlib bug
Date: Mon, 11 Mar 2002 23:08:26 +0100 (CET)

Hello.

After reading
http://www.gzip.org/zlib/advisory-2002-03-11.txt
I like to ask if/how this affects OpenBSD. I noticed
that ssh/compress.c includes zlib.h.

Regards
/Greger Asplund

From: Thorsten Glaser
Subject: Re: zlib bug
Date: Mon, 11 Mar 2002 23:04:13 +0000 (UTC)

No, it does not affect OpenBSD because of the superior
malloc (free, to be exact) implementation.
I read /. too and I instantly checked with the man pages.

However it does affect OpenSSH on Linux.

Thorsten

From: Ian D
Subject: Re: zlib bug
Date: 12 Mar 2002 08:55:57 +0100

Is OpenBSD as a whole immune to this bug, or just OpenBSD's OpenSSH
implementation?

From: Ted U
Subject: Re: zlib bug
Date: Tue, 12 Mar 2002 00:48:30 -0800 (PST)

I think immune is a strong word. It's still a bug. But BSD malloc
implementations are safe for the most part from being exploited.

OpenBSD as a whole, until a few hours ago, was vulnerable to the flaw in
any program that used libz (I count 7 in /usr/bin) would double free. It
just so happens that double freeing reports a warning instead of
corrupting the heap.

From: Artur Grabowski
Subject: Re: zlib bug
Date: 12 Mar 2002 10:42:07 +0100

That depends on in which order you do the double free.

if it's:

x = malloc();
free(x);
free(x);

Then everything should be safe with phk malloc.

But if it's:

x = malloc();
free(x);
a = malloc();
free(x);
b = malloc();

no malloc implementation will catch that and you have a big risk that
'a' and 'b' will point to the same memory.

I don't know how bad it was in zlib.

---

From: Darren Reed
Subject: Re: zlib bug
Date: Tue, 12 Mar 2002 22:40:43 +1100 (Australia/ACT)

What about ppp (deflate) in the kernel and the kernel malloc/free ?

Is /sys/net/zlib.c in need of patching ?

From: Todd C. Miller
Subject: Re: zlib bug
Date: Tue, 12 Mar 2002 09:13:59 -0700

Did that in January. It's based on an older zlib (or so it would appear)
so if you noticed something I didn't catch I'd be happy to hear about it.

---

From: Todd C. Miller
Subject: Re: zlib bug
Date: Tue, 12 Mar 2002 09:11:36 -0700

Actually, I committed a fix for the problem in January. We didn't
realize it was a security problem at the time (and neither did the
zlib folks).

---

From: Generic Player
Subject: that whole zlib thing
Date: Tue, 12 Mar 2002 19:19:32 -0500

Is any older version of openbsd vulnerable to this bug? I still have
some 2.8 boxes out there, do I need to worry about them?

Thanks
Adam

From: Darren Reed
Subject: Re: that whole zlib thing
Date: Wed, 13 Mar 2002 16:06:53 +1100 (Australia/ACT)

Further to that, it would appear that /sys/net/zlib.c was updated
Jan 18 2002 by Todd (why did I delete your email before I'd let it
sink in?). This leaves ppp in OpenBSD 3.0 and everything prior to
that "vulnerable". I say "vulnerable" because I don't know what
the impact is on the kernel - anyone tested this or doing any testing?

Further to this, there has been no pullup of the patched for zlib.c
(from 1.9 to 1.10) into the 3.0 branch, so using a "current" 3.0-stable
will not bring in a fix. This might be worthwhile, maybe even onto
2.9 and 2.8 for users who are stuck?

From: Todd C. Miller
Subject: Re: that whole zlib thing
Date: Tue, 12 Mar 2002 22:36:49 -0700

The zlib patches will get pulled into the stable branch in the next
day or two. The only things that use the kernel zlib are kernel
ppp support (that's pppd, not ppp), ipsec, and the crypto framework.

It's not clear that the kernel zlib is exploitable in any way, but
of course it never hurts to be safe.