A year ago I published a table of Security Features in Red Hat Enterprise Linux and Fedora Core. Since then we've released two more Fedora versions, and a Red Hat Enterprise Linux, so it's time to update the table.
Between releases there are lots of changes made to improve security and I've not listed everything; just a high-level overview of the things I think are most interesting that help mitigate security risk. We could go into much more detail, breaking out the number of daemons covered by the SELinux default policy, the number of binaries compiled PIE, and so on.
| Fedora Core | Fedora | Red Hat Enterprise Linux | |||||||||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 3 | 4 | 5 | |
| 2003Nov | 2004May | 2004Nov | 2005Jun | 2006Mar | 2006Oct | 2007May | 2007Nov | 2003Oct | 2005Feb | 2007Mar | |
| Firewall by default | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
| Signed updates required by default | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
| NX emulation using segment limits by default | Y | Y | Y | Y | Y | Y | Y | Y | Y2 | Y | Y |
| Support for Position Independent Executables (PIE) | Y | Y | Y | Y | Y | Y | Y | Y | Y2 | Y | Y |
| Address Randomization (ASLR) for Stack/mmap by default3 | Y | Y | Y | Y | Y | Y | Y | Y | Y2 | Y | Y |
| ASLR for vDSO (if vDSO enabled)3 | no vDSO | Y | Y | Y | Y | Y | Y | Y | no vDSO | Y | Y |
| Restricted access to kernel memory by default | Y | Y | Y | Y | Y | Y | Y | Y | Y | ||
| NX for supported processors/kernels by default | Y1 | Y | Y | Y | Y | Y | Y | Y2 | Y | Y | |
| Support for SELinux | Y | Y | Y | Y | Y | Y | Y | Y | Y | ||
| SELinux enabled with targeted policy by default | Y | Y | Y | Y | Y | Y | Y | Y | |||
| glibc heap/memory checks by default | Y | Y | Y | Y | Y | Y | Y | Y | |||
| Support for FORTIFY_SOURCE, used on selected packages | Y | Y | Y | Y | Y | Y | Y | Y | |||
| All packages compiled using FORTIFY_SOURCE | Y | Y | Y | Y | Y | Y | |||||
| Support for ELF Data Hardening | Y | Y | Y | Y | Y | Y | Y | ||||
| All packages compiled with stack smashing protection | Y | Y | Y | Y | Y | ||||||
| SELinux Executable Memory Protection | Y | Y | Y | Y | |||||||
| glibc pointer encryption by default | Y | Y | Y | Y | |||||||
| FORTIFY_SOURCE extensions including C++ coverage | Y | ||||||||||
Our usual security audit for Fedora Core 6 is now available. For 20020101 to 20061023 there are a potential 1758 CVE named vulnerabilities that could have affected FC6 packages. 93% of those are fixed because FC6 includes an upstream version that includes a fix, 1% are still outstanding, and 6% are fixed with a backported patch. Most of those outstanding issues are for low or moderate severity flaws that are not fixed upstream.
The full details broken out by CVE name are available as at GOLD (fixed) or latest status (updated daily)
There's a new Apache HTTP Server security issue out today, an off-by-one bug that affects the Rewrite module, mod_rewrite. We've not had many serious Apache bugs in some time, in fact the last one of note was four years ago, the Chunked Encoding Vulnerability.
This issue is technically interesting as the off-by-one only lets you write one pointer to the space immediately after a stack buffer. So the ability to exploit this issue is totally dependent on the stack layout for a particular compiled version of mod_rewrite. If the compiler used has added padding to the stack immediately after the buffer being overwritten, this issue can not be exploited, and Apache httpd will continue operating normally. Many older (up to a year or so ago) versions of gcc pad stack buffers on most architectures.
The Red Hat Security Response Team analysed Red Hat Enterprise Linux 3 and Red Hat Enterprise Linux 4 binaries for all architectures as shipped by Red Hat and determined that these versions cannot be exploited. We therefore do not plan on providing updates for this issue.
In contrast, our Fedora Core 4 and 5 builds are vulnerable as the compiler version used adds no stack padding. For these builds, the pointer being overwritten overwrites a saved register and, unfortunately, one that has possible security consequences. It's still quite unlikely we'll see a worm appear for this issue that affects Fedora though: for one thing, the vulnerability can only be exploited when mod_rewrite is enabled and a specific style of RewriteRule is used. So it's likely to be different on every vulnerable site (unless someone has some third party product that relies on some vulnerable rewrite rules). Even then, you still need to be able to defeat the Fedora Core randomization to be able to reliably do anything interesting with this flaw.
So, as you can probably tell, I spent a few days this week analysing assembler dumps of our Apache binaries on some architectures. It was more fun than expected; mostly because I used to code full-time in assembler, although that was over 15 years ago.
In the past I've posted timelines of when we found out about issues and dealt with them in Apache; so for those who are interested:
20060721-23:29 Mark Dowd forwards details of issue to security@apache.org 20060722-07:42 Initial response from Apache security team 20060722-08:14 Investigation, testing, and patches created 20060724-19:04 Negotiated release date with reporter 20060725-10:00 Notified NISCC and CERT to give vendors heads up 20060727-17:00 Fixes committed publically 20060727-23:30 Updates released to Apache site 20060828 Public announcement from Apache, McAfee, CERT, NISCCHere is the patch against 2.0, the patch against 1.3 or 2.2 is almost identical.
On Friday 14th July an exploit was widely posted for a vulnerability in the Linux 2.6 kernel, CVE-2006-3626, which attempts to allow a local user to gain root privileges. The exploit relies on the kernel supporting the a.out binary format.
This vulnerability does not affect Red Hat Enterprise Linux 2.1 or 3 as they are based on 2.4 kernels.
Red Hat Enterprise Linux 4, Fedora Core 4, and Fedora Core 5 do not support the a.out binary format, causing the exploit to fail. We are not currently aware of any way to exploit this vulnerability if a.out binary format is not enabled. In addition, a default installation of these OS enables SELinux in enforcing mode. SELinux also completely blocks attempts to exploit this issue.
For more technical details of this issue please see bz#198973
The Red Hat Security response team have therefore rated this as having moderate security severity for Enterprise Linux 4. No asynchronous kernel update for this issue is currently planned; the fix for the flaw will be included in some later scheduled update.
Just finished the security audit for FC5 - For 20030101-20060320 there are a potential 1361 CVE named vulnerabilities that could have affected FC5 packages. 90% of those are fixed because FC5 includes an upstream version that includes a fix, 1% are still outstanding, and 9% are fixed with a backported patch. Many of the outstanding and backported entries are for issues still not dealt with upstream. For comparison FC4 had 88% by version, 1% outstanding, 11% backported.
On Monday a vulnerability was announced affecting the Linux kernel that could allow a remote attacker who can send a carefully crafted IP packet to cause a denial of service (machine crash). This issue was discovered by Dave Jones and allocated CVE CVE-2006-0454. As Dave notes it's so far proved difficult to reliably trigger (my attempts so far succeed in logging dst badness messages and messing up future ICMP packet receipts, but haven't triggered a crash).
This vulnerability was introduced into the Linux kernel in version 2.6.12 and therefore does not affect users of Red Hat Enterprise Linux 2.1, 3, or 4. An update for Fedora Core 4 was released yesterday.
At FudCon I talked about the lack of any recent Linux worms, the last being a couple of years ago - but as of this weekend I've a new Linux worm to talk about, Lupii. This Linux worm was detected around the 5th November 2005 and is designed to exploit a flaw CVE-2005-1921 in the PHP PEAR XML-RPC Server package through a number of third party PHP scripts.
Red Hat released updates to PHP to correct this vulnerability for Red Hat Enterprise Linux 3 and 4 in July 2005. Red Hat Enterprise Linux 2.1 was not affected by this vulnerability. Fedora Core 4 and Fedora Core 3 also got updates in July.
Our analysis showed that the default SELinux targeted policy on Enterprise Linux 4 would have blocked the specific instances of this worm seen so far, but is not sufficient to block a worm written differently from exploiting this vulnerability if left unpatched. Time to make sure all your servers are up2date!
On Friday we read about the Firefox security issue, CAN-2005-2871. This issue looked like it could well be a 'critical' issue potentially allowing a malicious web page to control a heap buffer overflow. We know that various technologies in Red Hat Enterprise Linux and Fedora Core are likely to reduce the chances of this being actually exploitable by an attacker -- checks foil the most usual way of exploiting heap overflows by messing with malloc control structures, and on x86 at least heap randomization makes an exploit harder. But this issue was already public and so we didn't have the luxury of time to be able to test the mitigation. So we initiated our emergency response process to get the packages through development and QA and got Firefox and Mozilla packages out via Red Hat Network within 20 hours of this issue being public (due to the awesome work from engineering folks, QA folks, and the security response team who worked late into Friday night to get this done).
Fedora Security
Just finished the security audit for FC4 candidate - For 20030101-20050605 there are a potential 861 CVE named vulnerabilities that could have affected FC4 packages. 759 (88%) of those are fixed because FC4 includes an upstream version that includes a fix, 8 (1%) are still outstanding, and 94 (11%) are fixed with a backported patch. I'll post all the details to fedora-devel-list later in the week. I'm also giving a keynote about Fedora and security response at FudCon later this month.
OpenSSL Security
A CSO remarked to me a couple of weeks ago that their perception was that OpenSSL had a lot of serious security issues over the years. In fact it's really only had a couple of serious issues, and in total only 15 issues in the last 4 years. So in the style of the Apache vulnerability database I did one for OpenSSL. This is now publically available and we'll keep it up to date. The page is built from a XML database of the issues.
Last week we published fixes for flaws in libPNG found by a UK researcher. Since these flaws didn't get much press attention I wanted to take this opportunity to fill in a few of the details. If you don't want the details just goto https://rhn.redhat.com/cve/CAN-2004-0597.html and update your systems right now.
Chris Evans discovered a stack buffer overflow in the libPNG library. This means that an attacker could create a malicious PNG image file to take advantage of the flaw. If you were to view that malicious image on your system then it could execute arbitrary code as you. Since most applications that display PNG files are linked to libPNG or contain libPNG code, that increases the risk of this flaw.
Whilst researching affected applications we found that most browsers were affected - so an attacker would simply have to put a malicious image onto a web site that you visit. You'd still need to be forced to visit that web site though. Or maybe the attacker can act as a man-in-the-middle and inject the malicious image file (as was reported recently at DefCon where wireless surfers had all their images replaced). More worrying are perhaps email applications that might load images by default, which could allow propegation of a worm. This isn't an issue that only affects Linux; just sending malicious images in attachments to someone using AppleMail on MAC OSX is enough to trigger the flaw.
Although i've not yet seen an exploit containing shellcode for this issue we believe it is triviallly exploitable. This is a "Critical" update.
Red Hat Enterprise Linux users need to update their libpng and Mozilla (which contained it's own copy of libpng) packages. Updating libpng is sufficient to protect all the applications that use that library to decode images (although you'll need to restart any applications you've already got running to pick up the change, it's probably easiest just to restart your system if you're unsure).
Fedora Core users should be protected against possible exploits of this issue by exec-shield, but should still upgrade (as a malicious PNG file would still crash an application).
https://rhn.redhat.com/cve/CAN-2004-0597.html
Because libpng is under a BSD-style license, anyone is basically free to use or include libpng even in closed-source products. So expect to see a whole raft of advisories over the coming weeks as other vendors come to discover that they're vulnerable to this issue.
