The slowest curl vendors of all time

In the curl project we make an effort to ship security fixes as soon as possible after we’ve learned about a problem. We also “prenotify” (inform them about a problem before it gets known to the public) vendors of open source OSes ahead of the release to alert them about what is about to happen and to make it possible for them to be ready and prepared when we publish the security advisory of the particular problems we’ve found.

These distributors ship curl to their customers and users. They build curl from the sources they host and they apply (our and their own) security patches to the code over time to fix vulnerabilities. Usually they start out with the clean and unmodified version we released and then over time the curl version they maintain and ship gets old (by my standards) and the number of patches they apply grow, sometimes to several hundred.

The distros@openwall mailing list allows no more than 14 days of embargo, so they can never be told any further than so in advance.

We always ship at least one official patch for each security advisory. That patch is usually made for the previous version of curl and it will of course sometimes take a little work to backport to much older curl versions.

Red Hat

The other day I was reading LWN when I saw their regular notices about security updates from various vendors and couldn’t help checking out a mentioned curl security fix from Red Hat for Red Hat Enterprise Linux 7. It was dated July 29, 2019 and fixed CVE-2018-14618, which we announced on September 5th 2018. 327 days ago.

Not quite reaching Apple’s level, Red Hat positions themselves as number three in this toplist with this release.

An interesting detail here is that the curl version Red Hat fixed here was 7.29.0, which is the exact same version our winner also patched…

(Update after first publication: after talks with people who know things I’ve gotten some further details. Red Hat did ship a fix for this problem already in 2018. This 2019 one was a subsequent update for complicated reasons, which may or may not make this entry disqualified for my top-list.)


At times when I’ve thought it has been necessary, I’ve separately informed the product security team at Apple about a pending release with fixes that might affect their users, and almost every time I’ve done that they’ve responded to me and asked that I give them (much) longer time between alert and release in the future. (Requests I’ve ignored so far because it doesn’t match how we work nor how the open vendors want us to behave). Back in 2010, I noticed how one of the security fixes took 391 days for Apple to fix. I haven’t checked, but I hope they’re better at this these days.

With the 391 days, Apple takes place number two.


Oracle Linux published the curl errata named ELSA-2019-1880 on July 30 2019 and it apparently fixes nine different curl vulnerabilities. All nine were the result of the Cure53 security audit and we announced them on November 2 2016.

These problems had at that time been public knowledge for exactly 1000 days! The race is over and Oracle got this win by a pretty amazing margin.

In this case, they still ship curl 7.29.0 (released on February 6, 2013) when the latest curl version we ship is version 7.65.3. When I write this, we know about 47 security problems in curl 7.29.0. 14 of those problems were fixed after those nine problems that were reportedly fixed on July 30. It might mean, but doesn’t have to, that their shipped version still is vulnerable to some of those…


Summing up, here’s the top-3 list of all times:

  1. Oracle: 1000 days
  2. Apple: 391 days
  3. Red Hat: 327 days

Ending notes

I’m bundling and considering all problems as equals here, which probably isn’t entirely fair. Different vulnerabilities will have different degrees of severity and thus will be more or less important to fix in a short period of time.

Still, these were security releases done by these companies so someone there at least considered them to be security related, worth fixing and worth releasing.

This list is entirely unscientific, I might have missed some offenders. There might also be some that haven’t patched these or even older problems and then they are even harder to spot. If you know of a case suitable for this top-list, let me know!

10 thoughts on “The slowest curl vendors of all time”

  1. I would write something insightful here, but I can’t be bothered right now, so I’ll do it next year!

  2. Can’t say I’m surprised by Apple and Oracle, but somewhat disappointed by RedHat. I understand concerns about every release having the potential to break things, but low-priority or not, that’s a long time to be sitting on a fix for a security bug.

    1. I’m being told I’ve misread the Red Hat situation. I might have reason to do an update/correction once I’ve figured out if indeed I have…

      1. Well, giving an example of a CVE that is only present on 32bit systems and complaining it was fixed late in RHEL 7 which doesn’t even have a 32bit version (only 64bit)… I think it deserves a correction 😉

  3. If that is the case (that Red Hat doesn’t have a 32 bit version of RHEL7), I think it deserves an explanation from Red Hat and not from me. They claim “This issue has been addressed in the following products” so if they don’t even ship a 32 bit version they fixed a problem they didn’t even have…

    Update to this comment: a friend at Red Hat says “For compatibility reasons we still ship a lot of 32 bit versions” – so the fix could actually have merit there.

    1. You’re right. They must have 32bit versions of packages for compatibility reasons, but the kernel is always 64bit. So it’s a question what “32 bit systems” in the CVE description practically means. Red Hat has different response times for security issues. If they’re critical they guarantee a fix within a week, if they assess it as low or minimal impact, they have much more relaxed deadlines.

      1. It means “systems with a 32-bit size_t”, exactly what it says. When compiling 32-bit applications, even if they’re subsequently run on 64-bit systems, size_t is indeed limited to 32 bits.

        (I just compiled a test program on my Fedora 30 64-bit system to check, using g++ -m32. sizeof(size_t) is 8 (bytes) without -m32, and 4 with it.)

        Their tracker page for the advisory shows that Red Hat updated the curl in the httpd24 collection for RHSCL on 2018-11-13, but missed the curl in RHEL7 proper until last month — even though there is a libcurl.i686 package in RHEL7 that would be vulnerable.

        There’s no indication of RHEL7’s libcurl.i686 being updated in the 2018-11-13 fixes, only RHSCL’s httpd24-curl.x86_64 and httpd24-libcurl.x86_64. (Those wouldn’t have been vulnerable anyway, since there are no .i686 builds.)

      2. RHBZ 1622707 (which tracks CVE-2018-14618) was updated two months ago with a dependency on a restricted bug, RHBZ 1714209. While I can’t see the contents of that bug, presumably it’s restricted because the reporter flagged it as security-sensitive. (Which is a standard feature of Red Hat’s Bugzilla, I’m not insinuating any sort of coverup or nefarious motives.)

        If I had to guess, RHBZ 1714209 prompted the reevaluation of the status of this CVE, and the subsequent (very tardy) correction of the missed update to RHEL7’s libcurl.i686.

  4. Current MacOS

    ?75% [kris:~] 7m35s $ which curl

    ?66% [kris:~] $ curl –version
    curl 7.54.0 (x86_64-apple-darwin18.0) libcurl/7.54.0 LibreSSL/2.6.5 zlib/1.2.11 nghttp2/1.24.1
    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
    Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets HTTPS-proxy

Comments are closed.