|
|
Log in / Subscribe / Register

OpenSSL security advisory for September 26

This OpenSSL security advisory is notable in that it's the second one in four days; sites that updated after the first one may need to do so again. "This security update addresses issues that were caused by patches included in our previous security update, released on 22nd September 2016. Given the Critical severity of one of these flaws we have chosen to release this advisory immediately to prevent upgrades to the affected version, rather than delaying in order to provide our usual public pre-notification."

to post comments

OpenSSL security advisory for September 26

Posted Sep 26, 2016 17:37 UTC (Mon) by fratti (subscriber, #105722) [Link] (11 responses)

Please stop fucking up already

OpenSSL security advisory for September 26

Posted Sep 26, 2016 20:04 UTC (Mon) by flussence (guest, #85566) [Link] (3 responses)

The best we can do is encourage downstream projects to make their code libressl-compatible. Right now I'm stuck with OpenSSL because hostapd doesn't support wifi without it... (sigh)

OpenSSL security advisory for September 26

Posted Sep 26, 2016 20:50 UTC (Mon) by pizza (subscriber, #46) [Link] (1 responses)

Unless something's changed in the last couple of years, hostapd and wpa_supplicant both will function fine without OpenSSL -- IIRC they support GNUTLS and also an internal SSL implementation (based on libtomcrypt) that was more than adequate to support wpa2-enterprise with full X509 certificates...

OpenSSL security advisory for September 26

Posted Sep 29, 2016 18:35 UTC (Thu) by flussence (guest, #85566) [Link]

You're right: searching a bit deeper into my problem points to an unresponsive distro maintainer and a pile of dropped patches...

OpenSSL security advisory for September 26

Posted Sep 28, 2016 13:18 UTC (Wed) by sandsmark (guest, #62172) [Link]

It's not like libressl wasn't hit: https://github.com/libressl-portable/openbsd/commit/f57f7...

Unfortunately libressl doesn't seem to publish proper advisories, that I could find at least.

OpenSSL security advisory for September 26

Posted Sep 27, 2016 23:09 UTC (Tue) by pjm (guest, #2080) [Link] (5 responses)

Are you suggesting that the flaw was intentional, or do you have some wisdom to pass on to software developers how we can all stop fucking up from now on?

on responding to errors

Posted Sep 27, 2016 23:44 UTC (Tue) by pjm (guest, #2080) [Link] (4 responses)

I apologize for my own sarcastic tone; I should tell myself off.

Trying again: I object to the remark not so much because making mistakes isn't something one chooses, but rather because it seems an ungracious response to others' efforts to fix problems to help others including many LWN readers. I don't want anyone who has tried hard to provide a fix quickly under pressure to withdraw from trying to help people as a result of receiving such thanks.

on responding to errors

Posted Sep 28, 2016 9:38 UTC (Wed) by fratti (subscriber, #105722) [Link] (3 responses)

I'm by far not the first to mention this, so this isn't exactly news to anyone, but had they fixed their code to get rid of all the preprocessor cruft for stupid things like support for imaginary systems (big-endian x86!) or long-dead compilers, they might actually be able to use static analysers to help them avoid exactly this type of bug.

on responding to errors

Posted Sep 28, 2016 19:28 UTC (Wed) by HenrikH (subscriber, #31152) [Link] (2 responses)

So why was libressl hit by that same bug then since they have done all that you just described as the remedy for problems such as this? Could it be that software development in a project the scale of OpenSSL is a little bit harder than just "don't fuck up"?

on responding to errors

Posted Sep 29, 2016 8:27 UTC (Thu) by liw (subscriber, #6379) [Link]

A strongly-held opinion follows.

The proper response to yet another bug in OpenSSL (or any other popular software) is to a) find further bugs b) submit patches for them c) find a higher-quality replacement or d) develop a higher-quality replacement. Bad-mouthing isn't constructive.

on responding to errors

Posted Sep 29, 2016 14:31 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

While it's true that this is harder than "don't fuck up", there inevitably will be some element of "don't fuck up" to any system even if that's limited to correct design of the system itself.

One illustration I like is a UK user-worked level crossing (ie a privately owned road crosses the railway, typically at a farm) where they had a near miss after the user telephoned for authority to cross, received it, and then before they could use the authority saw a train pass right in front of them.

Who fucked up? Not the crossing user. Not the train driver. Not even the signaller who gave authority (although they did other things wrong not causal to the near miss itself).

The immediate cause was that the signalling system showed the crossing in logically the wrong place. The train which arrived was shown as having already passed that crossing. So who fucked up? Well, a human transcribing paper documents into an electronic system for a re-signalling project typo'd an identifier. OK. But obviously a system vulnerable to such drastic consequences from a typo is itself unsound. Who fucked up there? Almost everybody. The programmers had checks for a number of mistakes made in transcription or when adding new data, but not this particular sort of typo. The managers tasked with comparing the paper documents to the imported electronic ones noticed the typo as a difference but didn't understand its significance as an error and assumed it was correcting the paper plan. The signallers never asked why their new system showed the crossing in a different place. After the initial error almost all other humans assumed that any consequence they saw must have a good explanation and didn't inquire what that was. Only the accident's investigators took the measure of simply going to the crossing and examining the territory to see how it compared to the map.

So yeah, it will always be possible for somebody to fuck up. BUT ultimately this incident was a level crossing fault. Though different in nature to many other types of level crossing incident, it shares with them the fact that it wouldn't happen if all traffic was grade-separated. No new railway should have level crossings at all, it's just not worth the risk. So my point is that likewise, too many of these OpenSSL or libressl bugs involve risky low-level constructs that needn't even have been used in an SSL library in the first place. "Don't fuck up" is necessary but we can make things safer by reducing the number of chances to fuck up.

OpenSSL security advisory for September 26

Posted Sep 30, 2016 17:25 UTC (Fri) by hkario (subscriber, #94864) [Link]

It's a huge complex codebase that is being pounded on by basically every security researcher on the planet.

Of course they will be finding bugs in it!

Any implementation of crypto that includes stuff like PKI/X.509 and TLS will be big and complex. Audits and writing it from scratch won't help you either: https://blogs.aws.amazon.com/security/post/TxLZP6HNAYWBQ6...


Copyright © 2016, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds