07.29.09
Microsoft’s Extend-and-Extinguish with ActiveX is Blowing Up in Rival Vendors’ Faces
Summary: Proprietary Web rears its ugly head — again
THE most detailed (as in references-filled) post that we have about ActiveX is this one. We also wrote about Novell's support of ActiveX and now we discover that the latest ActiveX flaw affects even Adobe and Cisco.
Microsoft’s ATL problem is spreading. Many other software vendors are affected, among them Adobe and Cisco. The total number of vendors with vulnerable controls is currently unclear. In an interview with heise Security, Microsoft executive Andrew Cushman confirmed that it is not known how many ActiveX controls are affected. Cushman said this is the first time a Microsoft library has been affected by a security problem. According to the executive, Redmond appreciates that this patch not only affects corporate IT teams, but also requires action from software developers.
A highly effective solution would be to ban ActiveX controls, as some companies have been doing for years; ActiveX controls were arguably added for competitive reasons despite the obvious dangers. It helped Microsoft create an Internet Explorer monoculture in the late 90s. A relationship between vulnerability and monoculture was also mentioned in this new E-mail. It is about another proprietary stain on the Web: Flash.
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.
The World Wide Web was built on standards, which were intended to be implemented independently by many capable vendors. Then came Microsoft. This potential departure from standards puts at great risk the entire Internet. █
“Another suggestion In this mail was that we can’t make our own unilateral extensions to HTML I was going to say this was wrong and correct this also.”
–Bill Gates [PDF]
Yuhong Bao said,
July 29, 2009 at 10:25 pm
On the matter of patching libraries like what MS just did with ATL, the LGPL requires that anyone be able to modify LGPL libraries linked into a program, regardless of whether that program is proprietary or free software. This way, if you want or need to patch a library (say to patch security vulnerabilities), you don’t have to wait for the vendor to relink the program.
Yuhong Bao said,
July 29, 2009 at 10:32 pm
Actually, though in general what I just said about patching LGPL libraries is true, in the case of ATL properly patching the hole may require modification to the source code of the programs linking with ATL.
The changes needed were documented in this page from MSDN:
http://msdn.microsoft.com/en-us/visualc/ee309358.aspx