>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) 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. Casper
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:27:28 PDT