| Summary: | app-forensics/sleuthkit < 2.09 includes vulnerable "file" code | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Hanno Böck <hanno> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | forensics+obsolete, jer, radhermit |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://sourceforge.net/project/shownotes.php?release_id=515880&group_id=55685 | ||
| Whiteboard: | B2 [glsa] Falco | ||
| Package list: | Runtime testing required: | --- | |
|
Description
Hanno Böck
2007-06-14 02:10:15 UTC
*** Bug 182708 has been marked as a duplicate of this bug. *** 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. 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. bumped and trying to fix bug 131268 at the same time. 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. ppc stable >>> Test phase [test]: app-forensics/sleuthkit-2.09 sh ./check-install Checking Tools ERROR: Missing 'file' command Done >>> Install sleuthkit-2.09 into ... Stable for HPPA nonetheless. 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 (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 So what are we going to do with this package? Are arches still needed here? (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. (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? (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. 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. (In reply to comment #16) > Falco uploaded the file so it's on the mirrors now. Hooray! x86 stable It appears to work. (In reply to comment #16) > hppa and ppc, you are already stable, but maybe you want to retry with the > dbtool-patch. > worksforme sparc stable Marked stable on amd64. B2 -> GLSA. Please file a request. (In reply to comment #22) > B2 -> GLSA. Please file a request. > done. but I think you can do it yourself now ;) GLSA 200710-19, eventually |