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 - coredumps with long filenames
Summary: coredumps with long filenames
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Powertools
Classification: Retired
Component: tripwire
Version: 5.2
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Mike Maher
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-01-05 17:32 UTC by Mike Wangsmo
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 1999-02-11 22:46:30 UTC


Attachments (Terms of Use)

Description Mike Wangsmo 1999-01-05 17:32:50 UTC
> 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 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


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