oss-security - Re: CVE request: jhead

Openwall Project		/home Owl JtR Pro crypt pam_passwdqc tcb phpass scanlogd popa3d msulogin / Linux BIND / advisories presentations / services donations / wordlists passwords / news community lists wiki CVSweb mirrors signatures
bringing security into open environments

Password Recovery Resources on the Net

[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]

Date: Thu, 16 Oct 2008 12:40:46 -0400
From: "John Dong" <jdong@...ntu.com>
To: "Steven M. Christey" <coley@...us.mitre.org>
Cc: oss-security@...ts.openwall.com, "Jamie Strandboge" <jamie@...onical.com>
Subject: Re: CVE request: jhead

On Wed, Oct 15, 2008 at 2:28 PM, Steven M. Christey
<coley@...us.mitre.org>wrote:

>
> On Wed, 15 Oct 2008, Jamie Strandboge wrote:
>
> > CC'ing John, as he is who found the majority of the issues and
> > coordinated with upstream.
>
> So the jhead changelog only acknowledges "potential string overflows".
>
> John's comment in bug 271020 alludes to various other types of issues, but
> specifics are unknown.  And there are some references to other overflows
> that may or may not have been fixed by upstream.
>
> So, we'd need multiple CVEs, but how many is unclear.
>
> 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
>
>
> Without knowing what exactly is being reported and fixed, it's pretty
> difficult to assign CVEs, especially with phrases like "more unchecked
> buffers" that could apply to anything.

Hi Steven,

Sorry for the delay. I just had a chance to look over the diff of the new
2.84 release. I see that the long cmd and all the unchecked buffers I found
were resolved by use of length-checked strcat functions. In addition, unsafe
tempfile creation was fixed by checking for existence of existing filenames,
trying a larger variety of filenames, and erroring out if there is not an
empty filename. However, this fix doesn't seem complete for DoCommand where
you can trick it to unlink() a file by the name of the input file mangled
with the last char of "z" instead of "t" or vice versa.

The shell escape potential for DoCommand, as far as I can tell, is also not
resolved.

So, bottom line is I think 2.84 fixes 1 and 3 acceptably, while 2 and 4 are
still unresolved.

John

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.