Date: Fri, 8 Jul 2016 16:19:20 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com 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[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. Alexander 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.