mark :: blog :: fedora
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).
I've been generating some more useful Fedora stats over the last few days, but I'm going to save them until FudCon next week so I've something new to talk about. I've also been adding some bookmarks to my phone so I can grab a few webcam geocaches in Karlsuhe and Frankfurt. Meanwhile the rest of the security team has been busy pushing out a lot of older 'moderate' and 'low' rated serverities whilst there isn't many 'important' rated issues in the queue.
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.
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"
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).
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.
The last couple of months have been quite busy and any spare time I've been using to go Geocaching. Only up to 8 finds so far, but I'm picking locations that sound interesting and worth visiting. Scottish Geocaches have some pretty amazing scenery and they've taken me to all sorts of places I'd never think of visting. So it took until today to finally getting around to configuring the T41 laptop the way I wanted to. It's running Fedora Core 2 and I figured it was time to use a dual-head so I'm not stuck at 1024x768 forever when theres a perfectly good 22" CRT next to me. "system-config-xfree86" had it working immediately; with just a manual tweak needed to XF86Config so the second screen was at 1280x1024. To complete the setup I plugged the USB IBM Trackpoint keypad into the laptop and it configured itself, set itself up, and now moving any of the trackerpoint mice moves the pointer, typing on any keyboard just works. What I've been putting off for the last two months took less time than typing this entry, I love it when that happens. Meanwhile, trying to get a bluetooth USB dongle working so I can just simply send and receive SMS via Fedora Core 2 is one of those more impossible missions that just sucks up time.
Hi! I'm Mark Cox. This blog gives my
thoughts and opinions on my security
work, open source, fedora, home automation,
and other topics.
pics from my twitter:
red hat summit,