Re: [Fwd: freeswan & zlib security]
On Mon, Sep 16, 2002 at 07:07:30PM +0200, Rene Mayrhofer wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
>
> I have checked the source code of freeswan 1.98b and have noticed that
> the second change (which is mentioned in the attached mail) is included
> with this code. However, in version 1.96 (which is currently in woody)
> this fix is not included. I am completely unsure if this opens a
> security hole or not. If it does, it would be important for woody to get
> an updated version.
> Any advice would be greatly appreciated.
IIRC, the problem with zlib was that it called free(3) an extra time, or
something like that, and glibc no longer allows that. Moving the ZFREE()
obviously changes the conditions required for it to be called, so this is
very probably related to the double-free(3) bug. If the code you've
posted is running in the kernel, then glibc won't be handling ZFREE, it'll
be a kernel memory management function. Does anyone know if it's safe to
double-free vmalloc()ed (or whatever it is) kernel memory?
I thought the kernel had zlib functions built in already, why isn't
FreeSWAN using that? (I'm not really a kernel hacker, so I could be wrong
on this :)
> To: Rene Mayrhofer <rene@mayrhofer.eu.org>
> From: Christian Jaeger <christian.jaeger@sl.ethz.ch>
> Subject: freeswan & zlib security
>
> Hello Rene,
>
> I'm looking into using the FreeSWAN kernel patch from Debian Woody
> (kernel-patch-freeswan 1.96-1.2) and have had a look at the source,
> and have noticed that it uses zlib version 1.1.3 which has had
> security advisories.
>
> It seems that the zlib source bundled with the freeswan kernel patch
> has already applied some corrections, but not others, so I'm not sure
> if this is by intent or an oversight. There's nothing in the README
> files about the (corrected) security problems.
>
> In freeswan's zlib source I read:
>
> if (memLevel < 1 || memLevel > MAX_MEM_LEVEL || method != Z_DEFLATED ||
> windowBits < 8 || windowBits > 15 || level < 0 || level > 9 ||
> strategy < 0 || strategy > Z_HUFFMAN_ONLY) {
> return Z_STREAM_ERROR;
>
> whereas the patch correcting one hole was:
> 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;
> (note the missing windowBits < 9 correction)
>
> Then in the new zlib source's infblock.c lines 325ff read:
> r = t;
> LEAVE
> }
> Tracev((stderr, "inflate: trees ok\n"));
> if ((c = inflate_codes_new(bl, bd, tl, td, z)) == Z_NULL)
> {
> r = Z_MEM_ERROR;
> LEAVE
> }
> s->sub.decode.codes = c;
> }
> ZFREE(z, s->sub.trees.blens);
> s->mode = CODES;
> case CODES:
>
> whereas the freeswan's reads:
> r = t;
> LEAVE
> }
> ZFREE(z, s->sub.trees.blens);
> Tracev((stderr, "inflate: trees ok\n"));
> if ((c = inflate_codes_new(bl, bd, tl, td, z)) == Z_NULL)
> {
> r = Z_MEM_ERROR;
> LEAVE
> }
> s->sub.decode.codes = c;
> }
> s->mode = CODES;
> case CODES:
>
> (note the ZFREE(z, s->sub.trees.blens); part which has been moved.)
>
>
> changelog.Debian.gz says the following:
> freeswan (1.96-1) unstable; urgency=HIGH
>
> Urgency critical because of the zlib bug.
> * New upstream version.
> * Fixed the zlib bug by manually applying the patch from the bug report.
> Closes: #138210: zlib security bug also present in freeswan 1.95-2
> * Updated the X.509 patch.
> * Updated the crypto extensions patch.
>
> -- Rene Mayrhofer <rene@mayrhofer.eu.org> Thu, 14 Mar 2002 17:48:23 +0100
>
>
> So I'm asking you if you are sure that all holes have been plugged.
>
>
> Thanks & greetings
> Christian.
>
--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@llama.nslug. , ns.ca)
"The gods confound the man who first found out how to distinguish the hours!
Confound him, too, who in this place set up a sundial, to cut and hack
my day so wretchedly into small pieces!" -- Plautus, 200 BC
Reply to: