OpenSSL will release a high-severity issue fix on 25th(mta.openssl.org)
mta.openssl.org
OpenSSL will release a high-severity issue fix on 25th
https://mta.openssl.org/pipermail/openssl-announce/2021-March/000196.html
127 comments
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
granted, much of the discussion is not about that at this point, though there is a bit: https://news.ycombinator.com/item?id=26547279
That would be a fine basis for discussion but I think it would need to be seeded by an article specifically about that.
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
The last high severity fix in OpenSSL was this past December.
[1] https://www.openssl.org/policies/secpolicy.html
> 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
So something to make sure you update, but not a Heartbleed level concern
What was the severity of heart bleed?
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.
It would have been CRITICAL.
It was CRITICAL and warranted new severity level added [1]
[1] - https://www.openssl.org/blog/blog/2015/09/28/critical-securi...
[1] - https://www.openssl.org/blog/blog/2015/09/28/critical-securi...
[deleted]
I am a maintainer for 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....)
(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.)
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....)
(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.)
The interesting thing about TLS state machine bugs is that they seem hard to prove nonexistence of ahead of time.
Look at gotofail: https://www.imperialviolet.org/2014/02/22/applebug.html
You can find it if you have a generic "suspicious looking code" check. And you can find it if you have a protocol regression test. But do you have a model of TLS that proves incorrect code paths like this don't exist?
Look at gotofail: https://www.imperialviolet.org/2014/02/22/applebug.html
You can find it if you have a generic "suspicious looking code" check. And you can find it if you have a protocol regression test. But do you have a model of TLS that proves incorrect code paths like this don't exist?
We have some documentation on what we've done to learn from previous vulnerabilities:
https://docs.rs/rustls/0.19.0/rustls/manual/index.html
We try very hard to model our code as a constrained state machine that closely follows the specification.
https://docs.rs/rustls/0.19.0/rustls/manual/index.html
We try very hard to model our code as a constrained state machine that closely follows the specification.
That looks good. For your amusement I remembered another state machine bug in an SSH implementation:
https://nakedsecurity.sophos.com/2018/10/17/serious-ssh-bug-...
It included some server states in the client state machine, so if a client sent the server its own "authentication successful" message it… just let them in.
It included some server states in the client state machine, so if a client sent the server its own "authentication successful" message it… just let them in.
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.
Any idea when rustls will hit 1.0? I feel a little unsafe using a <1.0 library because (assuming it's following SemVer) as it might not be "done"/production ready and the API might change a lot before it hits 1.0.
The API has generally been pretty stable, so I don't think you should be too worried about that. I haven't talked to other stakeholders about a version 1.0, and we actually have some larger API changes cooking right now. For now we probably value the ability to change the API more, especially because there are likely still ways we can make it more robust/secure.
Do you support ppc64le? WebAssembly? Not a requirement for me, but the fact that ring has no portable implementations is concerning. How do you verify correctness without a baseline? Evercrypt seems like a much better option on that front.
I think ring does support WebAssembly. Yeah, the ASM in ring is not great, but unfortunately Rust does not currently provide us with all the guarantees we need to write safe crypto code (for example, timing guarantees). We hope this will change fairly soon, though, so we can port all the underlying crypto to Rust.
Feature completeness. There is no reason to preserve only ECDH-based cipher suites, for example.
TLS 1.0 support.
What do you need TLS 1.0 support for?
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.
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.
Replying to myself: TLS 1.0 is now officially deprecated.
As soon as it becomes popular, it will be backdoored for sure.
The last sev:hi OpenSSL vulnerability was an X.509 null pointer read, crash-only, just in case you're calibrating expectations.
Do they usually give 3 days lead time? That's what gets my attention here.
Yes, all HIGH severity vulnerabilities (even MODERATE) have lead time.
e.g. see https://mta.openssl.org/pipermail/openssl-announce/2021-Febr...
e.g. see https://mta.openssl.org/pipermail/openssl-announce/2021-Febr...
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.
On the other hand, it gives people that found the vulnerability independently a bit of extra time to exploit.
> 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.
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.
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.
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
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.
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
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.
* A TLS client using session resumption may cause a use-after-free.
Looking forward to the day that Evercrypt[1] becomes a production-ready replacement for libcrypto.
[1] https://hacl-star.github.io/HaclValeEverCrypt.html
[1] https://hacl-star.github.io/HaclValeEverCrypt.html
Not that there's much to read here, but here's an archive link
https://web.archive.org/web/20210322203019/https://mta.opens...
https://web.archive.org/web/20210322203019/https://mta.opens...
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?
> 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/
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
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/search?keywords=debian-goodies
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/
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
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/search?keywords=debian-goodies
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/ In general you should be following this list if you're managing production services running debian or ubuntu.
Maintain a constant state of suspicious alertness until March 25th.
Restart your services or better reboot your server to be sure.
Will it also be a vulnerability in boringssl and libressl? only speculations
I often ask myself how long these things are exploited in the wild before they get revealed.
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.
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.
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.
> 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 suppose the flip side of this view is just how easy it is to underestimate what a truly enormous amount of work it would take to completely reimplement all these 'chainsaw juggling feats' that are used all over the place, day in and day out.
I suppose the flip side of this view is just how easy it is to underestimate what a truly enormous amount of work it would take to completely reimplement all these 'chainsaw juggling feats' that are used all over the place, day in and day out.
This is why we need simple systems above all. That also means having protocols and in general technologies that are as simple as possible while of course being useful. Especially in basic infrastructure, the cost of every new feature should be evaluated as a priority. The cost of bugs also should be considered. Libraries the world basically depends on should be an example how to do these things right.
The reality is, we see constant stream of patches to bugs we know for certain are security related to basically any software we use all the time. Am I the only one to think every such patch should be delivered with sweat running down our backs asking ourself how this could have happened at all in such critical software? Instead we introduce regular patch days, responsible disclosure and other protocols that don't solve the issue itself, that basically our software stacks are not maintainable at all if we are being frank.
In my opinion, we will have no dependable security until a handful of skilled engineers are together able to understand the systems we use fully. One can understand the more low level stuff, the other maybe the middle etc. with some reasonable overlaps so the security of the stack as a whole can be reasonable evaluated and maintained. This is currently just not realistic with any team size, when even the firmware of our CPUs has to be patched constantly. I mean, when you launch e.g. Gmail, who really understands everything from the JavaScript until basically the lowest level firmware in a clients computer? I guess, nobody and not even any team on the planet comes even close to grasping the full depth and breadth of the stack. Therefore the security and other quality related aspects cannot be evaluated without broad oversimplification that really doesn't add anything to the discussion.
If we don't wont to really change our ways, we should at least be frank and say that the software we actually use will never be fully secure, correct or dependable. Just as much as bridges fall, dams break and fallen power-lines create widespread fires we are just not able to handle this stuff reliably. If that is not scary enough, just imagine the software and other infrastructure handling security at nuclear power plants, processing centres and weapons. (And no, engineers are not the only ones having no clue. Doctors, medics etc. don't have a clue either as we see with the pandemic, still unsolved diseases everywhere, even stuff like hearing loss from stress is not understood well.)
The reality is, we see constant stream of patches to bugs we know for certain are security related to basically any software we use all the time. Am I the only one to think every such patch should be delivered with sweat running down our backs asking ourself how this could have happened at all in such critical software? Instead we introduce regular patch days, responsible disclosure and other protocols that don't solve the issue itself, that basically our software stacks are not maintainable at all if we are being frank.
In my opinion, we will have no dependable security until a handful of skilled engineers are together able to understand the systems we use fully. One can understand the more low level stuff, the other maybe the middle etc. with some reasonable overlaps so the security of the stack as a whole can be reasonable evaluated and maintained. This is currently just not realistic with any team size, when even the firmware of our CPUs has to be patched constantly. I mean, when you launch e.g. Gmail, who really understands everything from the JavaScript until basically the lowest level firmware in a clients computer? I guess, nobody and not even any team on the planet comes even close to grasping the full depth and breadth of the stack. Therefore the security and other quality related aspects cannot be evaluated without broad oversimplification that really doesn't add anything to the discussion.
If we don't wont to really change our ways, we should at least be frank and say that the software we actually use will never be fully secure, correct or dependable. Just as much as bridges fall, dams break and fallen power-lines create widespread fires we are just not able to handle this stuff reliably. If that is not scary enough, just imagine the software and other infrastructure handling security at nuclear power plants, processing centres and weapons. (And no, engineers are not the only ones having no clue. Doctors, medics etc. don't have a clue either as we see with the pandemic, still unsolved diseases everywhere, even stuff like hearing loss from stress is not understood well.)
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.
While this is a true statement, it doesn't feel accurate. Rust's type system offers a significant number of features over that of C beyond just memory safety. These come in the form of safe unions (with Rust enums), Generics with ZeroSizedTypes for ensuring states of computation happen in the proper order, safe destructuring of values such that the wrong field isn't referenced.
Point being, a Rust library that incorporates these type of safety measures can help significantly reduce programming errors beyond just memory safety issues.
Point being, a Rust library that incorporates these type of safety measures can help significantly reduce programming errors beyond just memory safety issues.
Memory errors and the sort of logic errors you described are one source of program errors, but I think the more devious ones are much higher level. There's a general taboo surrounding rolling your own crypto for a reason -- there are too many high level footguns that have nothing to do with raw program logic that can make a crypto system insecure or vulnerable to some kind of exploit, not necessarily relating to the code at all! Problems in randomness, distribution, other things beyond my pay grade.
Rust being higher level will prevent errors, yes, but crypto is hard on a whole other level. It's worth "waiting and seeing" what sort of vuln this is before jumping all in on the rust train this time ;-)
Rust being higher level will prevent errors, yes, but crypto is hard on a whole other level. It's worth "waiting and seeing" what sort of vuln this is before jumping all in on the rust train this time ;-)
If you're looking for me to argue with you that C is an acceptable substitute for languages like Rust and Go, you're barking up the wrong tree. It's not. But that doesn't mean we can simply bucket every vulnerability in a memory-unsafe program as a casualty of memory-unsafety, especially in programs like OpenSSL, which host a large domain of other vulnerabilities that are equally present in Rust and Go code.
Not looking for an argument, just trying to incorporate some more perspective.
Cryptography might be the one single place where I'd look askance at replacing memory-unsafe code with memory-safe de novo implementations. Fortunately, you mostly don't have that dilemma; there are good options in Go and Rust. But a lot of energy goes into auditing the cryptography code in OpenSSL. Certainly, you might reasonably pick OpenSSL over some random high-level implementation nobody is auditing.
That's why I think it's worth calling this out.
Odds are, it's some dumb memory corruption thing. But we don't know yet. OpenSSL sev:hi tends to mean "dubiously exploitable crasher", and good crypto bugs in OpenSSL tend to be sev:med.
That's why I think it's worth calling this out.
Odds are, it's some dumb memory corruption thing. But we don't know yet. OpenSSL sev:hi tends to mean "dubiously exploitable crasher", and good crypto bugs in OpenSSL tend to be sev:med.
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.
Such as?
The Rust type system can define parts of the state machine that can help guarantee certain states are true at compile time.
This is very helpful for not using cryptography libraries incorrectly, or not accidentally using the wrong data at different points of implementing functions.
Generally more applicable to higher level use cases, the ring[1] library is a great example of how the algorithms (same impls as OpenSSL) are exposed to end users.
[1]: https://github.com/briansmith/ring
This is very helpful for not using cryptography libraries incorrectly, or not accidentally using the wrong data at different points of implementing functions.
Generally more applicable to higher level use cases, the ring[1] library is a great example of how the algorithms (same impls as OpenSSL) are exposed to end users.
[1]: https://github.com/briansmith/ring
I like Ring but I don't think there's a lot of evidence that Rust's type system has effectively prevented cryptography errors, either in protocol state machines or in primitive implementations.
The challenge in avoiding cryptography mistakes is that you have to understand the errors before you can avoid them. Short of formal analysis with provers, I don't think there's a level of programming rigor that gets you away from most (maybe any?) of the last 10-15 years of (say) {TLS,JWT} bugs.
The challenge in avoiding cryptography mistakes is that you have to understand the errors before you can avoid them. Short of formal analysis with provers, I don't think there's a level of programming rigor that gets you away from most (maybe any?) of the last 10-15 years of (say) {TLS,JWT} bugs.
I look forward to discussing that on the 25th when we have more information.
Evidence of this nature will always be difficult, though, since it’s very difficult to prove a negative. We can only prove that some specific issue hasn’t yet occurred.
Evidence of this nature will always be difficult, though, since it’s very difficult to prove a negative. We can only prove that some specific issue hasn’t yet occurred.
Match statement exhaustiveness checking is one example, especially combined with the pervasiveness of enums (instead of constants).
Any respectable C compiler does this.
Like the one OpenSSL is being compiled with?
What C compiler has pattern matching and ADTs?
Every C compiler these days will warn about unchecked enums in switch statements. This is, effectively, what the comment was saying.
Pattern matching has nothing to do with security or program safety.
Pattern matching has nothing to do with security or program safety.
From what I remember, you can't write a secure cryptography library in pure Rust because it has no guarantees that would stop timing-based vulnerabilities.
Neither does C. Timing is not considered "observable behavior" in the C standard, so compilers don't have to preserve it.
It looks like at least libsodium implements constant-time array comparison in C.
https://github.com/jedisct1/libsodium/blob/ae4add868124a32d4...
Edit: I'm not disagreeing that C compilers are free to optimize stuff like this out; this comment is for people who (like me) thought that serious projects always used assembly for constant time operations.
https://github.com/jedisct1/libsodium/blob/ae4add868124a32d4...
Edit: I'm not disagreeing that C compilers are free to optimize stuff like this out; this comment is for people who (like me) thought that serious projects always used assembly for constant time operations.
And indeed the XOR method is also how it's implemented in Rust.
https://docs.rs/subtle/2.4.0/src/subtle/lib.rs.html#226-244 - the impl for [u8], where the per-element ct_eq is
https://docs.rs/subtle/2.4.0/src/subtle/lib.rs.html#259-272 - the impl for u8
https://docs.rs/subtle/2.4.0/src/subtle/lib.rs.html#226-244 - the impl for [u8], where the per-element ct_eq is
https://docs.rs/subtle/2.4.0/src/subtle/lib.rs.html#259-272 - the impl for u8
Which is prime example as to how C does not consider timing to be observable behavior. What the code does is that it tries to specify the operation in sufficiently complex way that makes compiler give up on any optimizations.
Note how this problem of "sufficient complexity" is an asymmetric problem between code author and compiler. A rather simple transformation implemented by the author to make the code constant-time may require NP-hard effort for the compiler to undo.
(but then the compiler may still do other unrelated transformations that end up making the code non-constant time again)
(but then the compiler may still do other unrelated transformations that end up making the code non-constant time again)
There's nothing that guarantees that's constant-time. It's just written in a way that's likely to be constant-time, and observed to be constant-time with current compilers, but there's no reason why a specification-compliant compiler couldn't make it variable-time tomorrow.
You can do exactly the same in Rust. Rust isn't any help there, but it doesn't obstruct you either.
You can do exactly the same in Rust. Rust isn't any help there, but it doesn't obstruct you either.
We've had code in OpenSSL written in C that was constant time until a newer version of both gcc and clang recognized (mask & a | ~mask & b) as a conditional assign and could do things like turn it into a branch.
Edit: It can turn "b = foo(); c = (mask & a | ~mask & b)" into "if (mask) c = a; else c = foo();"
Edit: It can turn "b = foo(); c = (mask & a | ~mask & b)" into "if (mask) c = a; else c = foo();"
[deleted]
"what is essentially a portable assembly language" amen to that :)
>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
Do you imagine a future where nobody is able to drive cars? Not even for fun?
I want all serious software that's written in C to be replaced with something like Rust, but I write C for fun. It's fun to do dangerous things. It's just bad to have danger as the modus operandi.
Do you imagine a future where nobody is able to drive cars? Not even for fun?
I want all serious software that's written in C to be replaced with something like Rust, but I write C for fun. It's fun to do dangerous things. It's just bad to have danger as the modus operandi.
I like doing dangerous things for fun too. (See also: my 50 mph scooter.)
I think we should mitigate risk in serious software in many holistic ways such as formal verification, fuzzing, anomaly detection, good/defensive coding standards, code reviews, and so forth. Such can be accomplished in C, but it maybe easier in languages such as Rust. The advantage of C is ubiquitous portability, which is necessary for widely-used libraries.
I think we should mitigate risk in serious software in many holistic ways such as formal verification, fuzzing, anomaly detection, good/defensive coding standards, code reviews, and so forth. Such can be accomplished in C, but it maybe easier in languages such as Rust. The advantage of C is ubiquitous portability, which is necessary for widely-used libraries.
Sure, it’s important for a library to have C source code for portability. That doesn’t exclude implementing the code in another language (such as F*/FStar or Dafny) that has stronger out-of-the-box safety guarantees, then compiling it to portable C source code for distribution.
You're right there's a lot of tools out there to help with writing secure code in C. I suppose I feel safer knowing Rust enforces some memory safey, but that isn't guaranteed either -- you could just use unsafe{} blocks everywhere.
I don’t think many people begrudge people who ride horses for fun or write security software in assembly for fun.
so..`yholio` Rants asside what is your valuable contribution to the library or creating a new impecable one? I'm acutally glad we have such powerfull library available for free and using open source code so we can audit it and find bugs
> open source code so we can audit it and find bugs
Open source didn’t stop Heartbleed
Open source didn’t stop Heartbleed
It's swiss-army chainsaw juggling with a kitchen-sink of unnecessary features, bloat, and poor coding hygiene.
C isn't the problem per se, it's the lack of quality, formal rigor, and testing that these slap-dash developers foist on the world. It's a steaming pile, and people wonder why it has security vulnerabilities over and over again. It's doing the same damn thing and expecting a different result: C maybe part of it, but its developers just aren't that great.
C isn't the problem per se, it's the lack of quality, formal rigor, and testing that these slap-dash developers foist on the world. It's a steaming pile, and people wonder why it has security vulnerabilities over and over again. It's doing the same damn thing and expecting a different result: C maybe part of it, but its developers just aren't that great.
Can't wait for your PR!
As mentioned down-thread, LibreSSL patched a use-after-free just last week.
It's a fork of swiss-army chainsaw juggling with training wheels. It is a slowly-dying project because it's not keeping up and distros are dropping it. It's not a viable alternative.
And yet, it's managed to avoid many of the OpenSSL CVEs.
It's not a "viable alternative" because nobody cares enough to test their code against it.
It's not a "viable alternative" because nobody cares enough to test their code against it.
How else do you expect that national security agencies do their job? :^)
Go seems to have it's own SSL lib
https://groups.google.com/g/golang-nuts/c/0za-R3wVaeQ
https://groups.google.com/g/golang-nuts/c/0za-R3wVaeQ
I dont see why this is being downvoted, in context of the parent comment
> 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.
Ok. So I'm pointing out that Go actually doesn't do such a "silly" thing...
> 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.
Ok. So I'm pointing out that Go actually doesn't do such a "silly" thing...
We don't know what the vulnerability is yet. Sure it could be a buffer overflow, readily possible in a language like C, or could be a bug in the crypto/implementation itself, no memory safe language will save you there.
I just started wondering, if things were any better if security libraries were written in higher level languages, depending on on a huge run-time support system that is written in what is essentially a portable assembly language, doing silly things like pointer arithmetic, manually allocating memory and so on... :)
The problem is not the language! If C is not sufficiently safe for you, you shouldn't take planes, or drive cars, or rely on medical devices, because the software of all these critical embedded system is written in C.
The problem is on how you write the software. There are projects that have strict code standard, such as MISRA C or even stricter ones. The problem is that such a critical software (well, relatively critical, because if there is a bug in a security library nobody dies in the end) is not written to that standards.
The problem is on how you write the software. There are projects that have strict code standard, such as MISRA C or even stricter ones. The problem is that such a critical software (well, relatively critical, because if there is a bug in a security library nobody dies in the end) is not written to that standards.
> The problem is not the language!
It is. A language that lets you write unsafe code is an unsafe language.
> If C is not sufficiently safe for you, you shouldn't take planes, or drive cars, or rely on medical devices, because the software of all these critical embedded system is written in C.
Citation needed. I would expect those programs to be written on a language with very strict types and no pointer arithmetic bullshit, like Ada.
And even if some of these software pieces are written in C, (a) that's very bad, too, and (b) it may be more suitable for those scenarios. But a program that reads and parsers unlimited amounts of user input, supports an ever growing list of complex (and often improperly defined) protocols, and is edited/expanded/updated daily, is definitely not such a suitable scenario.
> The problem is on how you write the software. There are projects that have strict code standard, such as MISRA C or even stricter ones.
Again, the problem is the language, not how you use it. If the security of a piece depends on how it is manipulated, it is by default insecure. A secure language shouldn't let users make mistakes (or at least avoid them to a very high degree, both in compilation and run time). And a library that is the backbone of the confidentiality and privacy of millions of people (and billions of dollars in businesses) should be written on a secure language.
It is. A language that lets you write unsafe code is an unsafe language.
> If C is not sufficiently safe for you, you shouldn't take planes, or drive cars, or rely on medical devices, because the software of all these critical embedded system is written in C.
Citation needed. I would expect those programs to be written on a language with very strict types and no pointer arithmetic bullshit, like Ada.
And even if some of these software pieces are written in C, (a) that's very bad, too, and (b) it may be more suitable for those scenarios. But a program that reads and parsers unlimited amounts of user input, supports an ever growing list of complex (and often improperly defined) protocols, and is edited/expanded/updated daily, is definitely not such a suitable scenario.
> The problem is on how you write the software. There are projects that have strict code standard, such as MISRA C or even stricter ones.
Again, the problem is the language, not how you use it. If the security of a piece depends on how it is manipulated, it is by default insecure. A secure language shouldn't let users make mistakes (or at least avoid them to a very high degree, both in compilation and run time). And a library that is the backbone of the confidentiality and privacy of millions of people (and billions of dollars in businesses) should be written on a secure language.
> A language that lets you write unsafe code is an unsafe language.
Rust lets you write unsafe code, and as a matter of fact people are using unsafe abundantly.
Rust lets you write unsafe code, and as a matter of fact people are using unsafe abundantly.
Yes, and unsafe Rust is an unsafe language. It's easy enough to detect it's use in a project so that it can be considered a language on it's own.
Out of interest, when would you say a language at fault for a security problem?
Static analysis tools should also be a normal part of the development process regardless of the language being used. Unfortunately, the good tools cost money and that discourages developers (and managers) from using them.
> if there is a bug in a security library nobody dies in the end
The University Hospital Düsseldorf (UKD) in Germany suffered a ransomware attack on September 10, 2020. The attackers exploited a vulnerability in the Citrix ADC that had been known since January but the hospital, unfortunately, had not got around to implementing the fix.
Unfortunately, one patient with a life-threatening illness was diverted to a distant hospital after UKD was deregistered as an emergency care facility. The additional hour’s travel may have been the cause of the patient’s death. On September 18, 2020, German prosecutors launched an official negligent homicide investigation which, if confirmed, would make the patient’s death the first known case of death by hacking.
:|
The University Hospital Düsseldorf (UKD) in Germany suffered a ransomware attack on September 10, 2020. The attackers exploited a vulnerability in the Citrix ADC that had been known since January but the hospital, unfortunately, had not got around to implementing the fix.
Unfortunately, one patient with a life-threatening illness was diverted to a distant hospital after UKD was deregistered as an emergency care facility. The additional hour’s travel may have been the cause of the patient’s death. On September 18, 2020, German prosecutors launched an official negligent homicide investigation which, if confirmed, would make the patient’s death the first known case of death by hacking.
:|
Is Citrix ADC a security library?
It’s a network security appliance - undoubtedly contains multiple security libraries.
yes, the problem is not the language. The problem is that OpenSSL has just became so important that It shouldn't not rely on C language any more. We have so much better tools now.
Planes actually have major portions of the software written in non-C languages such as ADA - see https://www.manufacturing.net/aerospace/news/21175187/airbus...
And are very proud of it. Medical equipment is not all implemented in embedded C systems.
And since modern embedded systems can easily run python or embedded JS versions, well, perhaps certain critical libs can actually get implemented in something that does not deal with memory... and the 5-10% penalty in performance is not going to be something anyone really notes.
And are very proud of it. Medical equipment is not all implemented in embedded C systems.
And since modern embedded systems can easily run python or embedded JS versions, well, perhaps certain critical libs can actually get implemented in something that does not deal with memory... and the 5-10% penalty in performance is not going to be something anyone really notes.
Even safety critical software can run reliably for the range of inputs that it's likely to ever see, but contain security holes.
For something like OpenSSL, it must produce a correct output for every single possible input. Even safety critical software may extremely rarely fail in unusual conditions. For security sensitive software though, all it takes is a single possible input that will trigger a bug, because the attacker is not a random process.
Writing secure software in C is extremely difficult.
For something like OpenSSL, it must produce a correct output for every single possible input. Even safety critical software may extremely rarely fail in unusual conditions. For security sensitive software though, all it takes is a single possible input that will trigger a bug, because the attacker is not a random process.
Writing secure software in C is extremely difficult.
That's like having a field full of mines and then arguing that the field is not dangerous because you have a map of the mines. If you have to develop strict coding standards not just to write reliable code but to avoid the pitfalls of a language that others don't have, then that proves that the language sucks.
We have languages that can provide certain levels of MISRA safety even if you are a novice programmer.Blaming the users for not following the correct guidelines (that barely anyone follows except for the people paid to follow them) completely misses the point.
We have languages that can provide certain levels of MISRA safety even if you are a novice programmer.Blaming the users for not following the correct guidelines (that barely anyone follows except for the people paid to follow them) completely misses the point.
As one of the OpenSSL maintainers, I would like to move away from C and probably to rust. But the problem is that C is the most portable language, and rust's platform support just isn't close enough.
1. There is no such thing as a safe or unsafe language. Safety is relative and impossible to guarantee. Even "memory safety" often just means "memory tradeoffs".
2. Inline assembly is often a necessary evil to create implementations of crypto libraries in C... not using it would be worse.
3. It's all machine code under the covers. Whether one developer poorly juggles chainsaws or your high-level language poorly juggles chainsaws is not a question of better or worse, but taste.
4. It's X.509. It sucks in every language.
5. Just because it's in C doesn't mean it sucks. There are alternative libraries that intentionally avoid sucky design. (https://nacl.cr.yp.to/internals.html)
6. Show me another language that's as portable and powerful as C, and cryptographers will probably start using it.
2. Inline assembly is often a necessary evil to create implementations of crypto libraries in C... not using it would be worse.
3. It's all machine code under the covers. Whether one developer poorly juggles chainsaws or your high-level language poorly juggles chainsaws is not a question of better or worse, but taste.
4. It's X.509. It sucks in every language.
5. Just because it's in C doesn't mean it sucks. There are alternative libraries that intentionally avoid sucky design. (https://nacl.cr.yp.to/internals.html)
6. Show me another language that's as portable and powerful as C, and cryptographers will probably start using it.
Klwohu(1)
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.
For some reason, companies decided to put money into the known-bad openssl instead, as if money could fix a bad development culture.
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.
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
Discussion: https://github.com/void-linux/void-packages/issues/20935
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.
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.
“Patch Tuesday” is a Microsoft policy afaik, not a global one.
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.
Who wants to roll out any kind of update to their production systems on a Friday afternoon ? That’s just asking for trouble.
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.
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?
I think you have mismanaged your expectations.
you expect downtime as a normal matter of doing business?
you can do better, my friend. you are worth better.
you can do better, my friend. you are worth better.
Patch Tuesday is a Windows thing generally.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...