john-dev - Re: Any advice on how to fuzz john jumbo by AFL

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150307151751.GA17277@openwall.com>
Date: Sat, 7 Mar 2015 18:17:51 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Any advice on how to fuzz john jumbo by AFL

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.