Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ