4 ms·

Seems OpenSSL as an organization is just irreparably broken if they haven't still learned the lesson

by adql 4y ago

Someone1234 4y ago
OpenSSL still receives minimum funding. Until Heartbleed they had nearly no funding, and now it is two full time people. https://en.wikipedia.org/wiki/Core_Infrastructure_Initiativev https://en.wikipedia.org/wiki/Core_Infrastructure_Initiative...
- pizza234 4y ago
  I'm of the opinion that in cases like this, it'd be better for the organization to close, and allow the gap to be filled naturaly. If the current OpenSSL maintainers closed the project, given its importance, there would be a rush to follow up maintenance. Chances are, it'd be better funded; even in worst case, it'll hardly be assigned less than two devs. This a case of the general dynamic where a barely-sufficient-but-arguably-insufficient solution prevents actors from finding and executing a proper one.
  - AdamJacobMuller 4y ago
    You don't even have to close. You can just refuse to merge code which does not include 100% test coverage. If someone wants the feature badly enough, they will figure out a way to fill the gap. Alternatively, someone can always fork the code and release "OpenSSL-but-with-lots-of-untested-code" variant.
  - SoftTalker 4y ago
    For a project like OpenSSL, it's not just having "enough" developers (whatever that is) it's having qualified developers. Writing good crypto code requires deep expertise. There aren't a lot of people with such expertise whose time is not already fully committed.
coder543 4y ago
I think at this point we've established that it's C which is just irreparably broken. Blaming the OpenSSL developers for writing bad C is just a "no true scotsman" at this point, since there is no large, popular C codebase in existence that I'm aware of that avoids running into vulnerabilities like this; vulnerabilities that just about every other language (mainly excluding C++) would have prevented from becoming an RCE, and likely prevented from even being a DoS. Memory safe languages obviously can't prevent all vulnerabilities, since the developer can still intentionally or unintentionally write code that simply does the wrong thing, but memory safe languages can prevent a lot of dumb vulnerabilities, including this one. No feasible amount of funding would have prevented this, since it continues to happen to much better funded projects also written in C. On the other hand, I guess we could blame the OpenSSL developers for writing C at all, being unwilling to start writing new code in a memory safe language of some kind, and ideally rewriting particularly risks code paths like parsers as well. We've learned this lesson the hard way a thousand times. C isn't going away any time soon (unfortunately), but that doesn't mean we have to continue writing new vulnerabilities like this one, which was written in the last two years.
- jabart 4y ago
  Keep in mind that Ubuntu compiled OpenSSL using a gcc flag that turns this one byte overflow into a crash instead of a memory leak/corrpution because it has a way to do that already. It's very risky, and a very long term project to rewrite something with this level of history into a completely new language.
  - coder543 4y ago
    > It's very risky, and a very long term project to rewrite something with this level of history into a completely new language. I didn't suggest a complete rewrite of the project. However, they could choose to only write new code in something else, and they could rewrite certain critical paths too. The bulk of the code would continue to be a liability written in C. I agree that it would be nearly impossible to rewrite OpenSSL as-is. It would take huge amounts of funding and time. In general, people with that much funding are probably better off starting from scratch and focusing on only the most commonly used functionality, as well as designing the public interface to be more ergonomic / harder to misuse.
cryptonector 4y ago
The OpenSSL team is actually very good and they do very good work, and they even have funding. The problem is that legacy never goes away, and OpenSSL is a huge pile of legacy code, and it will take a long long time to a) fix all the issues (e.g., code coverage), b) migrate OpenSSL to not-C or the industry to not-OpenSSL.
- cjbprime 4y ago
  This vulnerable parser of attacker-controlled remote input was written from scratch in C in 2020, without a fuzz harness even though OpenSSL is critical infrastructure and is already hooked up to oss-fuzz. It is simply difficult to reconcile these facts with the idea that it is a very good team doing very good work.

Seems OpenSSL as an organization is just irreparably broken if they haven't still learned the lesson

by adql 4y ago

Seems OpenSSL as an organization is just irreparably broken if they haven't still learned the lesson

OpenSSL still receives minimum funding. Until Heartbleed they had nearly no funding, and now it is two full time people. https://en.wikipedia.org/wiki/Core_Infrastructure_Initiativev https://en.wikipedia.org/wiki/Core_Infrastructure_Initiative...

pizza234 4y ago
I'm of the opinion that in cases like this, it'd be better for the organization to close, and allow the gap to be filled naturaly. If the current OpenSSL maintainers closed the project, given its importance, there would be a rush to follow up maintenance. Chances are, it'd be better funded; even in worst case, it'll hardly be assigned less than two devs. This a case of the general dynamic where a barely-sufficient-but-arguably-insufficient solution prevents actors from finding and executing a proper one.
- AdamJacobMuller 4y ago
  You don't even have to close. You can just refuse to merge code which does not include 100% test coverage. If someone wants the feature badly enough, they will figure out a way to fill the gap. Alternatively, someone can always fork the code and release "OpenSSL-but-with-lots-of-untested-code" variant.
- SoftTalker 4y ago
  For a project like OpenSSL, it's not just having "enough" developers (whatever that is) it's having qualified developers. Writing good crypto code requires deep expertise. There aren't a lot of people with such expertise whose time is not already fully committed.

coder543 4y ago

I think at this point we've established that it's C which is just irreparably broken. Blaming the OpenSSL developers for writing bad C is just a "no true scotsman" at this point, since there is no large, popular C codebase in existence that I'm aware of that avoids running into vulnerabilities like this; vulnerabilities that just about every other language (mainly excluding C++) would have prevented from becoming an RCE, and likely prevented from even being a DoS. Memory safe languages obviously can't prevent all vulnerabilities, since the developer can still intentionally or unintentionally write code that simply does the wrong thing, but memory safe languages can prevent a lot of dumb vulnerabilities, including this one. No feasible amount of funding would have prevented this, since it continues to happen to much better funded projects also written in C. On the other hand, I guess we could blame the OpenSSL developers for writing C at all, being unwilling to start writing new code in a memory safe language of some kind, and ideally rewriting particularly risks code paths like parsers as well. We've learned this lesson the hard way a thousand times. C isn't going away any time soon (unfortunately), but that doesn't mean we have to continue writing new vulnerabilities like this one, which was written in the last two years.

jabart 4y ago
Keep in mind that Ubuntu compiled OpenSSL using a gcc flag that turns this one byte overflow into a crash instead of a memory leak/corrpution because it has a way to do that already. It's very risky, and a very long term project to rewrite something with this level of history into a completely new language.
- coder543 4y ago
  > It's very risky, and a very long term project to rewrite something with this level of history into a completely new language. I didn't suggest a complete rewrite of the project. However, they could choose to only write new code in something else, and they could rewrite certain critical paths too. The bulk of the code would continue to be a liability written in C. I agree that it would be nearly impossible to rewrite OpenSSL as-is. It would take huge amounts of funding and time. In general, people with that much funding are probably better off starting from scratch and focusing on only the most commonly used functionality, as well as designing the public interface to be more ergonomic / harder to misuse.

cryptonector 4y ago

The OpenSSL team is actually very good and they do very good work, and they even have funding. The problem is that legacy never goes away, and OpenSSL is a huge pile of legacy code, and it will take a long long time to a) fix all the issues (e.g., code coverage), b) migrate OpenSSL to not-C or the industry to not-OpenSSL.

cjbprime 4y ago
This vulnerable parser of attacker-controlled remote input was written from scratch in C in 2020, without a fuzz harness even though OpenSSL is critical infrastructure and is already hooked up to oss-fuzz. It is simply difficult to reconcile these facts with the idea that it is a very good team doing very good work.