OpenSSL Rampage

In case your cvs-fu is rusty FreshBSD[1] or OpenSSL Rampage[2] provide an easy way of keeping an eye on the changes. One of my favorites so far is: "Remove hacky workaround for Cray T3E," as in the debuted in 1995, Cray Research T3E.[3] -/* Added for T3E, address-of fails on bit field ([email protected]) */ -#ifndef BIT_FIELD_LIMITS memcpy(&server.sin_addr.s_addr, ip, 4); -#else - memcpy(&server.sin_addr, ip, 4); -#endif [^1]: http://freshbsd.org/search?project=openbsd&q=project%3Aopenbsd+lib… [^2]: http://opensslrampage.org/ [^3]: http://freshbsd.org/commit/openbsd/01f41ed5b37037b963c0de2c25a84f35390… [^3]: https://en.wikipedia.org/wiki/Cray_T3E

The OpenSSL Valhalla Rampage. It was kind of amusing, though horrifying with what they found. https://opensslrampage.org/

Read this (from older to newer posts) https://opensslrampage.org/ it explains a lot of the bad stuff on OpenSSL Example: "“Do you really want to build OpenSSL for 16-bit Windows? Well, we don’t.”" https://opensslrampage.org/post/83952304402/do-you-really-want-to-buil…

banter and patches from OpenBSD here: https://opensslrampage.org/

Luckily I moved everything to openbsd's libressl which is /mostly/ compatible. I wonder if this bug affects them, typically the HIGH's haven't[0] It really feels like every other week there is a bug in OpenSSL and after following along with the libressl blog I understand why- the code is an absolute mess[1] [0] http://undeadly.org/cgi?action=article&sid=20150319145126 [1] http://opensslrampage.org/page/49

Reminds me of one of my favorite commit logs from the LibreSSL project: "Do not feed RSA private key information to the random subsystem as entropy. It might be fed to a pluggable random subsystem…. What were they thinking?!" http://opensslrampage.org/post/83007010531/well-even-if-time-isnt-rand…

I'm still a little bitter http://opensslrampage.org/ stopped updating, it was always good for a chuckle

"demonstrably safe" -- this is another issue I have with this crypto conservative FUD. "Use SSL, don't roll your own!" Then we get BEAST, CRIME, Heartbleed, etc., and we discover that the dominant SSL/TLS implementation is a rat's nest of comically awful code: http://opensslrampage.org Look at the older posts for LuLz like: http://opensslrampage.org/post/83007010531/well-even-if-time-isnt-rand… I wonder just how much scrutiny IPSec implementations have gotten, especially since it's such a usability nightmare that nobody uses it.

> What does binary size have to do with quality? Do OS/2, 16 bit Windows, and Data General Unix support indicate quality to you? http://opensslrampage.org/

And if you want to watch the carnage, the highlights are at http://opensslrampage.org/ .

It's cool they're doing this cleanup, but overly self-righteous commit messages (http://opensslrampage.org/) on patches like http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/crypto/asn1/a… rub me the wrong way (I'm sure comparing a string pointer to '5' / decimal 53 is _exactly_ what the old, ridiculed code meant to do…)

Looks like significant amount of non-stylistic changes too: http://opensslrampage.org/

As feld, clarry, danrik, etc. have pointed out, having a consistent coding style makes identifying bugs much easier. "regardless of the practical value of creating single solutions that work everywhere" Since these are the same folks who do OpenSSH, I would imagine after the initial work is done, it will probably evolve to be as portable as OpenSSH and the other OpenBSD projects. Also, they are doing many bug fixes as shown on http://opensslrampage.org

Some of it: todo: do not leave 15 year old todo lists in the tree. This code is the reason perl has a name as a write only language. Remove oh-so-important-from-a-security-pov OpenSSL_rtdsc() function. Do not feed RSA private key information to the random subsystem as entropy. It might be fed to a pluggable random subsystem.... What were they thinking?! <RANT> Whoever thought that RAND_screen(), feeding the PRNG with the contents of the local workstation's display, under Win32, was a smart idea, ought to be banned from security programming. </RANT> Edit: just noticed, there's a BLOG with it.. http://opensslrampage.org/

>as we saw with Heartbleed, the "many eyes" theory is flawed as well. I don't think Heartbleed counts as some sort of evidence against the "many eyes" paradigm. There are so many better bugs for that, as Heartbleed is really low hanging fruit. OpenSSL is a total nightmare. I've posted elsewhere about this at length - but in short OpenSSL is really an example of what a good program _shouldn't_ do. How a good program _shouldn't_ be written. There is a list of sins a mile long on http://opensslrampage.org/. The truth is that there is no guarantee that Windows, Linux, or BSD are not backdoored by the NSA, GCHQ, or FSB. There's no guarantee you didn't get owned and Chuck Blackhat installed a backdoor on your computer. The real reason to use OpenBSD is because it's had less remote exploits in the past 15 years than Windows has had in the past year. The real reason to use Linux and BSD is because that software respects your freedom. If you don't care about things like software freedom or if you feel the security of Windows is "good enough" for what you're doing then of course you don't care about Linux and BSD.

Ironically, I've been having the other side of this argument over on Diaspora: https://joindiaspora.com/posts/3918657 No, open source is not, in and of itself, sufficient. I do believe increasingly, however, that it is necessary. But so are other attributes: a healthy development culture, an approach which preemptively seeks out and eliminates security threats and holes, and most importantly, operates with the end-user as a primary focus. Projects with a strong record of this include OpenBSD (which is now conducting a focused effort to clean up the OpenSSL code: http://opensslrampage.org/) and the Debian project (with formal social contract, constitution, and policy all of which put the interests of the end-user front and center). While Debian's had its security snafus, particularly relative to OpenBSD, among Linux distros it's tended to be among the more secure and security-conscious distros, in my experience. But projects with a long track record of disdain also tend to show themselves for want of strong security: PHP, awstats, GNOME, and more recently, systemd, all come to mind. I have grave concerns over the damage the latter is now in a position to do, and the fact that one dev has already been denied privileges to submit kernel patches by Linus Torvalds doesn't do much to increase my confidence.

Also: http://opensslrampage.org/

Ah, good point; at the very least things like zeroing out buffers upon deallocation would have helped. Yes, I was a fan of the commits showing up at opensslrampage.org. One of the highlights was when they found it would use private keys as an entropy source: https://opensslrampage.org/post/83007010531/well-even-if-time-isnt-ran…

Back around the time of Heartbleed, there was a bunch of childish[1,2] attention given to OpenSSL's warts, mostly centered around the OpenBSD fork called LibreSSL, which stripped out a lot bad, old code and code for non-Unix platforms. Unsurprisingly, the childish attention faded into nothing because it's much harder to write good code than it is to tear apart someone else's. But the smear on the OpenSSL volunteers' reputation remains, as seen by GP's comment. [1] https://opensslrampage.org/page/49 [2] https://opensslrampage.org/post/83555615721/the-future-or-lack-thereof…

A bit off-topic (sorry) but the recent decision to allow ANSSI FRP256v1 in libressl worries me: http://opensslrampage.org/post/84442190366/add-support-for-the-french-… I get that logic in the post, but there are concerns that FRP256v1 was weakened in the standard similarly to the FIPS curves. So I'm not sure that is good reasoning. Also I am unsure if the libressl/openssl implementation has good small subgroup attack defenses even.