Re: [Fwd: freeswan zlib security]
On Tue, Sep 17, 2002 at 12:49:34AM -0300, Peter Cordes wrote: 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 :) I chatted on the phone with Henry Spencer back when the zilb bug was first announced and he was of the opinion that in FS it would be almost impossible to exploit. So it's probably something that should be fixed but is not a high profile issue. Not my call though: I'm not one of the maintainers, just a user of the results. -- -- Nuke bin Laden: Dale Amon, CEO/MD improve the global Islandone Society gene pool. www.islandone.org -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: freeswan zlib security]
Dale Amon [EMAIL PROTECTED] writes: I chatted on the phone with Henry Spencer back when the zilb bug was first announced and he was of the opinion that in FS it would be almost impossible to exploit. So it's probably something that should be fixed but is not a high profile issue. Not my call though: I'm not one of the maintainers, just a user of the results. If we are talking about kernel code, a DoS vulnerability is serious enough, and IIRC it has been demonstrated that the double free() does happen in practice, and it might crash the kernel (I don't know if this actually happens, though). -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: freeswan zlib security]
On Tue, Sep 17, 2002 at 06:10:32PM +0200, Florian Weimer wrote: Dale Amon [EMAIL PROTECTED] writes: I chatted on the phone with Henry Spencer back when the zilb bug was first announced and he was of the opinion that in FS it would be almost impossible to exploit. So it's probably something that should be fixed but is not a high profile issue. Not my call though: I'm not one of the maintainers, just a user of the results. If we are talking about kernel code, a DoS vulnerability is serious enough, and IIRC it has been demonstrated that the double free() does happen in practice, and it might crash the kernel (I don't know if this actually happens, though). The impression I had was it would be extremely difficult in the best case to trigger it, and that typical configurations are such that it is avoided entirely. I'd have to really dig to get the details: that was many months ago. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: freeswan zlib security]
On Tue, Sep 17, 2002 at 12:49:34AM -0300, Peter Cordes wrote: 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 :) I chatted on the phone with Henry Spencer back when the zilb bug was first announced and he was of the opinion that in FS it would be almost impossible to exploit. So it's probably something that should be fixed but is not a high profile issue. Not my call though: I'm not one of the maintainers, just a user of the results. -- -- Nuke bin Laden: Dale Amon, CEO/MD improve the global Islandone Society gene pool. www.islandone.org --
Re: [Fwd: freeswan zlib security]
Dale Amon [EMAIL PROTECTED] writes: I chatted on the phone with Henry Spencer back when the zilb bug was first announced and he was of the opinion that in FS it would be almost impossible to exploit. So it's probably something that should be fixed but is not a high profile issue. Not my call though: I'm not one of the maintainers, just a user of the results. If we are talking about kernel code, a DoS vulnerability is serious enough, and IIRC it has been demonstrated that the double free() does happen in practice, and it might crash the kernel (I don't know if this actually happens, though). -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
Re: [Fwd: freeswan zlib security]
On Tue, Sep 17, 2002 at 06:10:32PM +0200, Florian Weimer wrote: Dale Amon [EMAIL PROTECTED] writes: I chatted on the phone with Henry Spencer back when the zilb bug was first announced and he was of the opinion that in FS it would be almost impossible to exploit. So it's probably something that should be fixed but is not a high profile issue. Not my call though: I'm not one of the maintainers, just a user of the results. If we are talking about kernel code, a DoS vulnerability is serious enough, and IIRC it has been demonstrated that the double free() does happen in practice, and it might crash the kernel (I don't know if this actually happens, though). The impression I had was it would be extremely difficult in the best case to trigger it, and that typical configurations are such that it is avoided entirely. I'd have to really dig to get the details: that was many months ago.
Re: [Fwd: freeswan zlib security]
Often changes get back-ported, have you read the changelog in /usr/doc/package/changloeg.Debian.gz? Regards, -- Phil PGP/GPG Key: http://www.zionlth.org/~plhofmei/ wget -O - http://www.zionlth.org/~plhofmei/ | gpg --import XP Source Code: #include win2k.h #include extra_pretty_things_with_bugs.h #include more_bugs.h #include require_system_activation.h #include phone_home_every_so_often.h #include remote_admin_abilities_for_MS.h #include more_restrictive_EULA.h #include sell_your_soul_to_MS_EULA.h //os_ver=Windows 2000 os_ver=Windows XP
Re: [Fwd: freeswan zlib security]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Phillip Hofmeister wrote: | Often changes get back-ported, have you read the changelog in /usr/doc/package/changloeg.Debian.gz? Yes. Sorry that I didn't mention it: I am the maintainer :) The question is if this would justify a security advisory. best regards, Rene -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iEYEARECAAYFAj2GJAMACgkQq7SPDcPCS94t4ACeJ7I9AzR2zajLhumr074+aZ2t OkwAn3bQnUxuknO5pnU9cXC3spkR3Z1e =yOk+ -END PGP SIGNATURE-
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 [EMAIL PROTECTED]
From: Christian Jaeger [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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([EMAIL PROTECTED] , 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
