Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Jul 2016 16:19:20 +0300
From: Solar Designer <>
Subject: Re: rules.c bug/feature

On Fri, Jul 08, 2016 at 02:24:58PM +0200, magnum wrote:
> 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.

You're right.  I didn't bother reproducing it, but I think I know what
the problem is: when I introduced the "length" variable some years ago,
I forgot to update the loop logic to clamp not only the buffer but also
this integer variable to the maximum length.  I think the attached patch
should fix it.  I'll test and commit it.


View attachment "john-rules-length.diff" of type "text/plain" (921 bytes)

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.