Mark J Cox

mark :: blog :: redhat

09 Oct 2012: OpenShift, perl, YouTube API

My wife is part of a competition to be the next face representing her college; with the final number of positive 'likes' on YouTube videos determining the winners. I thought it would be neat to create a scoreboard to track her progress, but also to learn how to use OpenShift all in one. It took me longer to write this blog than to write the code and deploy it live!

After creating an account on Red Hat OpenShift I created a new app based on perl and added a cron container so we can run our script every few minutes (to stop overloading the YouTube API if the site gets popular):

rhc-create-app -a fomc -t perl-5.10
rhc-ctl-app -a fomc -e add-cron-1.4
cd fomc

That was all the configuration needed, the 'fomc' directory is populated with everything you need. OpenShift when you deploy your app, figures out your perl dependencies and grabs and builds them for you, so no messing around needing root or even logging into the host.

By default the file perl/index.pl will get served, but since we're going to cache the output from the script let's make it a html file index. To do this simply add to the existing perl/.htaccess file:

DirectoryIndex index.html

I wrote this quick perl program to query the YouTube API and do a simplistic HTML page of the number of likes for each of the videos in the playlist, and placed it in the main directory as youtube.pl. Now to get it created every ten minutes we use the cron container by creating a file .openshift/cron/minutely/perljob with the contents:

#!/bin/bash
MIN=`date +%M`
if [ $((${MIN#0} % 10)) == 0 ]; then
    perl ${OPENSHIFT_REPO_DIR}/youtube.pl > ${OPENSHIFT_REPO_DIR}/index.html
    mv -f ${OPENSHIFT_REPO_DIR}/index.html ${OPENSHIFT_REPO_DIR}/perl/index.html
fi

The cron job is run every minute, but the "modulus 10" ensures we only run the perl script once every 10 minutes. We use an intermediate file so that anyone visiting the site during the time it takes to create the file doesn't get a blank page. Finally we want to make sure that we don't have to wait ten minutes for the file to be created when we push the app, and give people the ability to see the source, so we create .openshift/action_hooks/post_deploy with the contents:

cp ${OPENSHIFT_REPO_DIR}/youtube.pl ${OPENSHIFT_REPO_DIR}/perl/youtubepl.txt
perl ${OPENSHIFT_REPO_DIR}/youtube.pl > ${OPENSHIFT_REPO_DIR}/perl/index.html

And that's it. Just run

git add .
git commit -a -m 'first app'
git push

And the app is up and running; here it is: http://fomc-esoom.rhcloud.com/. If this blog was useful (blatent plug!) please click on "Tracy Cox", make sure you're logged in, and click "like" ;)

28 Sep 2012: Fedora or Android?

For a two day trip I decided to test using my Android tablet instead of also taking a laptop, and it worked out okay for the most part.

I was booked to go to Red Hat HQ in Raleigh, NC at the start of August for a two-day business trip, well more accurately two-days in the office and another two-days of travelling. I'd usually take my trusty ThinkPad x201 on the trip with me, it's small and light, but it's battery life isn't so great anymore. Earlier this year I'd bought an Android tablet, an ASUS Transformer Prime which with a long battery life would be perfect for movies, but could it replace my ThinkPad completely and save me travelling with two devices? I worked through my requirements and it seemed plausible in theory, so here is how it stacked up in practice:

Connectivity. In the UK you can only buy the Prime with the keyboard dock, the keyboard dock is great. The in-built wifi was okay for the airport, hotel, and office. I carry a USB network adapter anyway just in case the hotel has a physical connection. The wifi signal on the Prime is terrible compared to other things (like a phone) though, so be prepared to walk around a bit to the best signal. Partial Win.
In flight entertainment. I wanted something to watch movies (as US Airways transatlantic don't yet have seat-back video, really!). The large internal memory meant I could store a few films in decent quality to watch and battery life wasn't a problem. I'd used the tablet continously (without wifi) with the keyboard connected for 6 hours and wasn't even down to 50% battery. Although hardware decoding of videos was a bit hit-and-miss, and after trying a dozen apps only "BS Player" seemed to do a reasonable job. A couple of the movies I'd brought had low audio and I couldn't figure out a way to boost it enough to hear over the noise of the plane, even with decent in-ear noise blocking headphones. Having the keyboard dock helped considerably as with the tablet on the tray-table I could set a decent angle to watch a movie. Win.
Reading material. I had a few papers and magazines to read which I'd preloaded onto the tablet in PDF format. The Adobe PDF viewer is acceptable, but it seems a little sluggish for something running on a quad-core processor, and the screen resolution isn't really good enough for magazines. The new Transformer Infinity would help here. Partial Win.
Keeping in touch with home. The standard Android GMail app and Facebook app are okay, and I was able to use GMail talk to have video chats with my family from both the hotel and office. Win.
Working. With just a couple days away I figured all that was needed was the ability to read and send email and browse intranet internal web pages. The standard VPN client on the Prime worked perfectly, and along with the Firefox beta app gave me perfect access to internal sites. For email I prefer command-line text-window clients anyway, so I just needed to be able to connect to a work machine. "Connectbot" on Android works well enough for ssh, and there are a few forked versions you can get that work with the Prime keyboard. The AndChat app works for irc. Win.
Presentations. I was giving a presentation at a meeting, but fortunately they had a laptop set up with the projector and I didn't need to worry about taking a HDMI lead and hoping it was a recent projector. Unexpectedly I needed to edit an existing OpenOffice presentation to remove a couple of slides and then convert to PDF to send to another company. I had to ask a colleague to do it for me. There are apps that can view OpenOffice files, but no native OpenOffice suite for android. I'd probably make sure I had access to a VNC server in the future and use a VNC client for anything like this. Fail.
Privacy. My thinkpad has full-disk encryption but I didn't bother for Android as I wasn't going to be storing anything sensitive on the machine. My thinkpad has a 3M privacy filter, which is great for airplanes and airports to stop people either side and behind you looking at your screen. The same filters do exist for Android, but are not as straightforward (it of couse only works in one orientation and attaches like a screen protector, so isn't the easiest thing to continuously take on and off, and forces you to use your screen in portrait mode for everything). Fail.
Printing a boarding card. When it was time to return home I was able to use Firefox to check in online, and printing my boarding passes gave me a PDF file. I didn't have any printer apps set up, but it was easy enough to email a PDF to a colleague to print for me. Partial Win.

So in summary I think I got away with it; having just the tablet didn't stop me doing anything that had to be done on the trip and I'll definately do the same thing again in the future for very short trips. For anything more than a couple of days or where connectivity might be an issue I'd miss having a full-featured OS.

20 Sep 2012: Red Hat Security Blog

We now have an official Red Hat Security Blog, and you'll find all my future reports and discussions about security metrics there. In the meantime here are a few already published articles:

18 May 2012: Red Hat and CVRF compatibility

The Common Vulnerability Reporting Framework (CVRF) is a way to share information about security updates in an XML machine-readable format. CVRF 1.1 got released this week and over at Red Hat we've started publishing our security advisories in CVRF format.

Find out more from our FAQ and formatting guide.

07 Jun 2011: Hiring three Security Response Team members

Red Hat has an unrivaled security record when it comes to addressing security flaws in our products. We reduce the risk to customers using our products by constantly monitoring for vulnerabilities and threats, triaging their impact to our customers, and addressing those that matter the most quickly. The Red Hat Security Response Team are responsible for dealing with security vulnerabilities in Red Hat products and services and has a team spanning nine countries.

We've currently got three positions in the team currently open. One is focused on Java (JBoss) technologies, another on our new Cloud services, and a final one on our Enterprise Linux product.

Would you like to be part of our dynamic team, and help protect Red Hat's customers and the open source community as a whole from security vulnerabilities?

Each of the positions are challenging and demanding; every day you'll be investigating different issues affecting different products and codebases, having to manage your time on the issues with the greatest impact.

Some of the tasks of the job include (but are not limited to):

Rapidly responding to new security issues. You'll need to be able to think fast, analyze complex problems, use your judgement to assess vulnerability severities and risks, and switch your priorities to ensure that serious issues get immediate attention.
Investigating how security flaws specifically impact your products. Research how the flaws can be exploited by attackers; by code analysis, testing exploits, or writing proof of concept tests.
Communicating about flaws with our software developers, managers, quality engineers, upstream project developers, as well as our peers in the security response teams of other vendors.
Developing advice and technical documentation for security advisories.
Responsibility for tracking vulnerabilities through the entire update release lifecycle and ensuring that customers get the right fixes with the right advice at the right time.

We can be flexible with working location. So if this interests you, email me a CV/resume (to mjc at redhat.com) as not all the jobs are on our careers page yet.

18 May 2011: Red Hat Security Advisories in CVRF

Earlier this year, Red Hat joined the Common Vulnerability Reporting Framework (CVRF) working group run by ICASI. The goal of CVRF is to provide a way to share information about security updates in a machine-readable format. Red Hat already produce a version of our security advisories in machine readable format, as OVAL definitions, but these are really designed for automated test tools to determine the need to apply an update. CVRF looked like it would be more useful for providing customers with a machine readable view of our advisories.

After many iterations at getting right schema, CVRF 1.0 was released this week.

Red Hat is not yet providing an official archive with CVRF representations of our advisories, but we have created tools internally to support it and allow us to automatically create CVRF documents based on our advisory database. We've provided a sample set of advisories in CVRF format for download.

Let's take one of these samples, a recent Red Hat Enterprise Linux security advisory and examine how it looks when automatically converted to a CVRF document. Our advisories often fix more than one vulnerability at a time and for more than one version of a product, but for this example we'll keep it simple. RHSA-2010:0888 is an Enterprise Linux 6 update to fix the vulnerability CVE-2010-3864 affecting OpenSSL.

The CVRF for this advisory starts like this:

<?xml version="1.0" encoding="utf-8"?>
<cvrfdoc xmlns="http://www.icasi.org/CVRF/schema/cvrf/1.0"
            xmlns:cvrf="http://www.icasi.org/CVRF/schema/cvrf/1.0" 
            xmlns:cvrf-vuln="http://www.icasi.org/CVRF/schema/vuln/1.0">
  <DocumentTitle xml:lang="en">Red Hat Security Advisory: openssl security update</DocumentTitle>
  <DocumentDistribution xml:lang="en">Copyright © 2011 Red Hat, Inc. All rights reserved.</DocumentDistribution>
  <LegalDisclaimer xml:lang="en">Please see http://www.redhat.com/legal/legal_statement.html</LegalDisclaimer>
  <DocumentType>Security Advisory</DocumentType>
  <DocumentPublisher>Vendor</DocumentPublisher>

The first section, above, is pretty straightforward: we're publishing this CVRF as the authoritative vendor for Red Hat Enterprise Linux, and it's a Security Advisory. All our text fields have a language identifier ("en") as future CVRF advisories could contain localized parts.

  <DocumentTracking>
    <DocumentID>RHSA-2010:0888</DocumentID>
    <DocumentStatus>Final</DocumentStatus>
    <DocumentVersion>1</DocumentVersion>
    <DocumentRevisionHistory>
       <DocumentRevision>
         <RevisionNumber>1.0</RevisionNumber>
         <RevisionDate>2010-11-16T16:08:00+00:00</RevisionDate>
         <RevisionDescription>Current version</RevisionDescription>
       </DocumentRevision>
    </DocumentRevisionHistory>
    <DocumentInitialReleaseDate>2010-11-16T16:08:00+00:00</DocumentInitialReleaseDate>
    <DocumentCurrentReleaseDate>2010-11-16T16:08:00+00:00</DocumentCurrentReleaseDate>

The next section is about document revision history and is a mandatory requirement of CVRF documents. This is tricky for Red Hat to automatically generate from our existing advisories: we use an internal "Push Count" as our revision number, and occasional problems during pushing an advisory live mean that our first real public version is not "1". In addition, when we do release an update to an advisory, we update the description text with details of the changes made, so we don't have this text stored in a separate field. So for now our CVRF "RevisionDescription" sections will not have useful descriptions, but the initial and current release dates will be accurate.

    <DocumentGenerator>
      <Generator>make-cvrf-from-et.pl</Generator>
      <GenerationDate>2010-12-15T10:15:06+00:00</GenerationDate>
      <CVRFVersion>1.00</CVRFVersion>
    </DocumentGenerator>
  </DocumentTracking>

During the design of CVRF we championed this separate "DocumentGenerator" section, which mirrors a similar section in OVAL. This can help us track down any errors in published documents and allows us to regenerate a document if our automated script is altered or fixed without causing a new document revision.

  <DocumentSummary>
    <Summary Title="Topic" Audience="General" xml:lang="en">
Updated openssl packages that fix one security issue are now available for
Red Hat Enterprise Linux 6.

The Red Hat Security Response Team has rated this update as having
important security impact. A Common Vulnerability Scoring System (CVSS)
base score, which gives a detailed severity rating, is available from the
CVE link in the References section.
</Summary>
  </DocumentSummary>
  <DocumentDetails>
    <Details Title="Details" Audience="General" xml:lang="en">
OpenSSL is a toolkit that implements the Secure Sockets Layer (SSL v2/v3)
and Transport Layer Security (TLS v1) protocols, as well as a
full-strength, general purpose cryptography library.

A race condition flaw has been found in the OpenSSL TLS server extension
parsing code, which could affect some multithreaded OpenSSL applications.
Under certain specific conditions, it may be possible for a remote attacker
to trigger this race condition and cause such an application to crash, or
possibly execute arbitrary code with the permissions of the application.
(CVE-2010-3864)

Note that this issue does not affect the Apache HTTP Server. Refer to Red
Hat Bugzilla bug 649304 for more technical details on how to determine if
your application is affected.

Red Hat would like to thank Rob Hulswit for reporting this issue.

All OpenSSL users should upgrade to these updated packages, which contain a
backported patch to resolve this issue. For the update to take effect, all
services linked to the OpenSSL library must be restarted, or the system
rebooted.
</Details>
  </DocumentDetails>

The document summary and details sections above are directly copied from the equivalent sections in our text advisory. This does mean however that the details of the vulnerabilities will get repeated, as later each vulnerability gets its own section with description, CVE name, and acknowledgments.

  <References>
    <RelatedDocument>
       <DocumentURL>https://rhn.redhat.com/errata/RHSA-2010-0888.html</DocumentURL>
       <DocumentDescription>https://rhn.redhat.com/errata/RHSA-2010-0888.html</DocumentDescription>
    </RelatedDocument>
    <RelatedDocument>
       <DocumentURL>http://www.redhat.com/security/updates/classification/#important</DocumentURL>
       <DocumentDescription>http://www.redhat.com/security/updates/classification/#important</DocumentDescription>
    </RelatedDocument>
  </References>

References can appear both at the top level of a CVRF document as well as for each vulnerability. The most important top level reference is the self-reference which links to the full representation of the advisory. In early CVRF drafts this had a separate attribute so that it was possible to extract the self reference URL; we think that would have been useful to still be there.

  <AggregateSeverity>Important</AggregateSeverity>
  <IssuingAuthority VendorID="Red Hat, Inc">secalert@redhat.com</IssuingAuthority>

The final top level directives give our severity rating and issuing authority. The severity is a free-text field and it's up to each vendor to use their own scheme for this. In the earlier references section we already gave a URL that described the severity levels being used; for a future CVRF version we should have that URL referenced as part of the AggregateSeverity tag.

  <cvrf-vuln:Vulnerability>
    <cvrf-vuln:VulnerabilityID><cvrf-vuln:Value SystemName="CVE">CVE-2010-3864</cvrf-vuln:Value></cvrf-vuln:VulnerabilityID>
    <cvrf-vuln:VulnerabilityDetails xml:lang="en">A race condition flaw
    has been found in the OpenSSL TLS server extension parsing code, which could
    affect some multithreaded OpenSSL applications. Under certain specific
    conditions, it may be possible for a remote attacker to trigger this race
    condition and cause such an application to crash, or possibly execute
    arbitrary code with the permissions of the
    application. </cvrf-vuln:VulnerabilityDetails>

We produce one vulnerability section for each CVE fixed, and the vulnerability details are abstracted from our full text description.

    <cvrf-vuln:VendorRemediationStatus>Completed</cvrf-vuln:VendorRemediationStatus>
    <cvrf-vuln:CVE>CVE-2010-3864</cvrf-vuln:CVE>
    <cvrf-vuln:Threat><cvrf-vuln:Impact>Important</cvrf-vuln:Impact></cvrf-vuln:Threat>
    <cvrf-vuln:ProductFamily>Red Hat Enterprise Linux</cvrf-vuln:ProductFamily>
    <cvrf-vuln:Acknowledgment>Red Hat would like to thank Rob Hulswit for reporting this issue.</cvrf-vuln:Acknowledgment>
    <cvrf-vuln:CVSS>
      <cvrf-vuln:CVSSBaseScore>7.6</cvrf-vuln:CVSSBaseScore>
      <cvrf-vuln:CVSSScoringVector>AV:N/AC:H/Au:N/C:C/I:C/A:C</cvrf-vuln:CVSSScoringVector>
    </cvrf-vuln:CVSS>

VendorRemediationStatus will always be "Completed" for all our advisories as they are always released at the same time as a fix. Also included is a per-vulnerability impact rating and CVSS base score. These are currently not included in our HTML advisories, but are available from our CVE database and Bugzilla entries; so it's handy to be able to have them all in the same document for the first time.

    <cvrf-vuln:Remediation>
      <cvrf-vuln:VendorFix xml:lang="en">
Before applying this update, make sure all previously-released errata
relevant to your system have been applied.

This update is available via the Red Hat Network. Details on how to
use the Red Hat Network to apply this update are available at
http://kbase.redhat.com/faq/docs/DOC-11259
</cvrf-vuln:VendorFix>
    </cvrf-vuln:Remediation>
    <cvrf-vuln:AffectedPlatform Name="Red Hat Enterprise Linux">
      <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux Desktop Optional (v. 6)">
          <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-devel-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-perl-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-static-1.0.0-4.el6_0.1</cvrf-vuln:Version>
      </cvrf-vuln:AffectedRelease>
      <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux HPC Node Optional (v. 6)">
          <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-devel-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-perl-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-static-1.0.0-4.el6_0.1</cvrf-vuln:Version>
      </cvrf-vuln:AffectedRelease>
      <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux Workstation Optional (v. 6)">
          <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-perl-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-static-1.0.0-4.el6_0.1</cvrf-vuln:Version>
      </cvrf-vuln:AffectedRelease>
      <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux Workstation (v. 6)">
          <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-devel-1.0.0-4.el6_0.1</cvrf-vuln:Version>
      </cvrf-vuln:AffectedRelease>
      <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux HPC Node (v. 6)">
          <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version>
      </cvrf-vuln:AffectedRelease>
      <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux Server Optional (v. 6)">
          <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-perl-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-static-1.0.0-4.el6_0.1</cvrf-vuln:Version>
      </cvrf-vuln:AffectedRelease>
      <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux Desktop (v. 6)">
          <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version>
      </cvrf-vuln:AffectedRelease>
      <cvrf-vuln:AffectedRelease Name="Red Hat Enterprise Linux Server (v. 6)">
          <cvrf-vuln:Version Type="Fixed">openssl-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-debuginfo-1.0.0-4.el6_0.1</cvrf-vuln:Version>
          <cvrf-vuln:Version Type="Fixed">openssl-devel-1.0.0-4.el6_0.1</cvrf-vuln:Version>
      </cvrf-vuln:AffectedRelease>
    </cvrf-vuln:AffectedPlatform>

The remediation section mirrors our advisories by giving a list of packages and the versions that first contained the fix for the issue. We have multiple variants of Red Hat Enterprise Linux 6, and some vulnerabilities will affect packages only shipped in some subset of variants, so the duplication is required.

    <cvrf-vuln:References>
      <cvrf-vuln:RelatedDocument>
        <cvrf-vuln:DocumentURL>https://www.redhat.com/security/data/cve/CVE-2010-3864.html</cvrf-vuln:DocumentURL>
        <cvrf-vuln:DocumentDescription>CVE-2010-3864</cvrf-vuln:DocumentDescription>
      </cvrf-vuln:RelatedDocument>
      <cvrf-vuln:RelatedDocument>
        <cvrf-vuln:DocumentURL>https://bugzilla.redhat.com/show_bug.cgi?id=649304</cvrf-vuln:DocumentURL>
        <cvrf-vuln:DocumentDescription>bz#649304: CVE-2010-3864 OpenSSL TLS extension parsing race condition</cvrf-vuln:DocumentDescription>
      </cvrf-vuln:RelatedDocument>
    </cvrf-vuln:References>
  </cvrf-vuln:Vulnerability>
</cvrfdoc>

Finally, the per-vulnerability reference section links to our CVE database for each CVE, and the Red Hat bug database for more technical details of the vulnerability and how it was addressed.

Our example advisory only had one vulnerability, but the whole vulnerability section is repeated where multiple are addressed.

Overall we've been really pleased with the way CVRF has turned out for it's first release, and we think it will be a useful way for vendors such as us to provide machine-readable advisories to customers as well as to tool vendors, filling a gap between our OVAL XML and our text and HTML advisories. We'll be trialling CVRF advisories later this year, drop an email to secalert@redhat.com if you have comments on our CVRF samples.

11 Nov 2010: Why Red Hat Enterprise Linux 6 has a new package signing key

Starting with Red Hat Enterprise Linux 6 we have switched to using SHA-256 signatures on all RPM packages and to a 4096-bit RSA signing key.

We've done this because it is current best practice to migrate away from MD5 and SHA-1 hashes due to various flaws found in them. Those flaws don't yet directly pose a threat to package signing however, and therefore our existing shipped products which used these older hashes will continue to use their existing keys until they reach their end of life.

A similar switch to stronger signing was already made in Fedora 11. This switch involved some changes to the RPM application.

So what this means is that we used new signing keys for both the beta and final release packages for Red Hat Enterprise Linux 6. Those keys were created and are protected by a hardware security module, as we've done with previous keys.

Details and fingerprint of the new key, #fd431d51.

Also in the Red Hat Enterprise Linux 6 distribution we've started to simplify the layout of the key files in the /etc/pki/rpm-gpg/ directory:

RPM-GPG-KEY-redhat-beta : Both the old and new beta keys
RPM-GPG-KEY-redhat-release : Both the new signing key and the auxiliary key
RPM-GPG-KEY-redhat-legacy-release : The signing key used for EL5
RPM-GPG-KEY-redhat-legacy-former : The signing key used for products before EL5
RPM-GPG-KEY-redhat-legacy-rhx : The signing key used for RHX

The auxiliary key mentioned above is for emergency use. We created it some time ago on a new standalone machine, took a hardcopy printout of the private key and passphrase, stored them separately and securely, and destroyed the software copies. We've planned for many eventualities, but in the unlikely event we lose the ability to sign with the hardware key we could retrieve the printout, type in the key, and continue to sign updates.

07 Oct 2009: CVE-2009-2408 (NULL in certificate) timeline

There have been quite a few stories over the last couple of weeks about the NULL character certificate flaw, such as this one from The Register.

The stories center around how open source software such as Firefox was able to produce updates to correct this issue just a few days after the Blackhat conference, while Microsoft still hasn't fixed it and are "investigating a possible vulnerability in Windows presented during Black Hat".

But the actual timeline is missing from these stories.

The NULL character certificate flaw (CVE-2009-2408) was actually disclosed by two researchers working independantly who both happened to present the work at the same conference, Blackhat, in July this year. Dan Kaminsky mentioned it as part of a series of PKI flaws he disclosed. Marlinspike had found the same flaw, but was able to demonstrate it in practice by managing to get a trusted Certificate Authority to sign such a malicious certificate.

The flaw was no Blackhat surprise; Dan Kaminsky actually found this issue many months ago and responsibly reported the issues to vendors including Red Hat, Microsoft, and Mozilla. We found out about this issue on 25th February 2009 and worked with Dan and some of the upstream projects on these issues in advance, so we had plenty of time to prepare updates and this is why we were able to have them ready to release just after the disclosure.

03 Mar 2009: Source of Vulnerabilities

From time to time I publish metrics on vulnerabilities that affect Red Hat Enterprise Linux. One of the more interesting metrics looks at how far in advance we know about the vulnerabilities we fix, and from where we get that information. This post is abstracted from the upcoming "4 years of Enterprise Linux 4" risk report

For every fixed vulnerability across every package and every severity in Enterprise Linux 4 AS in the first 4 years of its life, we determined if the flaw was something we knew about a day or more in advance of it being publicly disclosed, and how we found out about the flaw.

A graph showing the information sources

For vulnerabilities which are already public when we first hear about them we still track the source as it's a useful internal indicator on where the security response team should focus their efforts.

A graph showing the information sources

So from this data, Red Hat knew about 51% of the security vulnerabilities that we fixed at least a day in advance of them being publicly disclosed. For those issues, the average notice was 21 calendar days, although the median was much lower, with half the private issues having advance notice of 9 days or less.

A graph showing the information
sources

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: