lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <200310272256.h9RMuiJg004518@linus.mitre.org> From: coley at mitre.org (Steven M. Christey) Subject: [inbox] Re: RE: Linux (in)security 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*).
Powered by blists - more mailing lists