[ossec-dev] Re: [Bug 87] New: os_regex_maps hostname_map errors

["Daniel Cid" <dcid@xxxxxxxxx>]

Hi,

Regarding the hostname map, your assessment is not correct.

In the map, the characters that we want to use (a-z, A-Z, 0-9, etc) are set
to "\001" and all the others are kept in any other way (generally their default
value). When we use isValidChar, we check if the return code is 1, not the
value of the character.

So, we allow the desired and deny everything else, like the good security
practices tell us :)

As for the sun compiler, I never used that, but the mapping is set to
unsigned char, so it shouldn't be a problem.... However, without access to
the compiler, it is very hard for me to fix it (patches welcome).

Thanks,

--
Daniel B. Cid
dcid ( at ) ossec.net


On 10/10/07, ossec-bugzilla@xxxxxxxxxxxxxxxxxxxxxxxxxxx
<ossec-bugzilla@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> http://www.ossec.net/bugs/show_bug.cgi?id=87
>
>            Summary: os_regex_maps hostname_map errors
>            Product: OSSEC
>            Version: 1.4
>           Platform: All
>         OS/Version: All
>             Status: NEW
>           Severity: normal
>           Priority: P3
>          Component: ossec core
>         AssignedTo: ossec-dev@xxxxxxxxx
>         ReportedBy: t@xxxxxxxx
>
>
> Sun's compiler throws errors when parsing the hostname_map array in
> os_regex/os_regex_maps.h. For elements greater than octal 127 (\200+),
> compilation fails with a message like "line 33: warning: initializer does not
> fit or is out of range: -128". The compiler doesn't complain if hostname_map
> elements are specified as hex or decimal; One solution could simply be to state
> "OSSEC only supports the gcc compiler", but I think this bit of code should be
> made cleaner.
>
> According to the documented code, the hostname charmap is a list of available
> characters: "a-z, A-Z, 0-9, -, _, ., @". This is sort of misleading, because
> isValidChar doesn't verify that that the input contains only valid characters;
> it instead checks the input for undesired characters. From a security
> standpoint, my personal opinion is that ossec should verify input contains only
> the desired characters, and not look for characters you don't want. In other
> words: instead of "deny the undesired, allow everything else", "allow the
> desired, deny everything else."
>
> Following this method, the set of items would be smaller, and the missing items
> would be more apparent (as would the 68 extra entries of \001). If the list of
> desired characters is correct, these additional characters are mistakenly
> allowed:
>     0x28 (
>     0x29 )
>     0x2F /
>     0xF8 through 0xFF - accented characters
>
>
> --
> Configure bugmail: http://www.ossec.net/bugs/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>