Re: CVE request: jhead

[Tomas Hoger <thoger () redhat com>]

On Thu, 19 Mar 2009 20:01:51 -0400 (EDT) "Steven M. Christey"
<coley () linus mitre org> wrote:

> On Fri, 6 Feb 2009, Tomas Hoger wrote:

Oh, my memory about this got even more rusty, so this is from quick
re-fresh, hope I do not get this wrong...

> > > 1 - long -cmd
> > > 2 - unsafe temp file creation
> > > 3 - "more unchecked buffers" and "unsafe buffer sized strcat's in
> > >    ModifyDescriptComment"  [this assumes that upstream only fixed
> > >    issue 1)
> > > 4 - shell escapes
>
> So CVE-2008-4641 was assigned to issue 4, and CVE-2008-4639 was
> assigned to issue 2.  However, I made a mistake in CVE-2008-4639 and
> said "before 2.84" instead of "2.84 and earlier."  I've since fixed
> the CVE-2008-4639 description to say ""2.84 and earlier."

IIRC, my confusion was about CVE-2008-4639 vs. CVE-2008-4640, the both
seem to be just a different consequences of the same problem with odd
way to create temporary file.  Ok, so if you create temp file by
changing the last character of the original name, you have predictable
temporary file name (and possibility for symlink attack, assuming jhead
is used on files stored in world-writable directory) and also
overwrite / remove existing file with that name stored in given
directory.  As far as I can see, that deletion should be limited to
files in jhead's destination directory, so not really arbitrary I'd say.

> Now what's this about 2.86?... Sounds like it may be a regression.

As jhead creates those temporary files in its "destination" directory,
this (as well as the original "unsafe temp file creation") can only be
a problem if jhead is instructed to use /tmp (or possibly run on files
in /tmp, I don't remember exactly).  Along with not-so-easily guessable
names and need to win a race, it sounds quite minor.

-- 
Tomas Hoger / Red Hat Security Response Team