11 ms·

OpenSSL will release a high-severity issue fix on 25th

282 points by yread 6y ago

jonas21 6y ago
Note that HIGH severity isn't the highest severity (that's CRITICAL) [1]. The last high severity fix in OpenSSL was this past December. [1] https://www.openssl.org/policies/secpolicy.html https://www.openssl.org/policies/secpolicy.html
- hosteur 6y ago
  What was the severity of heart bleed?
  - richardwhiuk 6y ago
    https://www.openssl.org/news/secadv/20140407.txt https://www.openssl.org/news/secadv/20140407.txt is the advisory, but this was back when OpenSSL wasn't as well maintained. It would have been CRITICAL.
  - leonardinius 6y ago
    It was CRITICAL and warranted new severity level added [1] [1] - https://www.openssl.org/blog/blog/2015/09/28/critical-security-level/ https://www.openssl.org/blog/blog/2015/09/28/critical-securi...
  - deleted 6y ago
    [deleted]
- 0x003 6y ago
  > HIGH Severity. This includes issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control So something to make sure you update, but not a Heartbleed level concern
tptacek 6y ago
The last sev:hi OpenSSL vulnerability was an X.509 null pointer read, crash-only, just in case you're calibrating expectations.
- orblivion 6y ago
  Do they usually give 3 days lead time? That's what gets my attention here.
  - bcaa7f3a8bbc 6y ago
    Yes, all HIGH severity vulnerabilities (even MODERATE) have lead time. e.g. see https://mta.openssl.org/pipermail/openssl-announce/2021-February/000191.html https://mta.openssl.org/pipermail/openssl-announce/2021-Febr...
    - spockz 6y ago
      I really like the lead time. It gives everyone time to prepare to patch ASAP when it is released without having the vulnerability available to attackers through diffing the binary. On the other hand, it gives people that found the vulnerability independently a bit of extra time to exploit.
      - koolba 6y ago
        > It gives everyone time to prepare to patch ASAP when it is released without having the vulnerability available to attackers through diffing the binary. It’s an open source library so the code of the patch will be available as soon as it’s published. It’s not released as a compiled library.
        spockz 6y ago
        Yes, indeed in the case of OpenSSL indeed but I was referring to applying the practice in general. With an open source product the lead time is even more important. Even then, they could release the binaries from a private branch/repository so that packages can be updated before the source is released.
snvzz 6y ago
We should all have switched to libressl a long, long time ago. For some reason, companies decided to put money into the known-bad openssl instead, as if money could fix a bad development culture.
- tptacek 6y ago
  I would probably use OpenSSL in preference to LibreSSL at this point. The dev culture point you’re trying to make hasn’t really been true for many years.
- tubbyjr 6y ago
  Somewhat ironically to this circumstance (assuming it doesn't affect LibreSSL), the Void team has just switched back away from LibreSSL which it shipped by default with for years. Discussion: https://github.com/void-linux/void-packages/issues/20935 https://github.com/void-linux/void-packages/issues/20935
  - spijdar 6y ago
    AFAIK every other linux distro shipping with or providing options for LibreSSL also switched around the same time frame, e.g. Gentoo dropped all support for it. It's just not feasible to build 3rd party software (that are targeting OpenSSL) with it anymore (obviously, if you targeted libressl specifically, there's no problem, but almost nothing does). Maintainers have just gotten tired of writing giant patches to get things like Qt5 working again.
mjevans 6y ago
Why is this embargoed until a Thursday; isn't "patch Tuesday" the usual mantra? That's the downtime window where I work as a result.
- danielheath 6y ago
  “Patch Tuesday” is a Microsoft policy afaik, not a global one.
  - mjevans 6y ago
    Yes, but knowing others, particularly in other companies, expect downtime on Tuesdays as a result, wouldn't you also pick the day everyone expects that downtime?
    - tedunangst 6y ago
      I think you have mismanaged your expectations.
    - arbitrage 6y ago
      you expect downtime as a normal matter of doing business? you can do better, my friend. you are worth better.
  - Aaargh20318 6y ago
    Sure, but still strange to release this on a Thursday afternoon. This means that everyone who depends on OpenSSL needs to rebuild and test and will have an update ready on Friday afternoon in the best case. Who wants to roll out any kind of update to their production systems on a Friday afternoon ? That’s just asking for trouble.
    - qbasic_forever 6y ago
      On the other hand, this is a high severity issue in security critical code that has had huge exploits in the past (heartbleed). This is the kind of security patch a good ops team is expecting and ready to handle at a moment's notice. It's far less annoying to do a Friday afternoon update than deal with active exploits all weekend.
dorianmariefr 6y ago
Will it also be a vulnerability in boringssl and libressl? only speculations
ollien 6y ago
Not that there's much to read here, but here's an archive link https://web.archive.org/web/20210322203019/https://mta.openssl.org/pipermail/openssl-announce/2021-March/000196.html https://web.archive.org/web/20210322203019/https://mta.opens...
seaghost 6y ago
I often ask myself how long these things are exploited in the wild before they get revealed.
- interestica 6y ago
  And I ask myself if announcing a fix with a few days lead time: 1. increases searches for the exploit 2. causes those with the exploit to utilize it as often as possible before its planned enddate.
yholio 6y ago
Can't believe that, in God's year 2021, 3rd millennia, Earth, we're still using security libraries written in what is essentially a portable assembly language, doing silly things like pointer arithmetic, manually allocating memory, and other chainsaw juggling feats. I swear some day we'll look back to this period with bewilderment: son, in those days people used to smoke carcinogens for their taste, drive their own cars and treat mental disorders with an ice pick in the prefrontal cortex. Trully mad men would even implement X.509 in unsafe languages.
- tptacek 6y ago
  It would be good to know if this vulnerability was related to memory safety before pinning it on memory safety. You can get cryptography just as wrong in Rust or Go.
  - dochtman 6y ago
    No argument from me that you can easily go wrong in any language, but I would argue that Rust has features other than memory safety that can also assist in building more reliable/secure software.
    - wglb 6y ago
      Such as?
      - dochtman 6y ago
        Match statement exhaustiveness checking is one example, especially combined with the pervasiveness of enums (instead of constants).
        junon 6y ago
        Any respectable C compiler does this.
        6y ago
trinovantes 6y ago
For the average developer what do I need to do? I don't use OpenSSL directly but I'm pretty sure some parts of my tech stack use it as a dependency. Do I simply need to run `apt-get upgrade` on the 25th?
- vbezhenar 6y ago
  Restart your services or better reboot your server to be sure.
- tedunangst 6y ago
  Maintain a constant state of suspicious alertness until March 25th.
- qbasic_forever 6y ago
  Watch the debian security mailing list for information about when their fix is available to others through apt: https://lists.debian.org/debian-security-announce/ https://lists.debian.org/debian-security-announce/ In general you should be following this list if you're managing production services running debian or ubuntu.
- throw0101a 6y ago
  > Do I simply need to run `apt-get upgrade` on the 25th? Mostly, but some details matter. Make sure that when you do the upgrade, that you are fetching the fixed version. Check for the security announcement and see which version things get fixed in: * https://www.debian.org/security/ https://www.debian.org/security/ Once the CVE is known, you can also see which versions are vulnerable and which are fixed: * https://security-tracker.debian.org/tracker/CVE-2020-1971 https://security-tracker.debian.org/tracker/CVE-2020-1971 You may have to restart some services. The checkrestart utility is handy to find these: * https://packages.debian.org/buster/debian-goodies https://packages.debian.org/buster/debian-goodies * https://packages.debian.org/search?keywords=debian-goodies https://packages.debian.org/search?keywords=debian-goodies
smasher164 6y ago
Looking forward to the day that Evercrypt[1] becomes a production-ready replacement for libcrypto. [1] https://hacl-star.github.io/HaclValeEverCrypt.html https://hacl-star.github.io/HaclValeEverCrypt.html
dochtman 6y ago
I am a maintainer for rustls (https://github.com/ctz/rustls https://github.com/ctz/rustls). What would your team need to be able to migrate to a different TLS stack that so far has proven to be safer, and passed its first security audit with flying colors? (https://github.com/ctz/rustls/blob/main/audit/TLS-01-report.pdf https://github.com/ctz/rustls/blob/main/audit/TLS-01-report....) (I am also currently available on part-time freelance basis, feel free to contact me if you need commercial support on your endeavour to structurally address your TLS security issues.)
- 29athrowaway 6y ago
  As soon as it becomes popular, it will be backdoored for sure.
- sounds 6y ago
  Apps build rustls into a fat binary, which doesn't get updated on day zero by the OS package manager. It requires a new release by the app maintainer for each app.
- tedunangst 6y ago
  TLS 1.0 support.
  - ancarda 6y ago
    What do you need TLS 1.0 support for?
    - tedunangst 6y ago
      Talking to things that only support TLS 1.0. :( some old mail thing which doesn't know what year it is. I think min TLS 1.2 is probably fine for a new library, but I also think believing it's universal is pretty web centric.
      - SAI_Peregrinus 6y ago
        TLS 1.0 isn't secure. I'd rather insecure protocols and primitives not be included in a mainstream library. Maybe offer some extension library to allow support, but the default shouldn't have any risk of including such code in a way that it could be usable by a careless programmer. Same for MD5 and SHA1.
ashneo76 6y ago
I am all for shared libraries. Update openssl and everything else gets the patch. With rust/go, now I have to wait for all the authors to release their fat binaries of the same dependencies
- edoceo 6y ago
  There was a post here a few days ago by one of the Gentoo maintainers talking about how static builds are bad and this exact reason (security vulnerability that touches lots of things) was one mentioned.
janvidar 6y ago
Not sure if this is related, but LibreSSL released version 3.2.5 with one fix last week: * A TLS client using session resumption may cause a use-after-free.
jez 6y ago
Site appears to be hugged to death. Here's the full text of the email: The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1k. This release will be made available on Thursday 25th March 2021 between 1300-1700 UTC. OpenSSL 1.1.1k is a security-fix release. The highest severity issue fixed in this release is HIGH: https://www.openssl.org/policies/secpolicy.html#high Yours The OpenSSL Project Team https://web.archive.org/web/20210322203019/https://mta.openssl.org/pipermail/openssl-announce/2021-March/000196.html https://web.archive.org/web/20210322203019/https://mta.opens...
dang 6y ago
This is a pretty low-information post and the discussion is therefore pretty generic. In such cases it's better to wait until the thing actually comes out, and with it enough information to support a specific discussion. https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22no%20harm%20in%20waiting%22%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so... https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=generic%20discussion%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
- bluejekyll 6y ago
  dang, do you think the fact that this is announcing a date in the future to look out for potentially an exploitable issue and folks may want to discuss ways to mitigate that? granted, much of the discussion is not about that at this point, though there is a bit: https://news.ycombinator.com/item?id=26547279 https://news.ycombinator.com/item?id=26547279
  - dang 6y ago
    That would be a fine basis for discussion but I think it would need to be seeded by an article specifically about that.

282 points by yread 6y ago

Note that HIGH severity isn't the highest severity (that's CRITICAL) [1]. The last high severity fix in OpenSSL was this past December. [1] https://www.openssl.org/policies/secpolicy.html https://www.openssl.org/policies/secpolicy.html

hosteur 6y ago
What was the severity of heart bleed?
- richardwhiuk 6y ago
  https://www.openssl.org/news/secadv/20140407.txt https://www.openssl.org/news/secadv/20140407.txt is the advisory, but this was back when OpenSSL wasn't as well maintained. It would have been CRITICAL.
- leonardinius 6y ago
  It was CRITICAL and warranted new severity level added [1] [1] - https://www.openssl.org/blog/blog/2015/09/28/critical-security-level/ https://www.openssl.org/blog/blog/2015/09/28/critical-securi...
- deleted 6y ago
  [deleted]
0x003 6y ago
> HIGH Severity. This includes issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control So something to make sure you update, but not a Heartbleed level concern

tptacek 6y ago

The last sev:hi OpenSSL vulnerability was an X.509 null pointer read, crash-only, just in case you're calibrating expectations.

orblivion 6y ago
Do they usually give 3 days lead time? That's what gets my attention here.
- bcaa7f3a8bbc 6y ago
  Yes, all HIGH severity vulnerabilities (even MODERATE) have lead time. e.g. see https://mta.openssl.org/pipermail/openssl-announce/2021-February/000191.html https://mta.openssl.org/pipermail/openssl-announce/2021-Febr...
  - spockz 6y ago
    I really like the lead time. It gives everyone time to prepare to patch ASAP when it is released without having the vulnerability available to attackers through diffing the binary. On the other hand, it gives people that found the vulnerability independently a bit of extra time to exploit.
    - koolba 6y ago
      > It gives everyone time to prepare to patch ASAP when it is released without having the vulnerability available to attackers through diffing the binary. It’s an open source library so the code of the patch will be available as soon as it’s published. It’s not released as a compiled library.
      - spockz 6y ago
        Yes, indeed in the case of OpenSSL indeed but I was referring to applying the practice in general. With an open source product the lead time is even more important. Even then, they could release the binaries from a private branch/repository so that packages can be updated before the source is released.

snvzz 6y ago

We should all have switched to libressl a long, long time ago. For some reason, companies decided to put money into the known-bad openssl instead, as if money could fix a bad development culture.

tptacek 6y ago
I would probably use OpenSSL in preference to LibreSSL at this point. The dev culture point you’re trying to make hasn’t really been true for many years.
tubbyjr 6y ago
Somewhat ironically to this circumstance (assuming it doesn't affect LibreSSL), the Void team has just switched back away from LibreSSL which it shipped by default with for years. Discussion: https://github.com/void-linux/void-packages/issues/20935 https://github.com/void-linux/void-packages/issues/20935
- spijdar 6y ago
  AFAIK every other linux distro shipping with or providing options for LibreSSL also switched around the same time frame, e.g. Gentoo dropped all support for it. It's just not feasible to build 3rd party software (that are targeting OpenSSL) with it anymore (obviously, if you targeted libressl specifically, there's no problem, but almost nothing does). Maintainers have just gotten tired of writing giant patches to get things like Qt5 working again.

mjevans 6y ago

Why is this embargoed until a Thursday; isn't "patch Tuesday" the usual mantra? That's the downtime window where I work as a result.

danielheath 6y ago
“Patch Tuesday” is a Microsoft policy afaik, not a global one.
- mjevans 6y ago
  Yes, but knowing others, particularly in other companies, expect downtime on Tuesdays as a result, wouldn't you also pick the day everyone expects that downtime?
  - tedunangst 6y ago
    I think you have mismanaged your expectations.
  - arbitrage 6y ago
    you expect downtime as a normal matter of doing business? you can do better, my friend. you are worth better.
- Aaargh20318 6y ago
  Sure, but still strange to release this on a Thursday afternoon. This means that everyone who depends on OpenSSL needs to rebuild and test and will have an update ready on Friday afternoon in the best case. Who wants to roll out any kind of update to their production systems on a Friday afternoon ? That’s just asking for trouble.
  - qbasic_forever 6y ago
    On the other hand, this is a high severity issue in security critical code that has had huge exploits in the past (heartbleed). This is the kind of security patch a good ops team is expecting and ready to handle at a moment's notice. It's far less annoying to do a Friday afternoon update than deal with active exploits all weekend.

dorianmariefr 6y ago

Will it also be a vulnerability in boringssl and libressl? only speculations

ollien 6y ago

Not that there's much to read here, but here's an archive link https://web.archive.org/web/20210322203019/https://mta.openssl.org/pipermail/openssl-announce/2021-March/000196.html https://web.archive.org/web/20210322203019/https://mta.opens...

seaghost 6y ago

I often ask myself how long these things are exploited in the wild before they get revealed.

interestica 6y ago
And I ask myself if announcing a fix with a few days lead time: 1. increases searches for the exploit 2. causes those with the exploit to utilize it as often as possible before its planned enddate.

yholio 6y ago

Can't believe that, in God's year 2021, 3rd millennia, Earth, we're still using security libraries written in what is essentially a portable assembly language, doing silly things like pointer arithmetic, manually allocating memory, and other chainsaw juggling feats. I swear some day we'll look back to this period with bewilderment: son, in those days people used to smoke carcinogens for their taste, drive their own cars and treat mental disorders with an ice pick in the prefrontal cortex. Trully mad men would even implement X.509 in unsafe languages.

tptacek 6y ago
It would be good to know if this vulnerability was related to memory safety before pinning it on memory safety. You can get cryptography just as wrong in Rust or Go.
- dochtman 6y ago
  No argument from me that you can easily go wrong in any language, but I would argue that Rust has features other than memory safety that can also assist in building more reliable/secure software.
  - wglb 6y ago
    Such as?
    - dochtman 6y ago
      Match statement exhaustiveness checking is one example, especially combined with the pervasiveness of enums (instead of constants).
      - junon 6y ago
        Any respectable C compiler does this.
        6y ago

trinovantes 6y ago

For the average developer what do I need to do? I don't use OpenSSL directly but I'm pretty sure some parts of my tech stack use it as a dependency. Do I simply need to run `apt-get upgrade` on the 25th?

vbezhenar 6y ago
Restart your services or better reboot your server to be sure.
tedunangst 6y ago
Maintain a constant state of suspicious alertness until March 25th.
qbasic_forever 6y ago
Watch the debian security mailing list for information about when their fix is available to others through apt: https://lists.debian.org/debian-security-announce/ https://lists.debian.org/debian-security-announce/ In general you should be following this list if you're managing production services running debian or ubuntu.
throw0101a 6y ago
> Do I simply need to run `apt-get upgrade` on the 25th? Mostly, but some details matter. Make sure that when you do the upgrade, that you are fetching the fixed version. Check for the security announcement and see which version things get fixed in: * https://www.debian.org/security/ https://www.debian.org/security/ Once the CVE is known, you can also see which versions are vulnerable and which are fixed: * https://security-tracker.debian.org/tracker/CVE-2020-1971 https://security-tracker.debian.org/tracker/CVE-2020-1971 You may have to restart some services. The checkrestart utility is handy to find these: * https://packages.debian.org/buster/debian-goodies https://packages.debian.org/buster/debian-goodies * https://packages.debian.org/search?keywords=debian-goodies https://packages.debian.org/search?keywords=debian-goodies

smasher164 6y ago

Looking forward to the day that Evercrypt[1] becomes a production-ready replacement for libcrypto. [1] https://hacl-star.github.io/HaclValeEverCrypt.html https://hacl-star.github.io/HaclValeEverCrypt.html

dochtman 6y ago

I am a maintainer for rustls (https://github.com/ctz/rustls https://github.com/ctz/rustls). What would your team need to be able to migrate to a different TLS stack that so far has proven to be safer, and passed its first security audit with flying colors? (https://github.com/ctz/rustls/blob/main/audit/TLS-01-report.pdf https://github.com/ctz/rustls/blob/main/audit/TLS-01-report....) (I am also currently available on part-time freelance basis, feel free to contact me if you need commercial support on your endeavour to structurally address your TLS security issues.)

29athrowaway 6y ago
As soon as it becomes popular, it will be backdoored for sure.
sounds 6y ago
Apps build rustls into a fat binary, which doesn't get updated on day zero by the OS package manager. It requires a new release by the app maintainer for each app.
tedunangst 6y ago
TLS 1.0 support.
- ancarda 6y ago
  What do you need TLS 1.0 support for?
  - tedunangst 6y ago
    Talking to things that only support TLS 1.0. :( some old mail thing which doesn't know what year it is. I think min TLS 1.2 is probably fine for a new library, but I also think believing it's universal is pretty web centric.
    - SAI_Peregrinus 6y ago
      TLS 1.0 isn't secure. I'd rather insecure protocols and primitives not be included in a mainstream library. Maybe offer some extension library to allow support, but the default shouldn't have any risk of including such code in a way that it could be usable by a careless programmer. Same for MD5 and SHA1.

ashneo76 6y ago

I am all for shared libraries. Update openssl and everything else gets the patch. With rust/go, now I have to wait for all the authors to release their fat binaries of the same dependencies

edoceo 6y ago
There was a post here a few days ago by one of the Gentoo maintainers talking about how static builds are bad and this exact reason (security vulnerability that touches lots of things) was one mentioned.

janvidar 6y ago

Not sure if this is related, but LibreSSL released version 3.2.5 with one fix last week: * A TLS client using session resumption may cause a use-after-free.

jez 6y ago

Site appears to be hugged to death. Here's the full text of the email: The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.1k. This release will be made available on Thursday 25th March 2021 between 1300-1700 UTC. OpenSSL 1.1.1k is a security-fix release. The highest severity issue fixed in this release is HIGH: https://www.openssl.org/policies/secpolicy.html#high Yours The OpenSSL Project Team https://web.archive.org/web/20210322203019/https://mta.openssl.org/pipermail/openssl-announce/2021-March/000196.html https://web.archive.org/web/20210322203019/https://mta.opens...

dang 6y ago

This is a pretty low-information post and the discussion is therefore pretty generic. In such cases it's better to wait until the thing actually comes out, and with it enough information to support a specific discussion. https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22no%20harm%20in%20waiting%22%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so... https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sort=byDate&type=comment&query=generic%20discussion%20by:dang https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...

bluejekyll 6y ago
dang, do you think the fact that this is announcing a date in the future to look out for potentially an exploitable issue and folks may want to discuss ways to mitigate that? granted, much of the discussion is not about that at this point, though there is a bit: https://news.ycombinator.com/item?id=26547279 https://news.ycombinator.com/item?id=26547279
- dang 6y ago
  That would be a fine basis for discussion but I think it would need to be seeded by an article specifically about that.