cq format segfault

[frank-dittrich]

(bleeding-jumbo)run $ ./john fail_cq.pw
Segmentation fault (core dumped)

See fail_cq.pw (29 bytes) attached to my john-dev message from Nov., 13th. Subject: [john-dev] Segfault in cq, eigrp, and skey formats

Unfortunately, the file contains non-ascii characters, so I don't know whether john still segfaults with the contents I get when I try copy&paste:

t%8r:$cq$c|earque:ö$a279b184

And here's another one that causes this format to segfault (64bit Linux autoconfig build):

45š0:$cq$ádmind10: 2!8Ê48:$bq$almin$4cfb73f2

[frank-dittrich]

Even if the contents differs from the original file: when I copy the first test into a new file, john still segfaults. But when I copy the second test, john no longer fails on this one, instead I get

No password hashes loaded (see FAQ)

[jfoug]

can you please post the input files using ../run/base64conv

../run/base64conv -i raw -o hex whatever_garbage_file

That way it will be 100% usable. I can simply switch -i and -o and get original file back.

[jfoug]

This file is enough to trigger the core in cq:

:$cq$aaaaaaaa

Any file with 8 character after the $cq$ will trigger it. What happens is valid says it is ok (strrchr $ leaves 8 chars.

Then within salt, the code skips past the $cq$ and then looks for the next '$'. There is none, so it gets a null pointer, and thus crashes.

We should look for other formats that do similar things (in valid, look for strrchr '$' and then simply use a length). For that logic to work, the '$' value can NOT be part of the signature!

I will post the fix in a minute or so.

[magnumripper]

We should look for other formats that do similar things

Lol. There are hundreds of them.

[jfoug]

This one was likely 'triggered' because the hash is SO short. 8 chars. What happened in the bad data, was there was a user name, and the 9th byte of the user name was a ':' char. john core cut that into a separate field, and sent it to valid. Valid saw 8 bytes past the last '$' and said it was OK. Then in get_salt, it could not find the next '$', got the null, and cored.

It sounds like this bug is in many formats. IRL, it probably does not get hit often. But we should look at fixing these valids. That is NOT a small project. It really is a project that someone should undertake however, and once we DO get fully valid valid()'s, we should pretty much demand that all new formats have at a minimum a fully functional valid to be included in the jumbo set.

[frank-dittrich]

I used a slightly changed version of the "primitive fuzzer for john hashes" posted by Alexander Cherepanov in April, 2013 http://thread.gmane.org/gmane.comp.security.openwall.john.devel/8105 to find formats that crash. I think I created open issues for all CPU formats I was able to crash.

[magnumripper]

That's pretty few then, let's fix just these for now.