patching, changelog and CVE numbers

Latest response

Via inspection of the changelog, it appears that one local system cannot account for any CVEs for OpenSSL 0.9.8e for the last 2 years (since 2012.

If the latest OpenSSL patch (via RHN) were applied, would that patch (cumulatively) carry forward all previous CVEs, or would all previous OpenSSL patches need to be applied as well in order to cover all the CVE bases?



Redhat patches are cummulative; you need only apply the latest one.

So, even though I use:

rpm -q --changelog package_name | grep CVE

and don't see any CVEs (for OpenSSL) for 2012, 2013, or 2014, I should assume that they're included?

I ask b/c before applying the latest patch for OpenSSL, nothing appeared for 2012-14. After the patching, the ONLY CVEs that appeared for 2012-14 were those covered by the latest patch?


I'm guessing most of the newer CVE's only apply to later code that doesn't exist in the fairly archaic redhat 5 openssl v0.9.8e. Redhat generally backports applicable security fixes, and if they are severe, quite promptly. If some CVE's aren't listed, the likely conclusion is that they don't apply and thus don't need to be and can't be fixed in that version, not that they still need to be fixed. I admit that comparing the changelogs for openssl on redhat 5 and redhat 6 makes for scary reading.

In any case, updating to the latest version (0.9.8e-27.el5_10.4 for redhat 5) gets you 100% of whatever security and other bug fixes redhat has on offer.

Please refer to Marc Milgram's answer below for the most specific answer to the question for this customer. Namely, how to determine the list of CVEs addressed by any given rpm (see Marc Milgran's bit below)

That being said...

Also see this Red Hat Security article, "Backporting Security Fixes". You will find that after successful patching, the latest RHEL version of a given rpm will not match the open source version. That's where the backporting comes in that is discussed both in the earlier posts above, and in the link within this paragraph. Make particular note of the last third of the material on that one-page article under the title: "Explaining Common Release-Numbering Confusion".

You can also look up specific Red Hat Vulnerabilities by CVE names at Red Hat's own CVE useful web interface. The benefit of Red Hat's CVE web interface is the filter function for any given keyword (highly useful). The date range runs from 1999 to present.

Red Hat goes into detail on their involvement with the CVE project, along with other details.

For those customers that use IAVA/IAVM reports, they can use the Red Hat IAVM Mapper at this link too. Lastly, DISA gives out an IAVA to CVE spreadsheet in xml and excel format publically at this link.

Kind Regards,

OK, so I read thru all of the above and the question is STILL unanswered, whether by design or sheer lack of want to provide a straight answer. IF I were to interrogate a 5.9 system (with 0.9.8e OpenSSL) for changelog information via YUM (for OpenSSL), should I or should I NOT be able to see WHAT CVEs have been applied via updates to this backported version?

I see Marc got you what seems to be what you are looking for, that's a handy method he posted. On a separate note...

While Marc gave you the direct answer you wanted, (and on a side-note) here's a way to check applicability of a known list of CVEs (perhaps from a list created by a search from the Red Hat CVE link listed in #1 below); this would at minimum tell you if you have a CVE (or list of targeted CVEs) that does or does not apply.

So here's one possibility to satiate any queries for existing applicable CVEs.

1) get the list of all applicable CVEs from Red Hat you wish,
- at that above Red Hat link, you can enter "openssl" and filter out only openssl items, or filter against any other search term
- Place these into a file, one line after another, such as this limited example:
NOTE: These CVEs below are from limiting the CVEs to "openssl" in the manner I described above, and the list is not completed, there are plenty more for your date range.

NOTE Adjust as needed for your specific date range or requirements


2) Keeping this Red Hat solution in mind Run something like the following as root:

[root@yoursystem]# bash
[root@yoursystem]# for i in `cat listyoumade.txt`;yum update --cve $i;done

And if the cve applies, it will prompt you to take the update, if it does not apply, it will tell you

Alternatively, I tried this to exit with "n" if it found a hit:

[root@yoursystem]# bash
[root@yoursystem]# for i in `cat listyoumade.txt`;echo n |yum update --cve $i;done

Hello John,

I just downloaded the latest openssl rpm for RHEL 5.9. I can list numerous CVEs that were fixed in it:

$ rpm -qp --changelog openssl-0.9.8e-27.el5_10.4.x86_64.rpm | grep CVE
- fix CVE-2014-0221 - recursion in DTLS code leading to DoS
- fix CVE-2014-3505 - doublefree in DTLS packet processing
- fix CVE-2014-3506 - avoid memory exhaustion in DTLS
- fix CVE-2014-3508 - fix OID handling to avoid information leak
- fix CVE-2014-3510 - fix DoS in anonymous (EC)DH handling in DTLS
- fix for CVE-2014-0224 - SSL/TLS MITM vulnerability
- fix for CVE-2013-0169 - SSL/TLS CBC timing attack (#907589)
- fix for CVE-2013-0166 - DoS in OCSP signatures checking (#908052)
  environment variable is set (fixes CVE-2012-4929 #857051)
- fix for CVE-2012-2333 - improper checking for record length in DTLS (#820686)
- fix for CVE-2012-2110 - memory corruption in asn1_d2i_read_bio() (#814185)
- fix for CVE-2012-0884 - MMA weakness in CMS and PKCS#7 code (#802725)
- fix for CVE-2012-1165 - NULL read dereference on bad MIME headers (#802489)
- fix for CVE-2011-4108 & CVE-2012-0050 - DTLS plaintext recovery
- fix for CVE-2011-4109 - double free in policy checks (#771771)
- fix for CVE-2011-4576 - uninitialized SSL 3.0 padding (#771775)
- fix for CVE-2011-4619 - SGC restart DoS attack (#771780)
- fix CVE-2010-4180 - completely disable code for
- fix CVE-2009-3245 - add missing bn_wexpand return checks (#570924)
- fix CVE-2010-0433 - do not pass NULL princ to krb5_kt_get_entry which
- fix CVE-2009-3555 - support the safe renegotiation extension and
- fix CVE-2009-2409 - drop MD2 algorithm from EVP tables (#510197)
- fix CVE-2009-4355 - do not leak memory when CRYPTO_cleanup_all_ex_data()
- fix CVE-2009-1386 CVE-2009-1387 (DTLS DoS problems)
- fix CVE-2009-1377 CVE-2009-1378 CVE-2009-1379
- fix CVE-2009-0590 - reject incorrectly encoded ASN.1 strings (#492304)
- fix CVE-2008-5077 - incorrect checks for malformed signatures (#476671)
- fix CVE-2007-3108 - side channel attack on private keys (#250581)
- fix CVE-2007-5135 - off-by-one in SSL_get_shared_ciphers (#309881)
- fix CVE-2007-4995 - out of order DTLS fragments buffer overflow (#321221)
- CVE-2006-2940 fix was incorrect (#208744)
- fix CVE-2006-2937 - mishandled error on ASN.1 parsing (#207276)
- fix CVE-2006-2940 - parasitic public keys DoS (#207274)
- fix CVE-2006-3738 - buffer overflow in SSL_get_shared_ciphers (#206940)
- fix CVE-2006-4343 - sslv2 client DoS (#206940)
- fix CVE-2006-4339 - prevent attack on PKCS#1 v1.5 signatures (#205180)

Marc, thanks for that, that's a useful command for existing rpms and CVE applicability.

Thanks John for asking for this.

The problem with this method generally is that there is no consistency and it can't be relied upon. For example, look at the latest bash package changelog.

2014-09-25 Ondrej Oprala <> - 4.1.2-15.2
    - CVE-2014-7169
    Resolves: #1146322
2014-09-15 Ondrej Oprala < - 4.1.2-15.1
    - Check for fishy environment
    Resolves: #1141645

The 'Check for fishy environment' is the CVE-2014-6271 fix (validated by looking at the Bugzilla listed), but CVE-2014-6271 isn't mentioned anywhere.

Additional to that, the changelog lists 2014-09-15 as the patch release date (age of the bugzilla), but the CVE-2014-6271 advisory wasn't released until the 24th, so it appears the CVE was never retrofitted / added when it was determined that the issue was major.


That's the answer I originally expected to get based on my understanding of the process. For example, I have access to a number of RHEL5.9 systems w/OpenSSL 0.9.8.e, where when interrogated via rpm (as above) or via YUM, there was essentially NOTHING reported for 2014, 2013 and 2012. The CVE list began at 2006 and incremented thru 2011. So essentially, this system's OpenSSL (and possibly other) package(s) had not been updated in years.

Thank You.

...this system's OpenSSL (and possibly other) package(s)
had not been updated in years.

"rpm -qi openssl" will, of course, tell you both the build and install dates of the currently running version. If they aren't both in 2014, then "years" is all too accurate.

Carlin, resurrecting this discussion from a while ago... an additional side-topic for this discussion. Here's how to see what CVEs were mitigated within a given rpm:

rpm -q [name-of-rpm] --changelog | grep CVE
rpm -q glibc --changelog | grep CVE

Not all CVEs are documented in changelog, often there is only a reference to a Bugzilla number :(

That seems to follow what PixelDrift mentioned 29 September 2014 11:40 PM

I had a question about the output here:

[MySystem.rhel6-64 ~]$ rpm -qi ksh

Name : ksh Relocations: (not relocatable)

Version : 20120801 Vendor: Red Hat, Inc.

Release : 37.el6_9 Build Date: Mon 22 Jan 2018 06:19:5T

Install Date: Mon 02 Apr 2018 08:44:41 AM EDT Build Host:

Group : System Environment/Shells Source RPM:

Size : 1743311 License: EPL

Signature : RSA/8, Mon 22 Jan 2018 08:15:57 AM EST, Key ID XXXXXXXXXXXXX

Packager : Red Hat, Inc.


Summary : The Original ATT Korn Shell

Description : KSH-93 is the most recent version of the KornShell by David Korn of AT&T Bell Laboratories. KornShell is a shell programming language, which is upward compatible with "sh" (the Bourne Shell).

Why is there such a large lapse of time between the "Build Date" and the "Install Date"? Ofcourse, I understand the Date Installed was when MY system was updated, although this update may have been made available several weeks ago, but certainly way after the date listed around January in the above example. I run updates monthly and didn't see this package in the RPM until recently. I was just using ksh as an example, but I often notice this in other packages that get updated - lapses of times that could be months.
Is there a lapse of time from the build date until it's release date?

The "Build date" is the date that the package is built. After a package is built, it goes through a QA (testing) cycle before it is released. The time between when the package is built and when it is released is anywhere from a few days to a number of months.

When you install the updated package is up to you, and that will be the Installed date.