[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHNEV5T_TNRisaqhbpdvQhsEQOCskWN-heMDbZJBKZJCkTLtLw@mail.gmail.com>
Date: Sun, 19 Apr 2015 15:45:33 -0400
From: Mathieu Laprise <mathlaprise@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Improving Johnny
Thanks for your interesting comment Alexander. I didn't think about that.
PS : Regarding my work-in-progress of the Translator class, my design
doesn't allows to translate the top down list because I used the complete
name as ids(error because they are not unique, they are translatable) and
for my comparison. It will be really easy to fix, I'll instead use the
language code that people and Qt use(ex: english =en) which is a unique id.
On Sun, Apr 19, 2015 at 3:06 PM, Solar Designer <solar@...nwall.com> wrote:
> 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
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
