Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 19 Apr 2015 22:06:44 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Improving Johnny

On Sun, Apr 19, 2015 at 01:18:23PM +0300, Aleksey Cherepanov wrote:
> Great! Really, user and hash are not trusted while such format strings
> could not be used with untrusted data. Both user and hash may contain
> %1 (%2 and %3 would be bad too). Hash may contain %1 in salt part.
> They screw the line and we don't get the result.
> 1) It's a bug.
> 2) This bug may be used as a defensive measure against Johnny so IMHO
> it may be viewed as a vulnerability.

Calling it a vulnerability for that reason is overkill.  Otherwise we'd
also have to call John's processing of "#!comment:" in wordlists a
vulnerability, because someone may deliberately prefix their password
with that string to avoid having it cracked specifically with John.

> I wrote about it earlier.
> http://www.openwall.com/lists/john-dev/2014/11/07/1
> 
> But we did not fix that yet.

OK.  When I suggested that Mathieu spends more time on this, I implied
that he did not comment on the issue of user or hash possibly containing
':' characters.  This is not specific to this line, nor to Johnny, but
that would have been relevant to mention as well.

Oh, and if commenting on potential buffer overflows at all and on how
dynamic memory allocation probably avoids them, also comment on
potential integer overflows when the combined string's length is
calculated for the memory allocation.  Of course, that would be a Qt
bug (in fact, it's very likely there is a bug like this - pretty much
all interfaces of this sort had that issue until some were fixed), and
if so it would need to be fixed there rather than worked around by us,
but if we're trying to come up with an exhaustive list of potential
issues, this would be among them.  (This is probably avoided in practice
by the string components having already been limited in length before.)

Other aspects are whether/how possible memory allocation failure is
handled, and whether/how/when the memory is freed.

And out of total paranoia and for the sake of being exhaustive, we could
also point out that the temporary string contains security sensitive
info, and its memory is probably not zeroized when freed.  Of course,
that's something we don't currently bother to do anywhere in Johnny and
John.  (And this is not easily done reliably in presence of optimizing
compilers.)  We don't have to since no security boundary is crossed,
although software such as GnuPG tries to zeroize memory previously
containing sensitive info anyway (to reduce exposure via swap space and
via possible bugs elsewhere in the system).

Anyway, I agree Mathieu's answer is good.  I am just nitpicking.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ