Bringing the Android kernel back to the mainline
Bringing the Android kernel back to the mainline
Posted Nov 20, 2018 18:18 UTC (Tue) by farnz (subscriber, #17727)In reply to: Bringing the Android kernel back to the mainline by marcH
Parent article: Bringing the Android kernel back to the mainline
The problem with the current security circus is that instead of trying to get people to address the underlying reasons certain classes of bug exist at all, it gets people to address individual high-profile bugs.
So, for example, picking on OpenSSL here, there's a 2011 OCSP stapling vulnerability caused by trusting that a packet sent by a remote host is correctly formed, and parsing accordingly. This individual bug gets fixed, but nothing is done to address the more general problem of insecure handling of packets. Then, in 2014, Heartbleed comes along - caused by trusting that a packet sent by a remote host is correctly formed, and parsing accordingly. Then there's CVE-2015-0291, where - stop me if you've heard this before - OpenSSL trusts that a certificate sent by a remote host is correctly formed, and parses it accordingly.
There's a pattern of bugs here (and OpenSSL is not the only code to have this sort of pattern) where the same class of mistake is being made again and again. If the security circus was fixing the errors of "good enough, ship it!", then the circus around Heartbleed would have prevented CVE-2015-0291 from happening - parsing code used by OpenSSL would have been fixed such that you couldn't accidentally assume that remote controlled data was well-formed.
Posted Nov 20, 2018 18:46 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (6 responses)
It does but very slowly.
> it gets people to address individual high-profile bugs.
Short terms fixes are needed too. For two reasons: 1. to quickly put out fires 2. to very slowly change how people (vendors *and* customers) think.
Posted Nov 20, 2018 19:37 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (5 responses)
When you say "very slowly", exactly how slowly do you mean? I've picked on OpenSSL because the security circus has been shouting about it for over a decade, and yet there's been three bugs with the same underlying engineering errors in that time that are significant enough to be mentioned in Wikipedia.
I don't see the security circus having much impact here - it's still shouting about the same types of bugs as always, and yet we're still seeing core infrastructure being built in a fashion where there's no automatic separation between trusted data where you can assume it'll parse sensibly, and attacker controlled data. The recent DHCPv6 issue in systemd-networkd is more of the same class of bug as OpenSSL has had on and off since 2011 (if not before), and yet despite being a much newer project, modern development techniques as applied in the field don't avoid the "parsed attacker controlled data as-if the attacker would never send invalid packets" bugs.
Posted Nov 20, 2018 20:29 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (2 responses)
Genuine question I'm not an expert.
Posted Nov 21, 2018 10:53 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (1 responses)
Compared to what you'd expect in the absence of the "security circus"? The only change that's not predictable from the state we were in back in 1998 (before the security circus got noisy) is the appearance of Let's Encrypt. Everything that's gone into the standard is either a mix of following the state of the art in cryptography (new ciphers, AEAD modes, end of CBC etc), or reactions to attacks that weren't foreseen at the time the previous standard was written (fixing up padding behaviours, SCSVs etc).
Further, there's no evidence that either OpenSSL or NSS (the two big SSL libraries out there) are changing their development practices in any major way to prevent classes of implementation error in future. Neither are we seeing a new library or a fork of one of the existing two that justifies any claim to higher security - the only significant fork is Google's BoringSSL, which mostly just lags behind OpenSSL and waits to see if there's a bug in an OpenSSL implementation of a feature, rather than trying to change things so that certain classes of implementation error cannot exist in BoringSSL.
In as far as I can see the security circus making any difference at all, it's that it enables managers to tell developers to not even try new security ideas, in case there's a bug - better to be one of thousands hit by the same flaw than to be an outlier.
Posted Nov 21, 2018 21:51 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
No, I didn't ask for speculatively rewriting history and pretending it's possible to have a security industry doing useful work without a corresponding circus.
Fortunately you gave some answers to my actual question anyway.
Posted Nov 20, 2018 20:52 UTC (Tue)
by pizza (subscriber, #46)
[Link] (1 responses)
Quality engineering, especially on an ongoing basis, costs money.
How many of those "shouting" have actually contributed anything to OpenSSL other than hot air?
(And feel free to s/OpenSSL/any other critical infrastructure tool/)
Posted Nov 21, 2018 11:04 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Not many - but the hot air is what the security circus brings, and worse, because the people making decisions often lack technical judgement (not their skillset), it encourages a tendency towards monoculture - better to be one of a million breached sites than to risk the security circus coming down on you for doing something different.
Bringing the Android kernel back to the mainline
Bringing the Android kernel back to the mainline
Bringing the Android kernel back to the mainline
Bringing the Android kernel back to the mainline
Bringing the Android kernel back to the mainline
Bringing the Android kernel back to the mainline
(Yes, $big_players finally created/funded the Core Infrastructure Initiative, but it's a long uphill climb..)
Bringing the Android kernel back to the mainline