As I mentioned yesterday in the firewall wizards list: There has been a linux patch for tripwire available for sometime, it was broken though. I discovered it was broken a few months ago, and contacted the individual that put forth the linux/trip patch at the UofM. After a slight bit f mucking about, he was able to produce a nice functional patch, and it should perhaps be up on sunsite once again, though might not. The patch obtsained dose a tad bit more then the currsory patch supplied here, making it far easier to get a non-core dumping tripwire up and running with far less editing and refixing of other files in the tripwire source tree. folks requireing such can look about sunsite or contact me to request the patch. I've looked about my archives to give credit where due to the engineering dude at the UofM here, but have yet to locate that set of e-mail exchanges. Thanks, Ron DuFresne On Mon, 4 Jan 1999, CyberPsychotic wrote: > 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 (campbellat_private) 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. > > > regards > > Fyodor > > -<cut here>- > > --- src/utils.c.orig Mon Jul 25 22:23:16 1994 > +++ src/utils.c Sun Jan 3 15:41:00 1999 > @@ -384,7 +384,7 @@ > char *filename; > { > static char filetmp[MAXPATHLEN+256]; > - register char *pcin = filename, *pcout = filetmp; > + register unsigned char *pcin = filename, *pcout = filetmp; > static char *octal_array[] = { > "000", "001", "002", "003", "004", "005", "006", "007", > "010", "011", "012", "013", "014", "015", "016", "017", > @@ -402,8 +402,24 @@ > "150", "151", "152", "153", "154", "155", "156", "157", > "160", "161", "162", "163", "164", "165", "166", "167", > "170", "171", "172", "173", "174", "175", "176", "177", > + "200", "201", "202", "203", "204", "205", "206", "207", > + "210", "211", "212", "213", "214", "215", "216", "217", > + "220", "221", "222", "223", "224", "225", "226", "227", > + "230", "231", "232", "233", "234", "235", "236", "237", > + "240", "241", "242", "243", "244", "245", "246", "247", > + "250", "251", "252", "253", "254", "255", "256", "257", > + "260", "261", "262", "263", "264", "265", "266", "267", > + "270", "271", "272", "273", "274", "275", "276", "277", > + "300", "301", "302", "303", "304", "305", "306", "307", > + "310", "311", "312", "313", "314", "315", "316", "317", > + "320", "321", "322", "323", "324", "325", "326", "327", > + "330", "331", "332", "333", "334", "335", "336", "337", > + "340", "341", "342", "343", "344", "345", "346", "347", > + "350", "351", "352", "353", "354", "355", "356", "357", > + "360", "361", "362", "363", "364", "365", "366", "367", > + "370", "371", "372", "373", "374", "375", "376", "377", > }; > - register char *pccopy; > + register unsigned char *pccopy; > > /* these only matter if they are the first character */ > if (*pcin == '!' || *pcin == '=' || *pcin == '#') > > --<cut here>-- > > ---------- Forwarded message ---------- > Date: Sun, 03 Jan 1999 10:25:36 -0500 > From: Gene Spafford <spafat_private> > > [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 > tripwireat_private > > 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. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:27:40 PDT