5 ms·
> Finding a genuine security flaw in OpenSSL is extraordinarily difficult. history suggests otherwise > The fact that 12 previously unknown vulnerabilities co
by blibble 8mo ago
> Finding a genuine security flaw in OpenSSL is extraordinarily difficult.
history suggests otherwise
> The fact that 12 previously unknown vulnerabilities could still be found there, including issues dating back to 1998, suggests that manual review faces significant limits, even in mature, heavily audited codebases.
no, the code is simply beyond horrible to read, not to mention diabolically bad
if you've never tried it, have a go, but bring plenty of eyebleach
- hnmullany2 8mo ago[dead]
- lumost 8mo agoIt really is just a collection of several dozen research grade implementations for algorithms + a small handful of load bearing algorithms for the entire internet. Surprisingly, OpenSSL isn't the only critical piece of internet architecture like this.
- ryandvm 8mo agoThe longer I develop software, the more I realize just how awful most software engineering it.
- dwattttt 8mo agoReferencing the classic https://xkcd.com/2030 https://xkcd.com/2030 "I don't quite know how to put this, but our entire field is bad at what we do, and if you rely on us everyone will die" "They say they've fixed it with something called <del>blockchain</del> AI" "Bury it in the desert. Wear gloves"
- doodlesdev 8mo agoHonestly, this is absurdly funny, but it makes me wonder whether we'll ever see Computer Science and Computer Engineering as seriously as other branches of STEM. I've been debating recently whether I should keep working in this field, after years of repeatedly seeing incompetence and complacency create disastrous effects in the real world. Oftentimes, I wonder if the world wouldn't be a bit better without the last 10 or 15 years of computer technology.
- dumpsterdiver 8mo ago> makes me wonder whether we'll ever see Computer Science and Computer Engineering as seriously as other branches of STEM It's about as serious as a heart attack at this point...
- vsgherzi 8mo agoThis is really something that’s making me quite fed up with industry. I’m looking towards embedded and firmware in hopes that the lower in the stack I go the more people care about these type of things out of business necessity. But even then I’m unsure I’ll find the rigor I’m looking for
- eloisius 8mo agoI’ve been thinking the same thing lately. It’s hard to tell if I’m just old and want everyone off my lawn, but I really feel like IT is a dead end lately. “Vintage” electronics are often nicer to use than modern equivalents. Like dials and buttons vs touch screens. Most of my electronics that have LCDs feel snappy and you sort of forget that you’re using them and just do what you were trying to do. I’m not necessarily a Luddite. I know tech _could_ be better theoretically but it’s distressing to know that it’s also not possible for things to be different for some other reasons. Economically, culturally? I don’t know.
- spease 8mo ago“…just think, Wally, everything that makes this thing go was supplied by the lowest bidder.” - astronaut
- bsimpson 8mo agoThere was an article on here 15ish years ago to the effect of "everything's broken all the time. Everyone who writes software knows it, yet we all tolerate it." I'd love to find that sometime. Maybe it's time to ask Gemini once again to look for me.
- gostsamo 8mo agoIs this what you are looking for? https://www.stilldrinking.org/programming-sucks https://www.stilldrinking.org/programming-sucks
- bsimpson 8mo agoGoogle guessed this one: https://medium.com/message/everything-is-broken-81e5f33a24e1 https://medium.com/message/everything-is-broken-81e5f33a24e1 With yours as candidate #2. It's too late here now for me to read them both, but I'll try to go back and check when I have time.
- Quarrelsome 8mo agomaybe this is what blindsides most developers into disregarding the threat of AI to their jobs. We work off some idealised version of what the industry actually is which we presume AI will fail at, instead of the reality. I remain surprised at how long people can flog horses I figured would be dead decades earlier in enterprise. Too scared to fix fundamental issues and still running off the fumes of vendor lock-in with exasperated end users.
- devsda 8mo agoConverse is also possible ? Even with all the best practices, patterns and reviews in place software products often turns out to be held up by hacks and patches. Add AI and inexperienced developers into the mix, the risk of fragile software increases ?
- Quarrelsome 8mo agoI worry that software and the industry is more resistent then we might imagine. Consider the insanity of Elon Musk's arbitrary cuts to twitter and the resilience of that platform in the years that followed. It might simply be the case that buying more tokens and kicking the code enough times might give a "good enough" result for the industry to continue. I don't want to believe this but the discussion of how awful the openssl code base is seems to suggest that might be the case. You just need to automate the process of caution we have around it. We should all be hoping that Gastown fails but I feel like it might succeed.
- bulbar 8mo agoThis case study makes me even think that AI will turn out to be a net positive for overall code quality.
- thaumasiotes 8mo ago> Consider the insanity of Elon Musk's arbitrary cuts to twitter and the resilience of that platform in the years that followed. Given the resilience, how can the cuts have been "insanity"?
- vlovich123 8mo agoIs it still a critical piece? I thought most everyone migrated to libressl or boringssl after the heartbleed fiasco and serious people took a look at OpenSSL and started to understand the horror show that is the codebase and also development practices that clearly have not gotten better, if not gotten even worse.
- timschmidt 8mo agoThe badness cannot be overstated. "Hostile codebase" would be an appropriate label. Much more information available in Giovani Bechis's presentation: https://www.slideshare.net/slideshow/libressl/42162879 https://www.slideshare.net/slideshow/libressl/42162879 If someone meant to engineer a codebase to hide subtle bugs which might be remotely exploitable, leak state, behave unexpectedly at runtime, or all of the above, the code would look like this.
- rakel_rakel 8mo agoAnother great example from tedunangst's excellent presentation "LibreSSL more than 30 days later". https://youtu.be/WFMYeMNCcSY&t=1024 https://youtu.be/WFMYeMNCcSY&t=1024 Teaser: "It's like throw a rock, you're gonna hit something... I pointed people in the wrong direction, and they still found a bug".
- Swizec 8mo ago> If someone meant to engineer a codebase to hide subtle bugs which might be remotely exploitable, leak state, behave unexpectedly at runtime, or all of the above, the code would look like this. I wonder who could possibly be incentivized to make the cryptography package used by most of the worlds computers and communications networks full of subtly exploitable hard to find bugs. Surely everyone would want such a key piece of technology to be air tight and easy to debug But also: surely a technology developed in a highly adversarial environment would be easy to maintain and keep understandable. You definitely would have no reason to play whackamole with random stuff as it arises
- spease 8mo ago> Surely everyone would want such a key piece of technology to be air tight and easy to debug 1. Tragedy of the Commons (https://en.wikipedia.org/wiki/Tragedy_of_the_commons https://en.wikipedia.org/wiki/Tragedy_of_the_commons) / Bystander Effect (https://en.wikipedia.org/wiki/Bystander_effect https://en.wikipedia.org/wiki/Bystander_effect) 2. In practice, the risk of introducing a breakage probably makes upstream averse to refactoring for aesthetics alone; you’d need to prove that there’s a functional bug. But of course, you’re less likely to notice a functional bug if the aesthetic is so bad you can’t follow the code. And when people need a new feature, that will get shoehorned in while changing as little code as possible, because nobody fully understands why everything is there. Especially when execution speed is a potential attack vector. So maybe shades of the trolley problem too - people would rather passively let multiple bugs exist, than be actively responsible for introducing one.
- lovich 8mo agoI can read C/C++ code about as well as I can read German. Bits and pieces make sense but I definitely don’t get the subtleties. What’s eye bleachy about this beyond regular C/C++? For context I’m fluent in C#/javascript/ruby and generally understand structs and pointers although not confident in writing performant code with them.
- jeffbee 8mo agoFor one thing, "C/C++" is not a thing. If you see C-like C++, that is C. Part of OpenSSL's incomprehensibility is that it is not C++ and therefore lacks automatic memory management. Because it doesn't have built-in allocation and initialization, it is filled with BLAH_grunk_new and QVQ_hurrr_init. "new" and "init" semantics vary between modules because it's all ad hoc. Sometimes callees deallocate their arguments. The only reason it needs module prefixes like BLAH and QVQ and DERP is that again it is not C++ and lacks namespaces. To readers, this is just visual noise. Sometimes a function has the same name with a different module, and compatible function signature, so it's possible to accidentally call the wrong one.
- rzerowan 8mo agoAlso werent a lot of deadend code removed and vulns patched into what would become LibreSSL. Would be interesting to see if any of those found exist there.
- assanineass 8mo ago[dead]
- cryptonector 8mo ago> history suggests otherwise The methodology for developing and maintaining codebases like OpenSSL has changed! > no, the code is simply beyond horrible to read, not to mention diabolically bad OpenSSL? Parts of it definitely are, yes. It's better since they re-styled it. The old SSLeay code was truly truly awful.
- nextaccountic 8mo agoWhy do people use OpenSSL? Or any other library that forked from it Why not start from a clean slate? Companies like Google could afford it
- sharms 8mo agoAWS actually has two libraries they use instead: s2n and aws-lc https://github.com/aws/s2n-tls https://github.com/aws/s2n-tls https://github.com/aws/aws-lc https://github.com/aws/aws-lc
- josefx 8mo agoSecurity certifications are one reason. OpenSSL maintains a module for FIPS compliance, which includes an entire boatload of weak and broken algorithms nobody else bothers with.
- nextaccountic 8mo agoThis kind of security certification seems like the exact opposite of actual security
- PunchyHamster 8mo agoIt is. There are other related issues like at some point RedHat patched back options removed/changed in openSSH 7.0 because * they upgraded a major release (6.x to 7.x) in "stable" channel of their distro * their customers ran some ancient stuff that required those options. We've failed a security audit because our checks just compared OpenSSH version ("if version is above this it doesn't need any change in config") while Red Hat's OpenSSH version was downgraded to earlier version settings/security issues
- lmm 8mo agoBecause as horrible as the OpenSSL code is, the best available clean implementation would mean using a language that's weird and French.
- 8mo ago
- fulafel 8mo agoWe don't know how to secure C codebases by manual review. It's been well known to security engineering people for decades. And has been wider industry and academic consensus for a long time. It's like "is man-made climate change real". (We don't know how to secure other codebases either, but C is harder since its memory safety story is like a chainsaw juggling act so code has classes of vulnerabilities that other languages don't and this eats a lot of the attention).
- snvzz 8mo agoInstead of everybody switching to LibreSSL, we had the Linux Foundation reward OpenSSL's incompetence with funding. We are still suffering from that mistake, and LibreSSL is well-maintained and easier to migrate to than it ever was. What the hell are we waiting for? Is nobody at Debian, Fedora or Ubuntu able to step forward and set the direction?