[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a4ba79156967062c864f533914bea682@smtp.hushmail.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
