Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Mar 2015 23:24:47 +0800
From: Kai Zhao <loverszhao@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Any advice on how to fuzz john jumbo by AFL

> This might, or might not, make the problem currently not triggerable -
> we'd need to analyze this more thoroughly - but it certainly has
> potential signed integer overflows, which are undefined behavior in C,
> so code like this better be cleaned up.  Ideally, someone should rewrite
> pieces like this to make them clean and robust.

> Alexander

Hi Alexander, thank you for your advice. I will do some code review and
fuzz testing.

On Sat, Mar 7, 2015 at 11:17 PM, Solar Designer <solar@...nwall.com> wrote:

> On Sat, Mar 07, 2015 at 04:30:43PM +0300, Solar Designer wrote:
> > The really brief comment from me, though, is that fuzzing must not be
> > the only method to find bugs in jumbo.  For example, integer overflow on
> > "+ 1" might take lots of time to fuzz, but is apparent at first glance.
>
> For example:
>
> egrep 'alloc.*\+' *_fmt*.c | less
>
> finds this (among other things):
>
> ssh_fmt_plug.c: decoded_data = (char *) mem_alloc(filelength + 1);
>
> static void *get_salt(char *ciphertext)
> {
> [...]
>         int i, filelength;
> [...]
>         filelength = atoi(strtok(NULL, "*"));
> [...]
>         decoded_data = (char *) mem_alloc(filelength + 1);
>
> Now, this is only invoked on strings that passed valid(), which has:
>
> static int valid(char *ciphertext, struct fmt_main *self)
> {
> [...]
>         char *p;
>         int res;
>         int length;
> [...]
>         length = strlen(p);
> [...]
>         if ((p = strtok(NULL, "*")) == NULL)    /* length */
>                 goto err;
>         if (!ishex(p))
>                 goto err;
>         res = atoi(p);
>
>         if(length != res * 2)
>                 goto err;
>
> This might, or might not, make the problem currently not triggerable -
> we'd need to analyze this more thoroughly - but it certainly has
> potential signed integer overflows, which are undefined behavior in C,
> so code like this better be cleaned up.  Ideally, someone should rewrite
> pieces like this to make them clean and robust.
>
> Alexander
>



-- 
loverszhaokai
motto:You got a dream and you gotta protect it.
github:https://github.com/loverszhaokai
blog:http://www.cnblogs.com/lovers/

[ CONTENT OF TYPE text/html SKIPPED ]

Powered by blists - more mailing lists

Your e-mail address:

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