Microsoft Warns of New Video ActiveX Vulnerability 146
ucanlookitup writes "Microsoft has warned of a 'privately reported' vulnerability affecting IE users on XP or Windows Server 2003. The vulnerability allows remote users to execute arbitrary code with the same privileges as the users. The vulnerability is triggered when users visit a web site with malicious code. 'Security experts say criminals have been attacking the vulnerability for nearly a week. Thousands of sites have been hacked to serve up malicious software that exploits the vulnerability.' The advisory can be found at TechNet. Until Microsoft develops a patch, a workaround is available."
Re:Fixes (Score:2, Informative)
Not privately reported (Score:3, Informative)
Securityfocus [securityfocus.com] has more details, including the secret identity of the 'private reporter'
Re:Isolate! (Score:3, Informative)
Re:better workaround (Score:3, Informative)
Re:Fixes (Score:3, Informative)
here [microsoft.com] is the fix and no, it isn't "downgrading to Vista." It disables the vulnerable parts of the OS/IE.
There is a difference - attack surface (Score:5, Informative)
It is true that an ActiveX and NSAPI plug-ins are both native code and can have the same risks. But the big difference is attack surface. Code needs to very explicitly be written as a NSAPI plug-in. However, most Windows components are by default a COM object, and perhaps controlable by Internet Explorer if the developer so chooses (traditionally referred to as an ActiveX control).
So a typical Firefox installation may have a half dozen or so plugins available, and they may have vulnerabilities. But a typical IE installation has literally thousands of COM objects at its disposal (A bare Windows XP installation has over 2500 COM objects). And those objects may have vulnerabilities as well.
So play the numbers. IE's close integration with the OS means that it has a larger attack surface. While isolation and privilege separation is a good idea, the actual reason that Vista and 2008 are unaffected are *not* because of low-rights IE. IE on those platforms treats the ActiveX interaction required by the exploit as "unsafe" and is blocked. (Rather than allowing the exploit to occur but "neutering" it by giving it low rights).
Re:Hi, I'm a mac (Score:2, Informative)
It can. Made the change to our GPOs, and it's rolling out now. Having an issue with terminal server users, the installer is trying to install for every user that accesses the box (as intended, I guess) but none of our users have admin rights so it's bombing out....that's a simple fix though, just exclude any terminal server you might have and patch it manually.
So, to answer my own question, yeah, it's easy to script it.
Re:There is a difference - attack surface (Score:3, Informative)
The vulnerability here comes from, NOT necessarily the oodles of known COM libraries on every Windows system. It isn't REALLY about the fact that you can CreateObject("COMObject.OfMyChoice") on these already known objects... it's all that wrapped together with a COM object that has a
Informative? More like "+1, Sounds Kinda Right." (Score:2, Informative)
Wrong on two counts:
1. Every ActiveX object is a COM object, but not every COM object is an ActiveX object. This is not a pedantic distinction.
2. IE is no more integrated with the OS than Webkit is in KDE: the rendering libraries are considered part of the OS, and the plugin mechanism previously discussed operates there as well.
Please know more about the technology before making unfounded assertions.
Re:Oh well. (Score:3, Informative)
iemployee.com
IE only.
Yes, I AM afraid.