[8947] in bugtraq
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
