181977 2007-06-14 02:10 0000 app-forensics/sleuthkit < 2.09 includes vulnerable "file" code 2008-01-10 08:54:05 0000 1 1 1 Unclassified Gentoo Security Vulnerabilities unspecified All Linux RESOLVED FIXED https://sourceforge.net/project/shownotes.php?release_id=515880&group_id=55685 B2 [glsa] Falco P2 normal --- 1 hanno@gentoo.org security@gentoo.org forensics@gentoo.org jer@gentoo.org radhermit@gmail.com hanno@gentoo.org 2007-06-14 02:10:15 0000 See subject, new version available. jakub@gentoo.org 2007-06-20 17:59:39 0000 *** Bug 182708 has been marked as a duplicate of this bug. *** falco@gentoo.org 2007-08-10 23:54:25 0000 i'm preparing the dbtool patch for sleuthkit-2.09. But appart from that, sleuthkit-2.09 fixes the recent "file" vulnerabities in its "file" embedded code: glsa-200703-26, glsa-200704-13, 200705-25. I suggest a GLSA. ChangeLog: 5/17/07: Update: Updated file to 4.20 (...) 6/13/07: Update: Updated file to 4.21 There is also a number of DoS fixed in this upgrade. aetius@gentoo.org 2007-08-11 00:11:54 0000 Seems like this would be very hard to exploit in a meaningful way. As I understand it, it essentially would require enticing a user to run the forensic tools on a crafted file. The attendant problems with that scenario are pretty obvious. :) Also I would expect that sleuthkit is not a common package by any means. Still, it is definitely a B2, so I guess we should. falco@gentoo.org 2007-08-29 14:50:13 0000 bumped and trying to fix bug 131268 at the same time. falco@gentoo.org 2007-08-29 14:53:45 0000 Hi arches, sleuthkit was shipped with a vulnerable version of the 'file' utility. There is pretty much change between sleuthkit-0.3 and sleuthkit-0.9. Please can you test sleuthkit-0.9 and mark is table if applicable, thanks. dertobi123@gentoo.org 2007-08-29 19:07:09 0000 ppc stable jer@gentoo.org 2007-08-30 02:50:12 0000 http://distfiles.gentoo.org/distfiles/sleuthkit-2.09_dbtool.patch.bz2 gives a 404... jer@gentoo.org 2007-08-30 03:00:59 0000 >>> Test phase [test]: app-forensics/sleuthkit-2.09 sh ./check-install Checking Tools ERROR: Missing 'file' command Done >>> Install sleuthkit-2.09 into ... jer@gentoo.org 2007-08-30 03:10:29 0000 Stable for HPPA nonetheless. willard.dawson@sungard.com 2007-08-30 16:11:24 0000 Where is it? Emerge can't locate the download... >>> Downloading 'ftp://cudlug.cudenver.edu/pub/mirrors/distributions/gentoo/distfiles/sleuthkit-2.09_dbtool.patch.bz2' --12:09:32-- ftp://cudlug.cudenver.edu/pub/mirrors/distributions/gentoo/distfiles/sleuthkit-2.09_dbtool.patch.bz2 => `/usr/portage/distfiles/sleuthkit-2.09_dbtool.patch.bz2' Resolving cudlug.cudenver.edu... 132.194.22.137 Connecting to cudlug.cudenver.edu|132.194.22.137|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD /pub/mirrors/distributions/gentoo/distfiles ... No such directory `pub/mirrors/distributions/gentoo/distfiles'. !!! Couldn't download 'sleuthkit-2.09_dbtool.patch.bz2'. Aborting. !!! Fetch for /usr/portage/app-forensics/sleuthkit/sleuthkit-2.09.ebuild failed, continuing... !!! Some fetch errors were encountered. Please see above for details. app-forensics/sleuthkit-2.09 jer@gentoo.org 2007-08-30 16:22:14 0000 (In reply to comment #10) > Where is it? Emerge can't locate the download... See comment #2 and comment #7 ... It's not ready yet, it appears. For now you will have to contend yourself with a lesser version or with: echo app-forensics/sleuthkit -dbtool >> /etc/portage/package.use fauli@gentoo.org 2007-09-05 05:22:47 0000 So what are we going to do with this package? Are arches still needed here? yoswink@gentoo.org 2007-09-05 10:40:33 0000 (In reply to comment #11) > (In reply to comment #10) > > Where is it? Emerge can't locate the download... > > See comment #2 and comment #7 ... It's not ready yet, it appears. @Jer: you say it's not ready yet (sure, it isn't ready even for ~arch) but ... why did you mark it as stable in hppa? This is not the first time I saw you marking stable packages after you discovered there are problems with them, so I would like to know the reason to not stop the process of stabilization. Thanks. jer@gentoo.org 2007-09-05 13:50:54 0000 (In reply to comment #13) > > See comment #2 and comment #7 ... It's not ready yet, it appears. > > @Jer: you say it's not ready yet (sure, it isn't ready even for ~arch) I meant the dbtool patch not being ready yet. The rest of the package works fine. > This is not the first time I saw you marking stable packages after you > discovered there are problems with them, so I would like to know the reason > to not stop the process of stabilization. See comment #2, "But appart from that," and so on. I read that as the dbtool patch being of no consequence to the included vulnerable version of file. `USE=-dbtool emerge =sleuthkit-2.09` works otherwise. I think it's up to the maintainer to stop the stabilisation process. falco CC'd the arches. Besides, dertobil23 marked ppc stable before I did. Why did you ask me, not him? yoswink@gentoo.org 2007-09-05 14:16:31 0000 (In reply to comment #14) > (In reply to comment #13) > > > See comment #2 and comment #7 ... It's not ready yet, it appears. > > > > @Jer: you say it's not ready yet (sure, it isn't ready even for ~arch) > > I meant the dbtool patch not being ready yet. The rest of the package works > fine. IMHO, something triggered via USE flag is a part of our "package" too, but well, keep reading please. > > > This is not the first time I saw you marking stable packages after you > > discovered there are problems with them, so I would like to know the reason > > to not stop the process of stabilization. > > See comment #2, "But appart from that," and so on. I read that as the dbtool > patch being of no consequence to the included vulnerable version of file. > > `USE=-dbtool emerge =sleuthkit-2.09` works otherwise. What we get here is to give our users a broken stable branch (via USE flag or not) what gives a very poor QA. When you are using the stable branch, you hope everything to works fine, everything means whatever combination of USE flags you have. Sometimes is not possible to test all the USE flags combinations but in this case, where we already know there is a broken combination, seems like a no-no to me marking as stable this version. > > I think it's up to the maintainer to stop the stabilisation process. falco CC'd > the arches. falco CC'd the arches (look when this happened) and didn't mention something about a broken USE. We don't know if he is aware of the not working USE. I'm quite sure that anybody is going to ask for stable a version with a known broken USE. > > Besides, dertobil23 marked ppc stable before I did. Why did you ask me, not > him? > dertobi123 probably has tested the package without the broken USE, so he didn't realize of the problem. Best thing to me, seems like what opfer has done, ask the maintainer and see what's happing here. Believe me that this is nothing personal with you, just wanted to know your reasons for going to a stable with a broken USE. I understand your position of respecting the maintainer desires but, in this case, I'm not sure if falco knows about the problem and anyway, and always IMHO, Gentoo shouldn't allow a broken stable branch on any arch. @dertobi123: maybe you are interested in the problem with this version. Sorry to CC'd you, if don't. rbu@gentoo.org 2007-09-21 11:21:26 0000 Falco uploaded the file so it's on the mirrors now. Arches, please go for stabling here. hppa and ppc, you are already stable, but maybe you want to retry with the dbtool-patch. fauli@gentoo.org 2007-09-21 13:08:51 0000 (In reply to comment #16) > Falco uploaded the file so it's on the mirrors now. Hooray! x86 stable jer@gentoo.org 2007-09-21 17:03:40 0000 It appears to work. dertobi123@gentoo.org 2007-09-25 17:18:05 0000 (In reply to comment #16) > hppa and ppc, you are already stable, but maybe you want to retry with the > dbtool-patch. > worksforme armin76@gentoo.org 2007-09-26 19:29:01 0000 sparc stable philantrop@gentoo.org 2007-09-28 17:08:09 0000 Marked stable on amd64. rbu@gentoo.org 2007-09-28 23:00:26 0000 B2 -> GLSA. Please file a request. py@gentoo.org 2007-09-29 13:59:35 0000 (In reply to comment #22) > B2 -> GLSA. Please file a request. > done. but I think you can do it yourself now ;) falco@gentoo.org 2007-10-18 22:45:32 0000 GLSA 200710-19, eventually