Bug 104085 (CVE-2005-2457)

From: Tim Yamin <plasmaroo@gentoo.org> 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050227 
To: vendor-sec@lst.de 
Cc: Chris Wright <chrisw@osdl.org> 
Subject: [vendor-sec] Re: kernel zlib updates 
Errors-To: vendor-sec-admin@lst.de 
Date: Thu, 11 Aug 2005 02:40:12 +0100 
 
You also want 243393c90f2b7cb781fd794e22786e9c8547901a as that's a 
dependency for fab5a60a29f98f17256a4183e34a414f6db67569 (which isn't a 
zlib related bug and not public with the exception of the patch). 
 
Use CAN-2005-2457 for zisofs, CAN-2005-2458 for gzip (the buffer 
overflow due to missing boundary checks) and CAN-2005-2459 for the 
gzip/zlib NULL dereference (the return code issue).    
 
Thanks! 
 

From: Mark J Cox <mjc@redhat.com> 
To: Tim Yamin <plasmaroo@gentoo.org> 
Cc: vendor-sec@lst.de, Chris Wright <chrisw@osdl.org> 
Subject: Re: [vendor-sec] Re: kernel zlib updates 
Errors-To: vendor-sec-admin@lst.de 
Date: Thu, 11 Aug 2005 10:48:53 +0100 (BST) 
 
>Use CAN-2005-2457 for zisofs, CAN-2005-2458 for gzip (the buffer 
 
I'm going to argue that CAN-2005-2457 should be dropped as this doesn't 
have a security consequence.  This is a flaw where if you have a mounted  
malicious filesystem then a user can cause a crash by reading one of the 
carefully crafted malicious files. 
 
An attacker who can get their malicious ISO mounted could definately do 
more exciting things than cause a crash.  Red Hat and other distributions 
do automount some hardware which could allow a non-root user to cause the 
crash, but I still wouldn't class this issue as having a security 
consequence. 
 
Cheers, Mark 

Created attachment 45714 [details]
zlib-kernel-fixes.diff

http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4aad724d3e52238e1ce005f166fbba5b4072a7f6

Created attachment 45715 [details]
zisofs-fix.diff

http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fab5a60a29f98f17256a4183e34a414f6db67569

Created attachment 45717 [details]
zisofs-fix1.diff

prereq of zisofs-fix.diff

local (not sure if remote) denial of service issue. 

we need to test the zlib stuff ... if need :/ 

Patch submitted to SLES9 SP2, SP3, 9.3 

From: Olaf Hering <olh@suse.de> 
To: Marcus Meissner <meissner@suse.de> 
Subject: [linux-kernel@vger.kernel.org: Revert unnecessary 
+zlib_inflate/inftrees.c fix] 
User-Agent: Mutt und vi sind doch schneller als Notes (und GroupWise) 
 
kernel immer noch kaputt. 
----- Forwarded message from Linux Kernel Mailing List 
+<linux-kernel@vger.kernel.org> ----- 
 
Date:   Wed, 17 Aug 2005 14:00:38 -0700 
Subject: Revert unnecessary zlib_inflate/inftrees.c fix 
From: Linux Kernel Mailing List <linux-kernel@vger.kernel.org> 
To: git-commits-head@vger.kernel.org 
 
tree 8a25999cb4b8c33841bd1969e3054c13bda3b394 
parent 7974b1cc7879141962999e78a6fc9a136dc4479e 
author Linus Torvalds <torvalds@g5.osdl.org> Thu, 18 Aug 2005 03:07:28 -0700 
committer Linus Torvalds <torvalds@g5.osdl.org> Thu, 18 Aug 2005 03:07:28 
-0700  
 
Revert unnecessary zlib_inflate/inftrees.c fix 
 
It turns out that empty distance code tables are not an error, and that 
a compressed block with only literals can validly have an empty table 
and should not be flagged as a data error. 
 
Some old versions of gzip had problems with this case, but it does not 
affect the zlib code in the kernel. 
 
Analysis and explanations thanks to Sergey Vlasov <vsu@altlinux.ru> 
 
Signed-off-by: Linus Torvalds <torvalds@osdl.org> 
 
 lib/zlib_inflate/inftrees.c |    2 +- 
 1 files changed, 1 insertion(+), 1 deletion(-) 
 
diff --git a/lib/zlib_inflate/inftrees.c b/lib/zlib_inflate/inftrees.c 
--- a/lib/zlib_inflate/inftrees.c 
+++ b/lib/zlib_inflate/inftrees.c 
@@ -141,7 +141,7 @@ static int huft_build( 
   { 
     *t = NULL; 
     *m = 0; 
-    return Z_DATA_ERROR; 
+    return Z_OK; 
   } 
 
 
 

Fixed in 9.2, 9.3, SLES9-SP2, SLES9-SP3, SLES8 and SLEC8 branches 

released 9.2, 9.3, SLES9 updates. 
 
SLES 8 , 9.0 and SLEC release still open. 

only sles8 update is left (in qa currently)

updates for sles8 and slec and 9.0 released now.