[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <004301ce219d$66dc2a90$34947fb0$@yahoo.com>
Date: Fri, 15 Mar 2013 17:51:54 +0100
From: "Costin Enache" <e_costin@...oo.com>
To: <john-dev@...ts.openwall.com>
Subject: err in rules processor and dirty fix [rules.c]
Ugly thing in the rule processor, when the rules are using \xHH
representation and the rule line size exceeds 0x100; this is only my
particular case, it can generate errors in many other ways.
The (params.h) RULE_BUFFER_SIZE is used for the rule pre-processor output,
as defined in rpp.h:
/* Current rule after preprocessing */
char output[RULE_BUFFER_SIZE];
The same RULE_BUFFER_SIZE is used in rules.c in rules_reject:
char *rules_reject(char *rule, int split, char *last, struct db_main *db)
{
static char out_rule[RULE_BUFFER_SIZE];
The rules_reject function is called for unprocessed data, as it comes from
the config file, for example to remote duplicate rules
(rules_load_normalized_list).
The unprocessed data can easily be over 0x100, such as in my unfortunate
case, when using \xHH for a long character list. In this case the remove
duplicates function will only compare the first 0x100 bytes of the rules -
dumping all the rules which begin with the same 0x100 bytes.
Quick and dumb fix, not sure that it is 100% ok and what else it breaks, but
it solves my hex encoding problem:
--- rules.c.orig 2013-03-15 17:34:14.000000000 +0100
+++ rules.c 2013-03-15 17:34:22.000000000 +0100
@@ -701,7 +701,7 @@
char *rules_reject(char *rule, int split, char *last, struct db_main *db)
{
- static char out_rule[RULE_BUFFER_SIZE];
+ static char out_rule[4*RULE_BUFFER_SIZE];
while (RULE)
switch (LAST) {
Cheers,
Costin
Content of type "text/html" skipped
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.
