[Cryptography] Would open source solve current security issues? (was "Re: EFF amicus brief in support of Apple")

ianG iang at iang.org
Thu Mar 17 20:10:54 EDT 2016


On 10/03/2016 11:28 am, Jerry Leichter wrote:
> I agree overall, but want to point out one additional bias in the data:
>
>> Where the data is mostly clear is that "time to fix" once a security vulnerability is made public (say, with 0days) is much quicker for getting an initial fix for open source projects than it is for closed source projects.
> It depends on the kind of patch and the length of supply lines.
>
> Open source projects can very quickly ship a source patch for the particular module involved.  This is fine for those who build from source - a tiny minority.
>
> The next step is getting the patch into a binary build.  Depending on the project to which the patch is made, that can take a couple of days.  The delays can also mount for the more branched distributions.  SuSE Linux, for example, always seems to take longer than many of the more mainstream distributions because they have their own variants of all the patches.  (Exactly what's different and why, I don't know, but their version id's are consistently different - which causes all kinds of grief for audits based on "version x.y.z and earlier have the bug".)  We're not talking big numbers - a couple of days at most - but the effect is there.
>
> Beyond that, of course, are products built on top of the binary distributions - and products built on top of *them*.  All of these take time to incorporate changes and push them out to clients.  Some - most famously Android phones, all the way at the end of supply lines running through handset makers and Telco's - never receive the changes at all.


I tracked the 'renegotiation' cycle over its announcement, fix, distro 
and finally to a measurement of 80% patched here:

http://financialcryptography.com/mt/archives/001210.html

The measurement of that OODA loop was 41 months.  Now, we can quibble 
about the numbers.  It's one story and we'd need a dozen or so to get 
reliable data.

It does however suggest some questions:

   Was open source an important factor in the slowness to patch?
   Would Microsoft have been able to do it faster?
   Would Apple?
   Would Android?

It may be that with enough eyeballs, all bugs are shallow.  It may also 
be that with enough open source, you can still drown in a one inch deep 
ocean of upgrade treacle.

The ways I've mitigated the supply chain treacle in the past are:

   a. build upgrade into the security model.
   b. shorten the supply chain (absorb that package!)
   c. do your own security stack.

These things of course involve taking on some more risk, in exchange for 
getting rid of other risks.  It's not clear that these mitigations cause 
breaks any more than say the open source package spaghetti weaving 
process, but when they do break, it's a lot faster to get the fix out to 
users.

(Note that I've not tested these out to large scale.)

...
> Of course, there are always the high-priority emergency patches - e.g., Heartbleed.  Recently, these have been reported to the software vendors privately and coordinated announcements and releases of patches have been standard.  In this case, the delays were all "up front", before the announcement - and the differences between open and closed source have *largely* been nil.  (Apple delayed on shipping a Heartbleed patch - but then it was pretty much irrelevant to the vast majority of their devices, which don't run HTTP servers.)


Yes, significant learning there.  Has anyone any notion of the time 
between discovery, announcement, and say 80% patch rate for the modern 
generation of issues such as Heartbleed?


> I think the important take-away from the whole discussion is that these are *systems* issues and have to be analyzed at that level.  How long it takes for someone to get out there and produce a patch is dwarfed by the time it takes for working secure code to actually get deployed on a significant proportion (ideally, all!) vulnerable systems.  Both open and closed source communities have been improving their approaches for a number of years now, and both have (in general - let's not get started on, say, industrial controller makers) improved things, often dramatically.


Right.  IoT.  Another pertinent question to ask is what other processes 
do we know about that haven't even begun to think about the supply chain 
aspects of delivery of security?

Nudge, nudge.

And, if you had to choose between a lunchtime Dagwood sandwich of dodgy 
algorithms versus a quagmire supply chain mixed into a bowl of spaghetti 
packages ... pick one ... which would you pick?



iang




More information about the cryptography mailing list