Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 10 Jun 2013 07:47:01 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: peculiar problem with fmt->params.max_keys_per_crypt in bleeding

On 8 Jun, 2013, at 7:56 , Sayantan Datta <std2048@...il.com> wrote:
> I checked and rechecked my format methods like a thousand times but then I decided to go a little deeper because I am sure the segfault wasn't from any of the internal methods. Although it may be due to some wrong setup in the format. So I checked into cracker.c(and other relevant files) to find out any memory allocations based on max_keys_per_crypt. I modified line number 123 in cracker.c to the following and the problem was gone.
> 
> if (db->loaded) {
>         size = /*crk_params.max_keys_per_crypt*/2097152 * sizeof(int64);
>         memset(crk_timestamps = mem_alloc_tiny(size,sizeof(int64)), -1, size);
> 

The above code is core code, except core use mem_alloc() instead of mem_alloc_tiny().

This looks like a core bug to me, or I don't understand the intent. The above is in crk_init() - I hope this is after fmt_init() where we (even in OMP) normally tune max_keys_per_crypt. At what point is set_mask() called? Maybe that function should decrease max_keys_per_crypt accordingly, so that the total max_keys_per_crypt (which was reported at first and used for the allocation in crkinit()) will hold the "running" max_keys_per_crypt that is lower but will be amplified with the set_mask variations. However, I see that format.params are *copied* to crk.params so if you change it after crk_init(), cracker.c will still use the old value. So I can't see how all this can fit together without slight core changes.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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