From: Josh Bressers <bressers@redhat.com> To: vendor-sec@lst.de Subject: [vendor-sec] Weekly embargoed issues recap Date: Fri, 24 Sep 2004 16:55:01 -0400 Sorry this is coming so late today. Things seem pretty slow lately, if I've missed anything, please be sure to let me know. Embargoed issues: CAN-2004-0803 libtiff ????(*1) Known issues which need work: CAN-NONE xpdf Chris Evans alerted vendor-sec on July 16 with multiple problems with xpdf. This is developing. We know xpdf 3 and 2 have different problems, but both have problems. CAN-2004-0814 kernel Alan Cox forwarded a message from the lkml stating a kernel panic in the serio code. http://www.ussg.iu.edu/hypermail/linux/kernel/0409.0/2276.html CAN-NONE kernel Marcus Meissner has reported an Oops in the kernel which allows an old ICMP exploit to work with certain firewall rules in place. (disclosure date?). Oystein Viggen reported to vendor-sec on 2004-09-10 a number of temp file issues. Work is ongoing (we're going to need CVE id's for these). *1) Chris, how close do you think we are from being able to release?
From: Chris Wright <chrisw@osdl.org> To: Josh Bressers <bressers@redhat.com> Cc: vendor-sec@lst.de Subject: Re: [vendor-sec] Weekly embargoed issues recap Date: Fri, 24 Sep 2004 14:02:57 -0700 * Josh Bressers (bressers@redhat.com) wrote: > Sorry this is coming so late today. > > Things seem pretty slow lately, if I've missed anything, please be sure to > let me know. You missed the binfmt_elf advisory from Paul Starzetz <ihaquer@isec.pl>. Although I've yet to convince myself of the severity (seems low). thanks, -chris
From: Dmitry V. Levin <ldv@altlinux.org> To: vendor-sec@lst.de Cc: Chris Evans <chris@scary.beasts.org> Subject: Re: [vendor-sec] Weekly embargoed issues recap Date: Sat, 25 Sep 2004 01:41:44 +0400 On Fri, Sep 24, 2004 at 04:55:01PM -0400, Josh Bressers wrote: > CAN-2004-0803 libtiff ????(*1) [...] > *1) Chris, how close do you think we are from being able to release? Note that CAN-2004-0803 issues are mentioned in libtiff cvs. I am working closely with Andrey Kiselev from libtiff to locate and fix numerous integer overflows in this library, most of them are related to memory allocation and therefore looks potentially exploitable. I suggest to release libtiff updates with all these bugs fixed.
CAN-2004-0803 libtiff ????(*1) From: Dmitry V. Levin <ldv@altlinux.org> To: vendor-sec@lst.de Cc: Chris Evans <chris@scary.beasts.org> Subject: Re: [vendor-sec] libtiff troubles Date: Mon, 4 Oct 2004 13:38:18 +0400 Hi, On Wed, Sep 22, 2004 at 10:06:11AM +0200, Sebastian Krahmer wrote: > On Tue, 21 Sep 2004 chris@scary.beasts.org wrote: > > > Good catch. > > This will need a new CAN identifier. > > > > Does anyone have time to look over libtiff for additional overflows > > (integer or otherwise)? > > before this starts to be an endless issue because every week we get a new > one, do we want to give it a full audit session? I've finished code review for malloc-related problems. Fixed numerous integer overflows in this library, most of them are related to memory allocation and therefore looks potentially exploitable. I suggest to assign it a CAN identifier, and release together with fixes reported by Chris. I've also backported these fixes to libtiff-3.6.1 and libtiff-3.5.7, you can find patches at ftp://ftp.altlinux.org/pub/people/ldv/tiff/ Note that both issues are already announced in libtiff cvs changelog. --------------------------------------------------------------------- From: chris@scary.beasts.org To: Dmitry V. Levin <ldv@altlinux.org> Cc: vendor-sec@lst.de Subject: Re: [vendor-sec] libtiff troubles Date: Mon, 4 Oct 2004 16:05:50 +0100 (BST) Hi, On Mon, 4 Oct 2004, Dmitry V. Levin wrote: > I've finished code review for malloc-related problems. > Fixed numerous integer overflows in this library, most of them are related > to memory allocation and therefore looks potentially exploitable. > > I suggest to assign it a CAN identifier, and release together with fixes > reported by Chris. Good idea. Since all the issues are already announced in the CVS changelog, how about a disclosure date of Weds 13th Oct 1400UTC? That's my attempt at a balance between releasing quickly vs. allowing enough time for package building and QA. Cheers Chris ------------------------------------------------------------------------------ solar@simple / $ metadata.py tiff Package: media-libs/tiff Herd: no-herd Maintainer: no-herd
Input from other sec devs requested. I have a tiff-3.6.1-r2 ready to go. I see there was some backporting of tiff to 3.5.7 and 3.5.7 is what we have marked as stable for most arches. However looking at the libtiff site http://www.libtiff.org/ they cleary say that 3.6.1 is the current. So I'm wondering if we should even waste our time working on the 3.5.7 stuff, or just go for the gold and get current.
Correction not most arches. tiff-3.6.1-r1.ebuild ~x86 ~ppc ~sparc mips alpha arm hppa amd64 ia64 s390 macos ppc-macos tiff-3.5.7-r1.ebuild x86 ppc sparc alpha hppa amd64 ~mips So only x86/ppc/sparc need to bump to stable. On this note I don't think it's going to be a problem moving everybody to 3.6.1-r2 Question is should I merge it now? Or wait till later? I'd vote for patching now and doing a GLSA on Weds 13th Oct 1400UTC assuming the date does not get bumped around anymore at vendor-sec before said release day.
Usually vendor-sec doesn't like it when vulnerabilities leak from CVS updates before coordinated release dates... I think we should get ready for the coordinated date by asking selected arch guys to test and directly commit the fix to stable just before issueing the GLSA on Oct 13. That's what we did for the recent Samba release. In all cases you should open a separate restricted bug to handle that, that will allow us to Cc: specific arch people.
libtiff - http://bugs.gentoo.org/show_bug.cgi?id=66354
libtff is out. xpdf is out. 2 kernel things are out. This bug is no longer needed closing.
closed
