General News

Status on CVE-2014-0160, aka “Heartbleed”

Copied from Robyn Bergeron’s post to the Fedora Announce mailing list, since we want to make people aware of the updates for the OpenSSL vulnerability as quickly as possible.heartbleed

If you’re not aware of the vulnerability, you can find more information via heartbleed.com. In short, “The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet.”

Greetings, Fedora community:

We’re aware of the recently disclosed CVE-2014-0160 (aka
“Heartbleed”):

https://bugzilla.redhat.com/show_bug.cgi?id=1085065 (openssl)
https://bugzilla.redhat.com/show_bug.cgi?id=1085066 (mingw-openssl)

The issue affects the currently supported Fedora 19 and Fedora 20
releases. Updates for openssl packages are available now, and
mirrors near you will receive them shortly. If you do not want to
wait for your local mirror to get updates, you can retrieve and
install packages directly:

For Fedora 19 x86_64:
yum -y install koji
koji download-build --arch=x86_64 openssl-1.0.1e-37.fc19.1
yum localinstall openssl-1.0.1e-37.fc19.1.x86_64.rpm

For Fedora 20 x86_64:
yum -y install koji
koji download-build --arch=x86_64 openssl-1.0.1e-37.fc20.1
yum localinstall openssl-1.0.1e-37.fc20.1.x86_64.rpm

Additionally, if you would like signed packages, you can retrieve and install those signed packages directly as well:

For Fedora 19 x86_64:
yum -y install koji
koji download-build --key=fb4b18e6 --arch=x86_64 openssl-1.0.1e-37.fc19.1
yum localinstall openssl-1.0.1e-37.fc19.1.x86_64.rpm

For Fedora 20 x86_64:
yum -y install koji
koji download-build --key=246110c1 --arch=x86_64 openssl-1.0.1e-37.fc20.1
yum localinstall openssl-1.0.1e-37.fc20.1.x86_64.rpm

Substitute i686 for 32-bit systems, or armv7hl for ARM systems (F20 only).

Package updates for mingw-openssl will receive fixes shortly and we’ll update the community when they are available. Note that Fedora 18, which is no longer supported by the Fedora community, is also affected by this issue. Fedora 17 and previous releases, also no longer supported, are not affected by this issue.

Fedora Release Engineering is currently regenerating AMIs and qcow2/kvm images to include the fix. The Fedora Infrastructure team is working to assess any additional impact, and will update the community as we develop more information.

Thanks for your patience as we work on this issue.

ACKNOWLEDGMENTS: Special thanks to Dennis Gilmore for quickly providing package updates, and Major Hayden for providing the manual update guidance above.

-Robyn Bergeron

 

UPDATE: See Update on CVE-2014-0160, aka “Heartbleed”, which provides more current information.

Please see the updated post for current instructions on updating your system, including some important notes that didn’t make the initial message.

About admin

No information is provided by the author.

18 Comments

  1. Till Maas

    Is it really correct, that only the openssl package and not the openssl-libs package needs to be updated? It does not sound right.

    Also IMHO Fedora should always advise users to only install properly signed packages are they were properly verified. The verification step is missing in this notification, i.e. running rpm --checksig *.rpm and only accepting packages if the output includes pgp and OK.

    • Till Maas

      I forgot to mention that the command from the posting cannot be easily copy&pasted, because the dashes are merged into one.

      And there is a python script to simplify gpg signature validation:
      http://yum.baseurl.org/download/misc/checksig.py

      • Ruth Suehle

        Good catch on WP autocorrecting a double hyphen to an em dash. Fixed!

    • You can just run ‘yum update *.rpm’ after downloading the packages, and let yum sort it out. It’ll do the right thing.

      yum also checks the package signatures, there’s really no need to do it separately.

      • Till

        yum does not check the package signatures if the files are installed from the local file system. This changed a while back. See localpkg_gpgcheck in man yum.conf.

  2. The Fedora Cloud images are now respun and should shortly be available at http://fedoraproject.org/get-fedora#clouds — follow https://fedorahosted.org/fedora-websites/ticket/257 to get status of that or to get updated AMI ids right now.

  3. Bill Burgess

    Has any consideration been given to releasing an update for Fedora 18? I understand 18 went EOL several weeks ago, but there are surely servers out there still running 18. In the interest of overall network security it seems worthwhile to make an exception to the EOL to minimize the damage done by this severe bug.

    • Foobar

      Most of the day has gone and no reply on updating F18? Is it really worth it to ignore this issue and not upgrade the F18 package because it’s past its EOL even when it was mentioned explicitly as a platform that has the bug? Is this some attempt at making people run away from fedora?

      • We really don’t have the resources to support old releases. Please update to a supported Fedora. We have worked to make that as easy as possible.

        Failing that, it really should be pretty easy to rebuild the openssl package for F18 if you really need to, but there are other security issues which will remain unaddressed. If we start making a call that certain vulnerabilities make us reach back in time, it lulls people into a false sense of security about running unsupported releases.

        If you’d like to work towards helping Fedora support longer lifetimes or older releases, that contribution would certainly be welcome, but please do not underestimate the effort required.

        • Foobar

          Yes, I know about the resources needed for general support. Something like the ubuntu LTS would have been nice, but I’m not even talking about that. The thing is that this particular bug had a huge exposure — so regardless of how bad it really is compared to other security issues, it’s bad in the sense of “huge exposure” => “huge rush of script kiddies to exploit it”, which means that this is definitely an exceptional situation.

          As someone who doesn’t really deal with building RPMs regularly, the effort on my side is much bigger than it’d take someone who knows how to do things. It took me a good number of hours to try to get the thing to compile, and at 3am I finally managed to get the RPMs, but couldn’t install them. (Being up for 48 hours makes it easy to miss things, and only today have I realized that I need –nodeps instead of –force…) I’d obviously be happy to put them up somewhere, but that problem might trip people who try to use it. There’s probably a way to make RPMs that work nicely, since the deps complaint was for libcrypto.so.10 which is still provided by the new RPM, and I had no use of anything static. And I think that it would be great to have just that: make such RPMs available somewhere on a Fedora site, with the obvious disclaimers about an OS who went past its life support anyway. Obviously, even better if it can be dropped onto the yum repository to make it a simple “yum update”: I get the point of lulling people, but this is really an exceptional situation due to the exposure and the rush of hacking attempts that is already going on.

          To summarize this, I think that it’s really a minimal effort on the Fedora side (just an updated set of RPMs), and a huge benefit for people who use it and therefore a good way to maintain a good reputation.

          • Well, that is why we did make sure to mention F18 in the messaging. It’s really not as easy as it seems, though. I don’t think we even have the build infrastructure in place to make official F18 rpms anymore — we’d have to re-set that up.

        • Bill Burgess

          Well, I’m no Linux dev expert but I built openssl from sources and it works. Sort of.

          Fedora makes its EOL practice very clear, and I agree that anybody who installs the latest version of Fedora should be well aware that in as little as six months they will be on their own no matter the severity of any issues discovered afterward. Yet when something this significant happens does it not make Fedora seem like a less professional solution to shrug and say it’s a lot of work and you should have known better, even though both are absolutely true?

          Going forward, may I humbly suggest that Fedora consider a two-stage EOL process in which security updates, or maybe just “significant” security updates, continue for at least another 6 months after initial EOL? A supported life as short as six months is the blink of an eye for people who want to use Fedora but have many other hats to wear and may be located remotely from the machines for which they’re responsible.

          • The supported life is 13 months. I agree that what you’re saying would be nice to have, but someone needs to step up and say they’re willing to put effort behind it. If that’s you, awesome. If not, it’s still a fine suggestion, but we already have more ideal work to do than possible, so it’s the contributions that ultimately sway prioritization.

          • Bill Burgess

            It’s an imperfect situation but at least it’s clear, and that’s something to acknowledge. I do appreciate your hard work.

            My reference to a supported life “as short as six months” meant simply that a user who installs the latest version could find himself without any support in as little as six months depending on when the install took place. Not all users are able to schedule installation to optimize supported life.

  4. Tony Martin

    I have been happily using Fedora now for many years and have never had too much of an issue with EOL, but this bug has made the question much more poignant. I tend to agree with Bill Burgess that this type of situation does seem to a special case for at least providing some mechanism to allow users on F18 to upgrade the Openssl packages. I guess I need to give more forward thought to EOL issues now.

Trackbacks / Pings

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>