Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 6 Jun 2015 11:10:52 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: poor man's fuzzer

On Fri, Jun 05, 2015 at 07:51:18PM +0200, Frank Dittrich wrote:
> On 06/05/2015 02:16 PM, Solar Designer wrote:
> > [solar@...er run]$ ./john fuzz-sample-LUKS-106-18
> > WARNING, LUKS format hash representation will change in future releases,
> > see doc/README.LUKS
> > john: luks_fmt_plug.c:475: get_salt: Assertion `res == cs.afsize' failed.
> > Aborted
> 
> This one is well known. The reason is that luks2john stores the same
> information twice in the hash, and the assertion is there to "prevent"
> loading such inconsistent hashes.
> This assertion also makes fuzzing somewhat harder, since you have to
> make sure to avoid this assertion to find the other bugs.

I think this is improper use of assert().  We should use assert() to
make assertions about the program's own behavior (and we should ensure
that assertions are never false, fixing any false assertions as bugs),
not about its input.

For assertions about the input, we should use explicit checks and either
user-friendly output or just valid() returning 0 (like it would on many
other erroneous hash strings anyway).

BTW, assert()'s are turned into no-ops when building with -DNDEBUG.
While I don't recommend that we build JtR that way, someone might, and
it does show that assert()'s are there for debugging and arguably
sometimes for some safety in presence of bugs, not as proper means to
detect invalid input.

So can we please fix the above misuse of assert()?  It is a bug.

> But LUKS has other issues as well.
> Instead of extraction the infor from all used slots it just extracts the
> infor from the one slot with lowest iteration count (even if this slot
> might refer to a key file instead of a passphrase).
> 
> See https://github.com/magnumripper/JohnTheRipper/issues/557
> LUKS format and luks2john ("best slot")

Thanks!  Yes, it certainly does appear that there are worse issues with
our LUKS format and luks2john.  I think those should be fixed separately.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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