Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 693

Summary: coredumps with long filenames
Product: [Retired] Red Hat Powertools Reporter: Mike Wangsmo <wangsmo>
Component: tripwireAssignee: Mike Maher <mike>
Severity: high Docs Contact:
Priority: medium    
Version: 5.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
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:

Description Mike Wangsmo 1999-01-05 17:32:50 UTC
> Chuck 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 =
>             *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, and
> sites), and message from Gene Spafford
which I received for
> responce to my message. I wasn't able to test this bug on
> 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 <>
> [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
> 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
> You can visit the Tripwire WWW site at
> <> 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
> 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