Bug 693

Summary: coredumps with long filenames
Product: [Retired] Red Hat Powertools Reporter: Mike Wangsmo <wangsmo>
Component: tripwireAssignee: Mike Maher <mike>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 5.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-02-11 22:46:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mike Wangsmo 1999-01-05 17:32:50 UTC
> Chuck Campbell (campbell) 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)
>
> bellow is the patch to tripwire 1.2 (as it is on
coast.cs.purdue.edu, and
> ftp.redhat.com sites), and message from Gene Spafford
which I received for
> responce to my message. I wasn't able to test this bug on
commercial
> tripwire, but since people still use free version, this
problem still might
> be applicable.
>
> ---------- Forwarded message ----------
> Date: Sun, 03 Jan 1999 10:25:36 -0500
> From: Gene Spafford <spaf.edu>
>
> [Form-letter response, last modified 8/16/98]
>
> Thanks for your inquiry about Tripwire.
>
> In mid-December 1997, Tripwire Security Systems, Inc.
(formerly Visual
> Computing Corporation) acquired the license for our
Tripwire
> change/intrusion detection system. They are now marketing
an enhanced,
> supported version of Tripwire for Unix-based machines.
They are also
> planning a Windows NT version of Tripwire for release
sometimes in late
> 1998. Gene Kim, my former student and the original author
of Tripwire,
> is the VP of TSS, and I may have some technical advisory
role in these
> developments. All enquiries about Tripwire sales and
technical support
> should be directed to:
>     W. Wyatt Starnes
>     President
>     Tripwire Security Systems, Inc.
>     615 SW Broadway
>     Portland, Oregon 97205
>     Phone: (503) 223-0280
>     FAX: (503) 223-0182
>     tripwire
>
> You can visit the Tripwire WWW site at
> <http://www.tripwiresecurity.com/> for details on the
latest release of
> the program, and for assistance with problems with
previous versions.
> Note that personnel at Purdue are no longer supporting
Tripwire.
>
> Please also note that Tripwire is a registered trademark
of the Purdue
> Research Foundation, and it is also licensed to TSS.
>

Comment 1 Mike Wangsmo 1999-01-05 17:52:59 UTC
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.

Comment 2 Mike Maher 1999-02-11 22:46:59 UTC
added patch to fix tripwire