Closed frank-dittrich closed 9 years ago
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)
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.
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.
We should look for other formats that do similar things
Lol. There are hundreds of them.
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.
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.
That's pretty few then, let's fix just these for now.
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:
And here's another one that causes this format to segfault (64bit Linux autoconfig build):