| |
mark :: blog :: redhat
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" ;)
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.
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:
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.
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.
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.
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.
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.
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.

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.

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.

|
|
|
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

|
|