Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 13 Aug 2015 12:05:14 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Lei's weekly report #15

On Aug 13, 2015, at 11:05 AM, jfoug@....net wrote:
> 
> On Wed, 12 Aug 2015 21:38:24 -0500, Lei Zhang <zhanglei.april@...il.com> wrote:
> 
> 
>> I got this error message:
>> 
>> form=episerver_sha1               guesses: 1476 -show=1476 0:00:00:00 DONE : Expected count(s) (1500)  [!!!FAILED1!!!]
>> .pot CHK:episerver_sha1           guesses: 1476 0:00:00:00 DONE  [PASSED] (1476 val-pwd)
>> 
>> form=episerver_sha256             guesses: 1476 -show=1476 0:00:00:00 DONE : Expected count(s) (1500)  [!!!FAILED1!!!]
>> .pot CHK:episerver_sha256         guesses: 1476 0:00:00:00 DONE  [PASSED] (1476 val-pwd)
>> 
>> What does that mean?
> 
> It 'may' be expected.   There are some tests which we will have to add specific multiple 'valid' number of passing tests. These are due to some data within the test being longer passwords than certain builds can handle.
> 
> This also may mean that there are BUGS.  If the code blindly inserts data, and you do not have proper length settings, then you will get longer passwords sent to your format, which can overwrite internal buffers of the candidates around the one you are writing data to.
> 
> So either way, we need to find out.  If you run the ts with these command switches:
> 
> -v -v -v --stop   it will print out a whole lot of stuff to screen, but it will stop on the first error. It shows you the command used that failed.  So now, you can run that command by hand, then use the -show and -show=left to find out what was found, and what was 'missed'.  If all of the missed data is long passwords, then we will need to adjust the jtrts.dat file saying that 1476 is a 'correct' possibility for this format.   If the missed words vary, then again, it is likely that you have not set the plaintext length properly, which would allow the very long passwords (120's, 125's, 128's) scattered in the input dictionary to smash your buffers.  That is exactly why those longer passwords were put in there, to help force problems like this, when a format is too promiscuous allowing data that are longer than it can handle.

Thanks for the tips.

I found those 24 uncracked passwords are indeed the longest passwords, with a length of 25, while the SIMD build of episerver only support plaintext length of up to 19.

So I guess the number 1476 will need to be put in jtrts.dat.


Lei

Powered by blists - more mailing lists

Your e-mail address:

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