Risk Report: Five years of Red Hat Enterprise Linux 4

https://fedorahosted.org/publican/

Section 3 Threats:
"Exec-Shield is a project which includes support for the No eXecute (NX) memory permission, simulating NX via segment limits"
'Approximating' would be the more appropriate term here, as on systems without NX support exec-shield provides only a best-effort approximation of NX. I've enumerated the ways many times before, and not even including the exec-shield vulnerabilities I reported to Ingo in 2005, it is different from real NX (and from a proper NX 'simulator' like PaX) in the following ways:
* a PT_GNU_STACK marking causes not only the stack to be executable, but the entire userland address space
* 'quantum-like' security: in the case of PIE main executables, the .data and .bss sections of all but the highest mapped ELF object will not be NX. Which object will that be? It's impossible to know a priori due to ASLR, runtime shared object loading, and the mixture of bottom-up ascii-armor area allocation/top-down other allocation. Subsequent execs will generally produce different memory layouts with a different single object with a protected .bss and .data, and n - 1 unprotected ones.
* in the non-PIE main executable case, unless all shared objects can fit and are loaded below the main executable, the .data and .bss sections of the main executable will not be NX. The quantum security applies here as well.

Section 3.1.4 PHP Exploits:
"In each case the default SELinux targeted policy for the Apache HTTP Server would restrict what a successful exploit is able to do."
To what extent a successful exploit is restricted I imagine is intentionally left vague, as this certainly doesn't include preventing kernel exploits in general (as last year should have sufficiently proven).

Section 3.1.5 Servers and services exploits:
"These are the most serious threats."
I'd question this evaluation. Is everyone reporting to RedHat when their server is compromised? Is CVE-2008-1891 ("An exploit for a Ruby WEBrick flaw. A remote attacker could read arbitrary CGI files, but only if the files were being served from a NTFS or FAT file system.") a more serious threat than a PHP exploit followed up by a local kernel exploit?

Section 2.2 Critical Flaws:
"Vulnerabilities rated “critical severity” are the ones that can pose the most risk to an organization. By definition, a critical vulnerability is one that could potentially be exploited remotely and automatically by
a worm. However we also stretch the definition to include those flaws that affect web browsers or plug-ins where a user only needs to visit a malicious (or compromised) website in order to be exploited."
What's the significance of a single vulnerability that can be exploited remotely and automatically? A vulnerability is a stepping stone, not a destination. Using two exploits for two "important" vulnerabilities gets you to the same place as a single "critical" vulnerability. Table 4 shows that no kernel vulnerabilities were classified as critical. Anyone with experience with metasploit or the commercial tools from Immunity or CORE knows that multiple exploits can be trivially chained together automatically.

On a side note, a flawed but interesting investigation would be to pool the public sources for exploits that offer download counts and compare the download counts against the severity classification for the vulnerability it exploited.

One final thing to think about (from Mark J. Cox's blog):
http://www.awe.com/mark/blog/20100216.html
Was 2009 really "the year of kernel NULL pointer dereference flaw"? Would the same attention have been paid if exploits hadn't been released publicly? Did NULL pointer dereference vulnerabilities suddenly appear in the kernel in 2009, or did one individual and two guys from Google just decide to publish some information?

-Brad