Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 181977 - app-forensics/sleuthkit < 2.09 includes vulnerable "file" code
Summary: app-forensics/sleuthkit < 2.09 includes vulnerable "file" code
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL: https://sourceforge.net/project/shown...
Whiteboard: B2 [glsa] Falco
Keywords:
: 182708 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-06-14 02:10 UTC by Hanno Böck
Modified: 2008-01-10 08:54 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hanno Böck gentoo-dev 2007-06-14 02:10:15 UTC
See subject, new version available.
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2007-06-20 17:59:39 UTC
*** Bug 182708 has been marked as a duplicate of this bug. ***
Comment 2 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-08-10 23:54:25 UTC
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.
Comment 3 Matt Drew (RETIRED) gentoo-dev 2007-08-11 00:11:54 UTC
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.
Comment 4 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-08-29 14:50:13 UTC
bumped and trying to fix bug 131268 at the same time.
Comment 5 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-08-29 14:53:45 UTC
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.
Comment 6 Tobias Scherbaum (RETIRED) gentoo-dev 2007-08-29 19:07:09 UTC
ppc stable
Comment 7 Jeroen Roovers gentoo-dev 2007-08-30 02:50:12 UTC
http://distfiles.gentoo.org/distfiles/sleuthkit-2.09_dbtool.patch.bz2 gives a 404...
Comment 8 Jeroen Roovers gentoo-dev 2007-08-30 03:00:59 UTC
>>> Test phase [test]: app-forensics/sleuthkit-2.09
sh ./check-install

Checking Tools
ERROR: Missing 'file' command
Done

>>> Install sleuthkit-2.09 into ...
Comment 9 Jeroen Roovers gentoo-dev 2007-08-30 03:10:29 UTC
Stable for HPPA nonetheless.
Comment 10 Willard Dawson 2007-08-30 16:11:24 UTC
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


Comment 11 Jeroen Roovers gentoo-dev 2007-08-30 16:22:14 UTC
(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
Comment 12 Christian Faulhammer (RETIRED) gentoo-dev 2007-09-05 05:22:47 UTC
So what are we going to do with this package?  Are arches still needed here?
Comment 13 Jose Luis Rivero (yoswink) (RETIRED) gentoo-dev 2007-09-05 10:40:33 UTC
(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.
Comment 14 Jeroen Roovers gentoo-dev 2007-09-05 13:50:54 UTC
(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?
Comment 15 Jose Luis Rivero (yoswink) (RETIRED) gentoo-dev 2007-09-05 14:16:31 UTC
(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.
Comment 16 Robert Buchholz (RETIRED) gentoo-dev 2007-09-21 11:21:26 UTC
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.
Comment 17 Christian Faulhammer (RETIRED) gentoo-dev 2007-09-21 13:08:51 UTC
(In reply to comment #16)
> Falco uploaded the file so it's on the mirrors now.

 Hooray!  x86 stable
Comment 18 Jeroen Roovers gentoo-dev 2007-09-21 17:03:40 UTC
It appears to work.
Comment 19 Tobias Scherbaum (RETIRED) gentoo-dev 2007-09-25 17:18:05 UTC
(In reply to comment #16)
> hppa and ppc, you are already stable, but maybe you want to retry with the
> dbtool-patch.
> 

worksforme
Comment 20 Raúl Porcel (RETIRED) gentoo-dev 2007-09-26 19:29:01 UTC
sparc stable
Comment 21 Wulf Krueger (RETIRED) gentoo-dev 2007-09-28 17:08:09 UTC
Marked stable on amd64.
Comment 22 Robert Buchholz (RETIRED) gentoo-dev 2007-09-28 23:00:26 UTC
B2 -> GLSA. Please file a request.
Comment 23 Pierre-Yves Rofes (RETIRED) gentoo-dev 2007-09-29 13:59:35 UTC
(In reply to comment #22)
> B2 -> GLSA. Please file a request.
> 

done. but I think you can do it yourself now ;)
Comment 24 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2007-10-18 22:45:32 UTC
GLSA 200710-19, eventually