[Update: I was wrong... It seems Microsoft has previously released kill bits for for third party software. Thanks to Edi and David for notifying me of this; I've updated this post accordingly.]
Just a quick post today. Its the second Tuesday of the month which means its Patch Tuesday. Browsing over the bulletins, there are some interesting ones as always, but MS08-023 caught my eye in particular:
This update includes kill bits that will prevent the following ActiveX controls from being run in Internet Explorer:
Yahoo! has released a security bulletin and an update that addresses the vulnerability in Yahoo! Music Jukebox. Please see the security bulletin from Yahoo! for more information and download locations. This kill bit is being set at the request of the owner of the ActiveX control. The class identifiers (CLSIDs) for this ActiveX control are:
• {5f810afc-bb5f-4416-be63-e01dd117bd6c}
• {22fd7c0a-850c-4a53-9821-0b0915c96139}
Firstly, a recap. A kill bit is a registry setting that prevents an ActiveX control from being instantiated in Internet Explorer. Microsoft have used kill bits extensively over the last few years to mitigate security issues in their own controls; these have been pushed out via Windows Update. Other software vendors have also used kill bits but have had no unified means of pushing out updates. This has lead to a plethora of systray applications running constantly, checking for security updates. As annoying as these can be, the alternative, that the end user must periodically go and check for new updates is not a secure, scalable solution.
To my knowledge, Microsoft hasn't previously provided kill bits over Windows Update for third party controls that do not come bundled with the OS [not true, read this footnote]. This one is for Yahoo! Music Jukebox, and the Microsoft bulletin even links to the Yahoo! Bulletin.
Personally I think its a great idea for third parties to be able to have their kill bits pushed out over Windows Update. That said, I'd be interested in hearing some of the logistics of how this update came about - I'm hoping the Microsoft Security Response team will talk about this in the future. Some of the things I'm wondering are:
- What is the process for a third party to request that Microsoft kill bit a control?
- Can any company request their controls be kill bit-ted?
- If not, what are the criteria?
- How does Microsoft verify the company is who it says it is, and has permission to kill bit the control?
Anyway, thats it for now. I'll be continuing my analysis of last month's JRE vulnerabilities in a new post later this week.
Cheers
John
Important footnote: It turns out Microsoft has released third party kill bits as hotfixes on at least two previous occasions. MS06-067 provided kill bits for WinZip 10, fixing the CreateNewFolderFromName() issue and
MS07-027 did the same for Acer and RIM vulnerabilities. I suspect there are others in previous bulletins too. I would still be interested to hear how these companies went about coordinating the update with Microsoft though.
3 comments:
This is not the first time MS provided kill bits for 3rd party component over Windows Update. It was done before. I remember the "famous" WinZip v10 CreateNewFolderFromName() issue.
From MS06-067 advisory: This security update also sets kill bits for ActiveX controls included with WinZip 10.0, software available from WinZip Computing."
They actually have done this in the past, for example, in MS07-027 (May 2007), they set kill-bits for vulnerabilities in Acer and RIM Blackberry ActiveX controls. I am sure there are earlier instances than this as well. Of course, every time they do it, it tends to go under the radar...
Perhaps in the first case, only vendors who sign their applications and controls should be allowed to access this facility. The act of obtaining a signing certificate should ensure some means of verifying identity and allows MS to checkup on the person contacting them with a kill bit request.
MS would require a formal request process that should have a full analysis of the vulnerability, including any know exploits operating in the wild, potential impact, etc.
However, we can't ignore the fact that most organisations don't use the SDL! Not surprisingly MS do and it forms a big part of how they develop their applications and systems and the updates for them. Does that mean the 3rd party vendors should look to work with MS and its partners to improve their application development process, even going to the extent of adopting the SDL? Could be a pretty costly programme!
To extend you post, it would be great to see MS / Windows Update being used to distribute more 3rd party updates and allow us to get rid of the now default situation of having dozens of applications checking for updates on system or application startup. If anything, it would stop vendors doing a "Safari" on us!
Post a Comment