Bug 693 - coredumps with long filenames
coredumps with long filenames
Status: CLOSED CURRENTRELEASE
Product: Red Hat Powertools
Classification: Retired
Component: tripwire (Show other bugs)
5.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Mike Maher
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-01-05 12:32 EST by Mike Wangsmo
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-02-11 17:46:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mike Wangsmo 1999-01-05 12:32:50 EST
> 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)
>
> 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@cs.purdue.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@tripwiresecurity.com
>
> 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 12:52:59 EST
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 17:46:59 EST
added patch to fix tripwire

Note You need to log in before you can comment on or make changes to this bug.