Re: The latest Flash vulnerability and monoculture
> It would also help quite a bit if we had better encapsulation > technology. Binary plug-ins for browsers are generally a bad > idea -- having things like video players in separate processes > where operating system facilities can be used to cage them more > effectively would also help to mitigate damage. I think this is one of those circumstances where if you can get the criminal to go to the house next door you've won and that is all the winning you can do. That everyone else uses Famous Vendor Software Latest Version and you don't is your win. Now it would be entirely ironic if the complexity of something (think ASN.1) caused a single working open source version (think ASN.1 compiler) to eclipse all other versions just because the complexity has made it too hard to go forward. As Mike O'Dell used to say, left to themselves, competent engineers will deliver the most complex code they can debug. This may apply to the world at large. --dan - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: The latest Flash vulnerability and monoculture
Jerry Leichter writes: > On Jul 26, 2009, at 11:20 PM, Perry E. Metzger wrote: >> Jerry Leichter 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? I could answer literal mindedly and note that QNX and a couple of other embedded OSes let you do that (or so I recall). However, it is clearly not necessary for that to be possible for people to reap the benefits of 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. That's completely untrue -- the two situations are extraordinarily different. For example, a high security firewall that has identical filtering boxes with the same stack in front of and behind the DMZ has a 100% chance of failure if a TCP bug is found, but will remain fine if two different stacks are in use. (And yes, I've built systems like that, and for exactly that reason.) >> several common HTTP servers (though there are far more uncommon >> ones), > > Apache and IIS together make up the bulk of implementations. Perhaps, but I'm not using either, and neither are many of the worlds largest web sites. There are a lot of web servers out there, and if you want, you can pick any you like based on the characteristics you like. >>> 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? Two, I think. I have trouble thinking of a lot of types of protocol implementations where there is only one available -- you originally claimed this was rare, but it is, in fact, nearly the rule, not the exception. I didn't even mention SMTP, where we have Sendmail, qmail, Postfix, MMDF, and more, and that's just the open source offerings. IMAP implementations are even more diverse. Anyway, you claimed there aren't a lot of diverse protocol implementations, and there are for practically everything important I can think of. You asked: >>> How many actual implementations of typical protocols are there? ...and the answer is, for typical protocols that are widely used, quite a number. If you want to argue that multiple implementations aren't interesting, that's another question, but you claimed they don't exist, and generally, in fact, they do exist. > Keeping multiple implementations going is expensive Having multiple supermarket companies or computer companies is also "expensive". None the less, we seem to have that happen. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: The latest Flash vulnerability and monoculture
> > 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? For Adobe Flash, there are three separate implementations -- Adobe's proprietary one, GNU Gnash, and Swfdec. Gnash is focused on long-term reliability and compatability, like the rest of the GNU programs. Its browser plugin executes the flash interpreter in a separate process (which draws in the browser's subwindow). It can use either gstreamer or ffmpeg to play video or audio. This summer, the development focus is on implementing Flash 10's new class library (they redid it all). Swfdec is focused on playing popular video sites well (sooner than gnash). They share some common regression-testing infrastructure, but the implementations came from different code bases. John - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: The latest Flash vulnerability and monoculture
"Perry E. Metzger" writes: >Jerry Leichter writes: >> 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. That's because crypto is cool, and it's so simple that absolutely anyone who's read the first two chapters of Applied Cryptography can do it. Writing, tuning, and debugging video codecs on the other hand is only slightly more interesting than developing accounts receivable software, only five people on earth really understand how they work, and at least two of them aren't allowed near sharp objects because of what they might do with them. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: The latest Flash vulnerability and monoculture
"Perry E. Metzger" writes: >This highlights an unfortunate instance of monoculture -- nearly everyone on >the internet uses Flash for nearly all the video they watch, so just about >everyone in the world is using a binary module from a single vendor day in, >day out. There are quite a number of third-party video players that will render Flash video, are these using Adobe codecs or third-party H.263/264/VP6 ones? In theory you don't actually need to run Adobe code to view FLV's, but given the freewheeling nature of video players which often, um, borrow codecs from all over the place, it's hard to tell what you're actually getting. Peter. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: The latest Flash vulnerability and monoculture
On Jul 26, 2009, at 11:20 PM, Perry E. Metzger wrote: Jerry Leichter 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 majord...@metzdowd.com
Re: The latest Flash vulnerability and monoculture
Jerry Leichter 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, several common HTTP servers (though there are far more uncommon ones), at least four or six common web browsers (depending on whether you count the several that use webkit as a single implementation or not), 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. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: The latest Flash vulnerability and monoculture
On Jul 26, 2009, at 2:27 PM, Perry E. Metzger wrote: ...[T]here is an exploitable hole in Adobe's "Flash" right now, and there is no fix available yet This highlights an unfortunate instance of monoculture -- nearly everyone on the internet uses Flash for nearly all the video they watch, so just about everyone in the world is using a binary module from a single vendor day in, day out. This is a bit of a wakeup call -- the use of standards based technologies to deliver content to users would likely have led to multiple implementations being in wide use, which would at least mitigate such problems. 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? With open source, once there's a decent implementation, there's little incentive for anyone to start from scratch on an independent one. Why not just improve the one that's already there? One way or another, a single implementation usually wins out in the OSS community. Even if along the way a competition - based on code size or speed or whatever - breaks out between two implementations, in the long one someone usually takes the best from both and produces the ultimate "winner". So while standard, openly defined protocols *make it possible* for multiple OSS implementations to thrive, they certainly don't *guarantee* it, and in many cases that's just not what we end up with. In fact, the scenario most likely to produce multiple *usable* implementations is probably: An open protocol, and multiple *closed source* competing implementations. As an example, not of a protocol, but of another kind of software - consider C compilers. There continues to be a market for proprietary C compilers, and quite a few of them exist. In the OSS world, gcc dominates. (Perhaps a new LLVM- based compiler will displace it - though more likely gcc will just absorb LLVM as an alternate back end. That hardly leave behind all gcc bugs.) In the hardware world, one is typically very leery of buying from a sole-source supplier. It's common to require that the vendor who developed some new chip license someone else to build the thing, too - just in case. (Of course, if you buy a couple of hundred chips a year from Intel, you're not going to have much luck getting them to work with you. But the *big* buyers definitely force second sourcing when they can. It would be nice if Flash users told Adobe "find someone to do another implementation or we stop using Flash." But since the space of Flash users has two components - those who *produce* Flash, who generally won't care about this; and those who use it to get light - it's difficult to generate such pressures. The Flash generators don't have any reason to care about this, and the users of Flash files - who pay nothing - have little leverage unless they serious follow through on a strike plan. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
The latest Flash vulnerability and monoculture
This is purely about security, not on crypto. For those of you not in the know, there is an exploitable hole in Adobe's "Flash" right now, and there is no fix available yet: http://www.adobe.com/support/security/advisories/apsa09-03.html (See also: http://www.us-cert.gov/cas/techalerts/TA09-204A.html ) The responsible thing would be to advise everyone to turn off flash until Adobe comes up with a fixed binary, but of course, if they did, large numbers of companies -- from the obvious Youtube and Hulu to the less obvious business down the street that uses Flash to handle their video catalog -- would be screwed. (Instead, of course, just about everyone out there with a web browser is screwed.) This highlights an unfortunate instance of monoculture -- nearly everyone on the internet uses Flash for nearly all the video they watch, so just about everyone in the world is using a binary module from a single vendor day in, day out. This is a bit of a wakeup call -- the use of standards based technologies to deliver content to users would likely have led to multiple implementations being in wide use, which would at least mitigate such problems. It would also help quite a bit if we had better encapsulation technology. Binary plug-ins for browsers are generally a bad idea -- having things like video players in separate processes where operating system facilities can be used to cage them more effectively would also help to mitigate damage. (By the way, for those that aren't aware, because recent versions of Acrobat Reader include the ability for PDFs to embed Flash, you are better off reading PDFs with third party PDF readers.) Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
