Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Jul 2016 14:24:58 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: rules.c bug/feature

On 2016-07-06 18:27, Solar Designer wrote:
> On Wed, Jul 06, 2016 at 05:27:33PM +0200, magnum wrote:
>> While playing with some old contest rules I found a bug in John that's
>> not Jumbo-specific: Apparently it lacks some checks so a 'ddd' rule will
>> blow the destination buffer even at moderate input lengths (eg. 50).
>
> No, this shouldn't be the case.  It is assumed that any rule command may
> double the word's length, and there's a safeguard inbetween commands.
>
> The buffers are:
>
> 	char buffer[3][RULE_WORD_SIZE * 2 + CACHE_BANK_SHIFT];
>
> and the safeguard is:
>
> 		in[RULE_WORD_SIZE - 1] = 0;
>
> Is this somehow broken?  We should identify the issue and fix it if so.

Sounds good, but then it must be broken somehow. The memcpy in 'd' did 
blow the buffer and overwrote rules_data.classes and I verified this 
happens in John proper too. I'm not sure why but I'll let you handle it.

I debugged it like this: Insert an "int canary;" right before and/or 
after rules_data.memory. Then have gdb watch rules_data.canary and run 
some words through 'dd' and 'ddd' (a ruleset of those two only).

It took me a good while to narrow it down, in Jumbo. I got segfaults 
long after the actual thrashing and it was hard to understand what was 
happening until I realized rules_data.classes was not intact.

I'm sure you can easily replicate this but if you can't I'll write an 
exact procedure.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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