Re: [inbox] Re: RE: Linux (in)security

["Steven M. Christey" <coley () mitre org>]

An alternate way of viewing the security of an application or
operating system is to evaluate the nature of the discovered
vulnerabilities.  Are they blatantly obvious, ancient bugs that could
have been found in basic auditing or testing?  Or are they new classes
of bugs, and/or more subtle?  Do they appear only in rarely used
configurations or features of the software?  Are there design choices
that make it easier (or more difficult) to become susceptible to
certain types of implementation-level vulnerabilities?

Consider "buffer overflows," which these days come in different shapes
and sizes, enough that the term "classic buffer overflow" is showing
up more often.  If an application barfs when you send it a long
string, I'd say that might be a bad indicator of the quality of the
rest of the software.  But if it can only be exploited by manipulating
length fields and performing numerous encodings for a limited set of
characters across multiple separate "messages," then that's a little
different: it's a "newer" type of overflow (from the programming error
perspective) that's harder to find in auditing and testing.

Consider the vulnerabilities that have been reported in Sendmail,
wu-ftp, and Apache over the past year or two.  Most of them aren't
immediately obvious (even the ones labeled "buffer overflows"), and in
some cases, the vulnerabilities were among the first of that type to
be reported (signal handler race conditions, anyone?).

Actually, Apache is an interesting example.  While the Unix version
has had a pretty good record lately in terms of being mostly limited
to "esoteric" bugs, the *Windows* versions of Apache have had some
"obvious" Windows vulnerabilities in the past couple years: DOS device
names, Windows-specific filename canonicalization errors, directory
traversal using "\" etc.

If some software *only* has fairly esoteric bugs, and there appears to
be some record of security auditing in its past, then maybe that's
another important data point besides just raw numbers.

- Steve

P.S. If anyone cares, I agree with the "theme" that certain
improvements or design choices in programming languages could wipe out
or significantly reduce entire classes of vulnerabilities by depending
less on the programmer to do their own work.  One of the most obvious
cases is the PHP remote file include bug.  Some of the subtler ones
are all the filename variants in Windows that wind up pointing to the
same physical file, which force programmers to be aware of every
variant (or use a filename canonicalization function *first*).

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html