Slashdot Mirror
2014: The Year We Learned How Vulnerable Third-Party Code Libraries Are
jfruh writes Heartbleed, Shellshock, Poodle — all high-profile vulnerabilities in widely used libraries that rocked the software industry in 2014. Sadly, experts are now beginning to believe that these aren't the only bugs lurking out there in widely used open source code, just the ones that grabbed the most attention. It's beginning to look like one of the foundation concepts of open source — that with enough eyes, all bugs are shallow — is a myth. Of course, probably no one believes that all bugs are instantly shallow, no matter how open is the source, or that open source software is immune from bugs -- particularly ESR, coiner of the phrase.
My magic 8 ball tells me that in 2015 we will learn that proprietary and embedded software is even more vulnerable. My Tarot Card deck tell me that we will see a lot of hacked car wrecks in 2015, now that Volvo released the demon by putting a web browser into in-dash system. Rest of the lemmings are sure to follow. Not that you really need a browser to pwn a car, with Bluetooth-to-CAN-BUS exploits shutting down cars demonstrated as early as 2012.
Amen.
I touched OpenSSL once. It was a nightmare. No idea where or how it passed anything as it wasn't at all clear the path that simple things, like certificate checking, were supposed to take.
In the end, I hacked onto it rather than play with it. The documentation was non-existent. The code samples were incomplete and with almost zero explanation of what you were supposed to be checking for and where things COULD go wrong. Hence 90% of the code I see that touches OpenSSL looks exactly like the samples and nothing more.
All I wanted to do was have two x509 certificates, and check that both were valid and one properly signed the other, as part of a primitive DRM scheme I was toying with. It turned into a nightmare scenario of IMAGINING every possible outcome and specifically coding for each one, rather than anything sensible.
I don't think I'd ever touch it again, and was not at all surprised that there were problems with it. I was more surprised that others had had the same problems, yet OpenSSL was still regarded as the "gold standard" library to integrate with.
So all we need are 11 more sets of programmers to program free version of SSL 2-12?
There is one workaround for this. If it's a security bug, public disclosure with a working demonstration/exploit on the right boards will get their attention awful damned fast, and you'll know when a fix is posted.
Funny part is, usually it still takes (relatively) longer for the proprietary shop to come up with a workaround/fix than it does a given OSS community.
Quo usque tandem abutere, Nimbus, patientia nostra?
"once" = several weeks of fighting with the damn thing to do one simple task, clearly specified, that's way within it's scope.
There is no serious documentation. The examples are given as documentation and are vastly incomplete.
It's not a question of "glanced at it, it was horrible", but for anything serious even a quick glance will show whether or not it's a nicely-produced library or not. One quick glance at a library is normally all I do in order to get a handle on whether it's good enough and clean enough for me to program against.
The problem with OpenSSL was that the only people who knew how it worked never bothered to simplify that or document that enough. There is no "is this certificate valid" function, that returns a enum from a list of potential problems (CERT_EXPIRED, CERT_NOT_YET_VALID, CERT_CORRUPT, CERT_UNTRUSTED, CERT_INSECURE, etc.), for instance. There are lots of things that LOOK like that, but none actually do it in OpenSSL.
Given that it's a library who's primary purpose is - given a configuration of particular algorithms and keys - to produce a encrypted bitstream from an unencrypted one (or vice versa), it's suprisingly complex to do anything simple with any guarantee that you're doing it right.