The latest Flash vulnerability and monoculture

[Jerry Leichter]

On Jul 26, 2009, at 11:20 PM, Perry E. Metzger wrote:

> Jerry Leichter <leichter at lrw.com> writes:
>> While I agree with the sentiment and the theory, I'm not sure that it
>> really works that way.  How many actual implementations of typical
>> protocols are there?
>
> I'm aware of at least four TCP/IP implementations in common use,
Can you name a single system that allows you to substitute different  
TCP/IP stacks?  Without that, there's little practical diversity.  The  
practical difference between a bug that affects 25% of the world's  
systems and 100% of the world's systems - assuming unrealistically an  
even division - isn't all that great.

> several
> common HTTP servers (though there are far more uncommon ones),
Apache and IIS together make up the bulk of implementations.   
Microsoft's long-standing drive to avoid OSS software accounts for one  
of the common TCP/IP implementations, too.  On the one hand, Microsoft  
isn't doing much of this any more - and no one else is trying.  On the  
other, this confirms my observation that an open definition with  
closed implementations is the most likely source of *multiple*  
implementations.

Here, a bug would hit close to half of all systems in the world.  The  
minor players are irrelevant.

> at least
> four or six common web browsers (depending on whether you count the
> several that use webkit as a single implementation or not),
There's probably more diversity here than anywhere else, as the result  
of first Firefox (and other Gecko-based browsers, though they are  
minor players) and then Safari and other Webkit-based browsers  
breaking up Microsoft's lock on the market.  Most of the others divide  
off into disjoint markets which rarely share much software.

> a half dozen
> jpeg libraries, three different opentype implementations, etc., etc.


>> One way or another, a single implementation usually wins out in the
>> OSS community.
>
> See above -- even counting only open source, we have *many*
> implementations. Heck, there are even multiple independent open source
> SSL, SSH and PGP implementations.
Yes, you can find examples.  But there are also examples where there  
is little diversity.  How many active competitors to zlib are there?   
Security bugs in zlib - which have occurred - cause grief to wide  
swaths of products.  While there a independent zip implementations,  
most of the less-known compression algorithms have one implementation  
- and bugs in those have led to problems in multiple anti-virus  
packages, which have to support all the formats and aren't about to re- 
implement them.

Keeping multiple implementations going is expensive - whether you're a  
commercial outfit who has to find the money, or and OSS project that  
has to attract developers.  There has to be a good reason to do it.   
There will be cases where good reasons are present - optimization for  
very different kinds of environments (low power embedded vs. larger  
systems, for example).  For OSS, just simple pride and competition can  
last for a long time, and sometimes get "frozen in".  Competitive  
differentiation is important for commercial efforts - and is  
increasingly affection OSS efforts through commercial funding.  But  
all of these have to fight a natural tendency to settle on a single  
solution once the problem is no longer novel, the techniques are all  
well understood, and there's ultimately little to distinguish one  
solution from another.  It'll happen sometimes, for some period of time.

I'm not saying more diversity isn't better.  Certainly, if the  
protocol is closed, there will likely be very little if any diversity  
in implementation.  So open standards are to be preferred.  All I'm  
saying is that there's no magic here.  If anything, OSS *encourages* a  
convergence on a single solution, because using what's already there  
is so cheap that you need some really good reason *not* to.
                                                         -- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com