[8947] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Tripwire mess..

daemon@ATHENA.MIT.EDU (Casper Dik)
Tue Jan 5 12:08:27 1999

Date: 	Tue, 5 Jan 1999 11:43:33 +0100
Reply-To: Casper Dik <casper@HOLLAND.SUN.COM>
From: Casper Dik <casper@HOLLAND.SUN.COM>
X-To:         CyberPsychotic <fygrave@TIGERTEAM.NET>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  Your message of "Mon, 04 Jan 1999 17:10:16 +0500." 
              <Pine.LNX.4.05.9901041626190.15582-100000@gizmo.kyrnet.kg>

>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

home help back first fref pref prev next nref lref last post