Re: Tripwire mess..

[casper () HOLLAND SUN COM (Casper Dik)]

> This may be, or may not be a security issue, however, since alot of people
> still use tripwire-1.2 or lesser versions(this is what shipped with R.H.
> Linux 5.2 at least), they might be interested in following detail:
>
> Chuck Campbell (campbell () neosoft com) pointed me out that tripwire dies with
> coredump on R.H. linux, if it hits a filename containing 128-255 characters.
> Playing a bit with debugger I found out that the problem sits around the
> line 417:
>        else if (iscntrl(*pcin)) {
>            *pcout++ = '\\';
>            *pcout++ = *(pccopy = octal_array[(int)(*pcin)]);
>            *pcout++ = *++pccopy;
>            *pcout++ = *++pccopy;
>        }
>
> iscntrl here would return 'true' not only for [0-31] arg, but also for
> [128-255]. It cause two problems here:
> 1. original octal_array contained only 127 elements, reference would go
> outside the array with *pcin>127
> 2. pcin is declared as pointer to char, which caused a negative offset for
> chars in range above 127. (and which actually caused coredump in this case)


This is a very common code problem; typically, these is* macros take
int arguments where the only valid arguments are eitehr -1 .. 255 or
0 .. 255.

Many OSes/compilers use signed chars.

Almost nobody takes proper care in casting char arguments to is*() to
unsigned char.

You'll find unpredictable things in much code, I'm sure.

Casper