| |
mark :: blog
Over the Christmas holiday I joined Second Life. I wasn't expecting to find it interesting as I don't use chat systems at all outside of work (all of the Red Hat Security Response Team work in different locations around the world so irc provides a good crisis room). But I was quickly hooked and started creating shirts, figuring out ways that Sonik could play a live gig, playing Myst-like adventure puzzles, and virtually dancing to great music.
Having discovered libsecondlife and having a few spare hours this weekend I installed mono development tools and knocked up a quick libsecondlife to Jabber interface. All my home automation communicates using XMPP, so by giving my second life avatar the ability to communicate to my Jabber server he can do all sorts of things. My avatar gets notification when the phone rings and can tell me the callers number (and do a cute little animation to pick up a phone), the avatar can turn on and off the house lights, or find the temperatures of rooms.
I've not figured out a use for this yet. I've a few ideas though which will need to wait until there's more free time.
Late last year a reporter contacted me who was interested in the
various security features and innovations in Red Hat Enterprise Linux
and Fedora. She particularly wanted to know the dates when each first
made it into a shipping product. In the end the article was published
in a German magazine and was not publically available. It's a shame
to waste the work as I don't think this has ever all been collected
together into one place before, so here is the table. It's possible
I've missed one or two of the features, and I've not broken down the
big things like SELinux where we could talk about the number of
default policies in each release or the number of binaries compiled
PIE, but drop me a mail if you see any issues.
New: Updated version from 7th January 2008
Red Hat Network got a minor update last night which added a couple of
new security features we've been working on:
These features are now live and also enhance our public interface to
the Red Hat Network (no login required).
Earlier this month, Steve Christey posted a draft report of the Vulnerability
Type Distributions in CVE. The report notices, amongst other things, some differences between open and closed source vendors. I thought it would be more interesting to focus just on one of our released distributions to see if it made a difference to the trends. Steve kindly provided some reports based on a list of CVE names I gave him, and this led to the analysis and these two graphs.
First, the Vulnerability Type Distribution graph. This is not really a big surprise, the most common vulnerabilities we fix are buffer overflows.
Technologies such as ExecShield (PIE, support for NX, FORTIFY_SOURCE
and so on) were designed specifically to reduce the risk of being able
to exploit this flaw type. Secondly, compared to the industry as a whole we fix far less web application flaws
such as cross-site scripting or SQL injection. This result is to be expected as most of these are in PHP web applications we don't ship in our distributions.
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, NISCC
Here 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.
Earlier this month Red Hat started publishing Open Vulnerability and Assessment Language (OVAL) definitions for Red Hat Enterprise Linux security issues and today we obtained official compatibility. But what are these definitions, how do you use them, and why are they important?
One of the goals of Red Hat Enterprise Linux is to maintain backward compatibility of the packages we ship where possible. This goal means making sure that when we release security updates to fix vulnerabilities that we include just the security fixes in isolation, a process known as backporting. Backporting security fixes has the advantage that it makes installing updates safer and easier for
customers, but has the disadvantage that it can cause confusion to people unfamiliar with the process who try to use the version number of a particular piece of software to determine it's patch status.
In 2002, Red Hat started publishing Common Vulnerability and Exposures (CVE) vulnerability identifiers on every security advisory in order to make it easy to see what we fixed and how. Customers need only know the CVE identifiers for the vulnerabilities they are interested in and can then find out quickly and easily which of our updates addressed that particular vulnerability. CVE is now used on security advisories from nearly all the major vendors.
Red Hat has a single common mechanism for keeping systems up to date with security errata, the Red Hat Network. The Red Hat Network looks at a customers machines to determine which updates are required and gives anything from a customised
notification that an update is available through to automated installation. Third party patch auditing tools don't have such an easy time figuring out what up
dates are required: they have to maintain their own list of Red Hat package versions against vulnerability names. As this list is different for each operating system version from each potential vendors, these tools are prone to many errors and lag behind our updates.
We've also found customers that query the Red Hat Network errata pages directly to gather information about our security advisories and put them into a format
they can integrate with their own processes. Many customers take feeds of vulnerability data, usually in some XML format, from third party security vulnerability companies.
MITRE recognised both of these issues a number of years ago when they founded the Open Vulnerability and Assessment Language project, OVAL in 2002. The aim of OVAL is to provide a language for defining how to test for vulnerabilities and system configuration errors in an open and cross-platform manner. Red Hat was a founding board member of the OVAL project as part of our overall commitment to security quality.
So Red Hat now publishes OVAL 5 definitions for our Red Hat Enterprise Linux 3 and 4 security advisories. Each security advisory gets a separate XML OVAL file
which defines the steps needed to test if an update is required for the target system. In an ideal world every Red Hat Enterprise Linux system would be consuming every update from Red Hat Network automatically, but for those that don't or
where systems have been disconnected for some time, these definitions can help determine the patch status. In addition, these definitions contain selected info
rmation from our advisories which can be combined with vulnerability feeds from third parties.
Red Hat OVAL patch definitions contain:
- A link to the original advisory
- CVE references for all the vulnerabilities fixed by the advisory
- References into our public bug tracking database
- The severity of the advisory
- A short description abstract taken from the advisory text
- For each Enterprise Linux version, a list of the packages and versions required to determine if the update is required
The actual OVAL definitions themselves are available from http://www.redhat.com/oval/ and are public within a couple of hours of an advisory being pushed to the Red Hat Network. OVAL definitions for all previous Red Hat Enterprise Linux 3 and 4 advisories are also available. At present we do not ship OVAL tools such
as a definition interpreter, but there are severalopen-source and commercial OVAL-compatible tools available.
For the future we encourage other vendors to publish definitive OVAL definitions for their products too, and we hope to work on compatibility testing with other operating system and tool vendors.
More information about the make-up of the OVAL patch definitions can be found at the MITRE OVAL site. An FAQ about our implementation and where to contact us with comments or questions is also available.
Nalin gave a great presentation in the last summit slot about single sign on. One of his slides read simply "Passwords Suck. More Passwords Suck More". I think this is a useful phrase that I am going to now subvert for a short rant:
American Airlines Experiences Suck
More American Airlines Experiences Suck More
First was the debacle which was a 7 hour delay getting to Nashville after a flight was cancelled. Now, at 9pm the day before my 6am flight from Nashville to London tommorrow they cancel my flight and are unable to get me to London in time for my Monday meeting. So I miss my meeting and total for the week I'll have had 18 hours of delays. Although perhaps I shouldn't blog this until I'm home as I'm still in Nashville and, nice that it is, don't want to spend another year here. So thats four out of my last six AA trips that have gone significantly wrong, and I only used AA this time because I wanted to upgrade and had miles left.
However, rant aside, this trip was all about the Red Hat Summit. I was pleasantly suprised by how smoothly it ran and how useful it was to have face-to-face meetings with some of the people I interact with daily by computer. There's a few cool things that the trip acted as a catalyst for, but you'll need to wait to find out ;) I tried to speak to many different attendees over breaks in the days, and consensus was positive with all the first-timers wishing to attend again in the future.
a few of my photos from the summit
After a busy day yesterday at the Summit we partied over at the Wildhorse Saloon. Popped out for an hour with a couple of colleagues to grab a few local geocaches, and saw some sights in Nashville we'd otherwise have missed. 
|
|
|
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:
popular tags:
[all],
apache,
apachecon,
apacheweek,
cve,
cvss,
fedora,
financial,
geocaching,
ha,
metrics,
microsoft,
nashville,
north carolina,
red hat summit,
redhat,
security,
trips
|
|
