Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 30 Dec 2012 11:25:46 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Rejecting hashes in valid() due to memory allocation
 failures?

On 12/30/2012 10:37 AM, Dhiru Kholia wrote:
> On Sun, Dec 30, 2012 at 1:39 PM, Frank Dittrich <frank_dittrich@...mail.com> wrote:
>> How unlikely is it that a memory allocation failure occurs when trying
>> to crack a huge number of passwords?
>> (This could also be caused by strict ulimit settings.)
>> IMHO, In such a case we shouldn't silently drop valid hashes as if they
>> were invalid, but instead at least print some kind of error message.
>> (May be even change the interface and allow a negative return value in
>> valid(), to signal that there is a more general problem, so that we
>> don't get thousands of error messages for memory allocation failures...)
> 
> diff --git a/src/pbkdf2-hmac-sha512_fmt_plug.c
> b/src/pbkdf2-hmac-sha512_fmt_plug.c
> index e6471b9..f560195 100644
> --- a/src/pbkdf2-hmac-sha512_fmt_plug.c
> +++ b/src/pbkdf2-hmac-sha512_fmt_plug.c
> @@ -90,8 +90,10 @@ static int valid(char *ciphertext, struct fmt_main *self)
> 
>         if (strncmp(ciphertext, FORMAT_TAG, strlen(FORMAT_TAG)))
>                 return 0;
> -       if (!(ctcopy = strdup(ciphertext)))
> +       if (!(ctcopy = strdup(ciphertext))) {
> +               fprintf(stderr, "Memory allocation failed in %s,
> unable to check if hash is valid!", FORMAT_LABEL);
>                 return 0;
> +       }
>         keeptr = ctcopy;
>         ctcopy += strlen(FORMAT_TAG);
>         if (!(ptr = strtok(ctcopy, ".")))
> 
> Does this look OK?

Actually, I just wanted to raise general awareness of a possible issue.
I doubt that you'll ever try to crack so many GRUB2 hashes that you run
into this issue.
(It is also unlikely that many ciphertexts of other formats start with
"$pbkdf2-hmac-sha512$".)

But for formats where this could happen, I don't think one error message
per memory allocation failure is a good idea.

Frank

Powered by blists - more mailing lists

Your e-mail address:

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