[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fc8a746a4263191979a98b0d46611eea@smtp.hushmail.com>
Date: Wed, 20 Mar 2013 20:53:47 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: err in rules processor and dirty fix [rules.c]
On 20 Mar, 2013, at 19:04 , Costin Enache <e_costin@...oo.com> wrote:
> The 4x change solves the hex encoding, but I don't think it's enough. The rules_reject function is used for both expanded and unprocessed data. For expanded rules, the size is ok, and with the 4x increase, it fits also hex values. However, the same RULE_BUFFER_SIZE must fit (fortunately, only to check for invalid rules) the unprocessed ones, which can be very long, mostly because of character ranges.
Even a list of the full 1-255 range, fully encoded in hex and not using ranges to compress it, can't be longer than 0x400. I can't dream of a line that needs 0x5000 like you write below:
> Take my case: I need to prepend and append machine-generated characters, and I am too lazy to check what is "common" and what is "special" character, so the easiest way is to encode all of them to hex representation. It is very easy to reach the buffer limit. As a temporary solution, I have increased the RULE_BUFFER_SIZE value in params.h, to 0x5000. This is overkill for already processed/ expanded rules. We could have two "rules_reject" functions, one of expanded and one for unprocessed rules ... not sure this is ok.
So 0x100 is not enough even if we did not have the hex encoding? Your rules must be extreme! Anyway, I think even core John should emit a warning when rules get truncated (should be possible to catch outside the performance critical code).
> I'd avoid patching for now, and it would be better if the original author of the rules parsing code could have a look into this, and see what needs to be changed (otherwise we might overlook some implication of the changes, get funny errors later, or waste memory on already processed rules).
Unfortunately the original author is Solar while the hex encoding magic was made by Jim and me (I added missing stuff for range support). Solar don't usually go out of his way to solve Jumbo bugs - even if he wanted to, he doesn't have the time. On a good day he'll give us a clue off the top of his head. This situation is not too uncommon in Jumbo: Usually we fix issues one at a time as we find them :-/
I think we should either 1) apply the fix you posted, and this will do until we know anything else specific. Or 2) we just bump RULE_BUFFER_SIZE to 0x400 instead. That size ought to be enough for sane use ;-) and maybe it benefits some other situations than just hex encodings.
Solar, any thoughts?
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.
