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[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.