Sure, it's easy to disable killbits if you have the ability to run code on a windows system. But if you've already reached the point of running arbitrary code on a windows system, why would you go through the trouble of disabling a kill bit and then hope that the ActiveX control gets exploited so that you can... run code on a windows system? Think about it.
You are correct. My original post was a bit over-simplified. Out of the COM objects that comes with Windows XP, about 350 of them are marked Safe for Scripting, and almost 250 of them are marked Safe for Initialization with a pretty large, but not complete amount of overlap between the two properties. That's still orders of magnitude larger than the plug-in attack surface of a browser like Firefox.
And even the objects that are not Safe for Scripting or Init cannot be discounted. Some objects cause IE to crash in an exploitable manner, triggered just by Internet Explorer checking if the control is safe or not. See: http://www.kb.cert.org/vuls/id/959049 for more details. There is no analogy of this in the NSAPI world.
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).
The second article (the one on NoDriveTypeAutoRun) is actually for how to disable AutoRun. The problem is that even Microsoft themselves conflates the terms AutoRun and Autoplay. If you look at the article, you will notice that it was written for Windows 2000. AutoPlay was not introduced until Windows XP. So basically, you've got an article that uses the term "Autoplay" before the feature was released or publicly known.
So although the NoDriveTypeAutoRun article uses the term "Autoplay," it should be interpreted as meaning "AutoRun." The setting does not disable AutoPlay as most people understand it (the menu with multiple choices as for what to do with a plugged-in device). Now, the main issue here is that the article is not accurate, as Windows does not actually fully obey the setting unless a special update, which is not automatically deployed via Microsoft Update for all systems, is installed.
TweakUI is just a GUI frontend for registry settings. The TweakUI setting for AutoRun/AutoPlay is just setting the value for the NoDriveTypeAutoRun registry key, which does not work properly, as outlined in the alert.
Aside from a clunky GUI, the thing that stood out the most for me about VirtualBox is the abysmal snapshot support. Both VMWare and Parallels allow for a snapshot tree where you can instantly jump to any powered-on machine state that you have saved. VirtualBox, on the other hand, seemed to only support a linear, multiple-level undo.
Anybody know if any progress has been made in this area?
Ok, a couple of problems here: - Standard video is not 24 frames per second, as the original article states. That's the speed for film, not video. - 1080i HDTV is displayed at the same frame rate as standard definition TV. In PAL land, that's 50 fields per second, which makes 25 frames per second. - Even at 720p's 50 full frames per second in PAL countries, that does not give the perception of smoother motion. SDTV will give you 50 half-resolution fields per second, and 720P will give you 50 full-resolution frames per second. The motion smoothness will be essentially the same. The real difference is the resolution delivered with each picture.
The site www.abit.com.cn has been hosting exploit code for the IE data binding vulnerability for over a week (injected iframe), and still hasn't been cleaned up. This may explain why they don't care.
Basically: 1) U3 devices emulate CD-ROM devices, which will automatically run code with zero user interaction. 2) Clicking a drive icon in Windows explorer may run code specified in the autorun.inf file rather than exploring that drive location.
Forgot to disable AutoRun, perhaps. But actually, it's quite non-intuitive how to disable AutoRun in Microsoft Windows. There are several options, and none of them (and even all of them combined) will disable AutoRun and AutoPlay features in their entirety. In fact, up until recently, Windows Vista had the logic reversed for one of the AutoRun features! i.e., if you take the effort to disable the AutoRun feature, you actually put yourself at more risk. More details here: http://www.kb.cert.org/vuls/id/889747
But luckily, there is a single registry value that can disable AutoRun at its core. Once this change is made, Windows will not interpret the Autorun.inf file on any device, effectively disabling AutoRun for all devices, including USB drives, network shares, and more. Get the scoop here: http://www.cert.org/blogs/vuls/2008/04/the_dangers_of_windows_autorun.html
Not upgrading to IE7 because you don't "use" it is dangerous. Because, as you mentioned, IE is closely integrated into the operating system, its components can be used by other applications regardless of whether you click the blue 'E' icon or not. Any Windows application that has the ability to handle HTML content is likely to use some IE components. So if IE is not fully up to date, these other applications can put you at risk.
So, for example, vulnerabilities that only affect IE6 may affect other applications that use the relevant IE components for HTML rendering (think email, IM, etc.). Such as: http://www.kb.cert.org/vuls/id/923508
Or, even better... A recent Safari for Windows vulnerability: http://www.kb.cert.org/vuls/id/127185 Safari, a "stand-alone" web browser, is actually at a higher risk on systems with IE6 as opposed to IE7.
As with any software on your computer, you should upgrade it whether you *think* you use it or not.
Your statement is incorrect. Newer versions of IE (IE7) does indeed have ActiveX enabled in the Internet zone. It does have a feature called ActiveX opt-in, which requires the user to accept a prompt before running controls installed by most stand-alone applications. However, ActiveX controls that are installed through IE (Such as the Myspace and Facebook controls mentioned in this article) are automatically opted-in during the install process. So IE7 would provide no additional protection in this case.
"ActiveX" itself is not necessarily the problem. ActiveX is a commonly used format for packaging native code in a way that it can be used by Internet Explorer. If that code contains a flaw, then Internet Explorer can be used as an attack vector for that buggy code. For example, if that code is written in C and it doesn't properly handle strings, it may be vulnerable to a buffer overflow that can reached by viewing a web page. That holds true whether that code is packaged as an ActiveX control or a Netscape-style plugin.
Plug-ins (including ActiveX) are dangerous. ActiveX is much more ubiquitous than Netscape-style plugins. For example, nearly every windows application comes with ActiveX or COM objects, but it's very rare for them to install Netscape-style plugins. Therefore, using Internet Explorer with ActiveX enabled for all sites on the internet (the default configuration) is dangerous because you're relying on all of these components to be written securely.
You'll want to set the NoDriveTypeAutorun registry value in HKLM to 0xFF. This will disable Autorun/Autoplay for all device types. What's interesting, though, is that according to that article, the default configuration for Windows is to disable Autorun for removable disks that aren't "CD" devices. What's not clear is whether this digital picture frame actually does automatically run, or whether it requires the user to double-click on the device icon in Windows explorer. (The latter of which will run software on the frame, regardless of AutoRun settings).
However, if your goal is to make a change that is malware-resistant, forget it! If you've already got malicious code on your system, it's game over. It can make any software changes that it likes.
Slashdot Mirror
Sure, it's easy to disable killbits if you have the ability to run code on a windows system. But if you've already reached the point of running arbitrary code on a windows system, why would you go through the trouble of disabling a kill bit and then hope that the ActiveX control gets exploited so that you can... run code on a windows system? Think about it.
NoScript actually mitigates this vulnerability. The ABE feature, in particular:
http://noscript.net/abe/
So although I added the firewall mitigation in dd-wrt, I was pleased to find that NoScript blocked the CSRF request before it even got to the router.
You are correct. My original post was a bit over-simplified. Out of the COM objects that comes with Windows XP, about 350 of them are marked Safe for Scripting, and almost 250 of them are marked Safe for Initialization with a pretty large, but not complete amount of overlap between the two properties. That's still orders of magnitude larger than the plug-in attack surface of a browser like Firefox.
And even the objects that are not Safe for Scripting or Init cannot be discounted. Some objects cause IE to crash in an exploitable manner, triggered just by Internet Explorer checking if the control is safe or not. See:
http://www.kb.cert.org/vuls/id/959049 for more details. There is no analogy of this in the NSAPI world.
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).
CERT has been telling users to disable Java in your web browser for years. If you haven't done so already, give it a shot. You probably won't miss it.
http://www.cert.org/tech_tips/securing_browser
Repeat after me:
UAC is NOT a security feature!
It was added to software developers do the right thing, i.e. not require administrative privileges unless absolutely needed.
http://www.networkworld.com/news/2007/021407-microsoft-uac-not-a-security.html
So what does this experiment show? That people just aren't computer savvy.
The second article (the one on NoDriveTypeAutoRun) is actually for how to disable AutoRun. The problem is that even Microsoft themselves conflates the terms AutoRun and Autoplay. If you look at the article, you will notice that it was written for Windows 2000. AutoPlay was not introduced until Windows XP. So basically, you've got an article that uses the term "Autoplay" before the feature was released or publicly known.
So although the NoDriveTypeAutoRun article uses the term "Autoplay," it should be interpreted as meaning "AutoRun." The setting does not disable AutoPlay as most people understand it (the menu with multiple choices as for what to do with a plugged-in device). Now, the main issue here is that the article is not accurate, as Windows does not actually fully obey the setting unless a special update, which is not automatically deployed via Microsoft Update for all systems, is installed.
For all systems older than Vista, the update needs to be manually installed for Windows to obey the AutoRun preference. This means all client systems.
TweakUI is just a GUI frontend for registry settings. The TweakUI setting for AutoRun/AutoPlay is just setting the value for the NoDriveTypeAutoRun registry key, which does not work properly, as outlined in the alert.
Do you really have to ask what Parallels is?
Aside from a clunky GUI, the thing that stood out the most for me about VirtualBox is the abysmal snapshot support. Both VMWare and Parallels allow for a snapshot tree where you can instantly jump to any powered-on machine state that you have saved. VirtualBox, on the other hand, seemed to only support a linear, multiple-level undo.
Anybody know if any progress has been made in this area?
You do realize that NTSC has a faster frame rate than PAL, right?
Ok, a couple of problems here:
- Standard video is not 24 frames per second, as the original article states. That's the speed for film, not video.
- 1080i HDTV is displayed at the same frame rate as standard definition TV. In PAL land, that's 50 fields per second, which makes 25 frames per second.
- Even at 720p's 50 full frames per second in PAL countries, that does not give the perception of smoother motion. SDTV will give you 50 half-resolution fields per second, and 720P will give you 50 full-resolution frames per second. The motion smoothness will be essentially the same. The real difference is the resolution delivered with each picture.
The site www.abit.com.cn has been hosting exploit code for the IE data binding vulnerability for over a week (injected iframe), and still hasn't been cleaned up. This may explain why they don't care.
Not at all. Please read:
http://www.cert.org/blogs/vuls/2008/04/the_dangers_of_windows_autorun.html
Basically:
1) U3 devices emulate CD-ROM devices, which will automatically run code with zero user interaction.
2) Clicking a drive icon in Windows explorer may run code specified in the autorun.inf file rather than exploring that drive location.
Forgot to disable AutoRun, perhaps. But actually, it's quite non-intuitive how to disable AutoRun in Microsoft Windows. There are several options, and none of them (and even all of them combined) will disable AutoRun and AutoPlay features in their entirety. In fact, up until recently, Windows Vista had the logic reversed for one of the AutoRun features! i.e., if you take the effort to disable the AutoRun feature, you actually put yourself at more risk. More details here:
http://www.kb.cert.org/vuls/id/889747
But luckily, there is a single registry value that can disable AutoRun at its core. Once this change is made, Windows will not interpret the Autorun.inf file on any device, effectively disabling AutoRun for all devices, including USB drives, network shares, and more. Get the scoop here:
http://www.cert.org/blogs/vuls/2008/04/the_dangers_of_windows_autorun.html
Yes, it affects Adobe Reader on all supported platforms.
Not upgrading to IE7 because you don't "use" it is dangerous. Because, as you mentioned, IE is closely integrated into the operating system, its components can be used by other applications regardless of whether you click the blue 'E' icon or not. Any Windows application that has the ability to handle HTML content is likely to use some IE components. So if IE is not fully up to date, these other applications can put you at risk.
So, for example, vulnerabilities that only affect IE6 may affect other applications that use the relevant IE components for HTML rendering (think email, IM, etc.). Such as:
http://www.kb.cert.org/vuls/id/923508
Or, even better... A recent Safari for Windows vulnerability:
http://www.kb.cert.org/vuls/id/127185
Safari, a "stand-alone" web browser, is actually at a higher risk on systems with IE6 as opposed to IE7.
As with any software on your computer, you should upgrade it whether you *think* you use it or not.
A search for CVE identifiers related to Joomla returns 244 hits:
http://nvd.nist.gov/nvd.cfm
New exploits for the vulnerabilities are released several times per week:
http://milw0rm.com/search.php?dong=joomla
Sounds like really good quality stuff...
It doesn't matter how poorly the web site is coded. A browser should never crash when rendering a page!
Or how about disable autorun instead of having to remember to hold down shift before any CD, DVD, thumb drive, etc. is inserted into your computer?
http://www.cert.org/blogs/vuls/2008/04/the_dangers_of_windows_autorun.html
Your statement is incorrect. Newer versions of IE (IE7) does indeed have ActiveX enabled in the Internet zone. It does have a feature called ActiveX opt-in, which requires the user to accept a prompt before running controls installed by most stand-alone applications. However, ActiveX controls that are installed through IE (Such as the Myspace and Facebook controls mentioned in this article) are automatically opted-in during the install process. So IE7 would provide no additional protection in this case.
"ActiveX" itself is not necessarily the problem. ActiveX is a commonly used format for packaging native code in a way that it can be used by Internet Explorer. If that code contains a flaw, then Internet Explorer can be used as an attack vector for that buggy code. For example, if that code is written in C and it doesn't properly handle strings, it may be vulnerable to a buffer overflow that can reached by viewing a web page. That holds true whether that code is packaged as an ActiveX control or a Netscape-style plugin.
Plug-ins (including ActiveX) are dangerous. ActiveX is much more ubiquitous than Netscape-style plugins. For example, nearly every windows application comes with ActiveX or COM objects, but it's very rare for them to install Netscape-style plugins. Therefore, using Internet Explorer with ActiveX enabled for all sites on the internet (the default configuration) is dangerous because you're relying on all of these components to be written securely.
Secure your web browser and you'll be much better off.
You'll want to set the NoDriveTypeAutorun registry value in HKLM to 0xFF. This will disable Autorun/Autoplay for all device types. What's interesting, though, is that according to that article, the default configuration for Windows is to disable Autorun for removable disks that aren't "CD" devices. What's not clear is whether this digital picture frame actually does automatically run, or whether it requires the user to double-click on the device icon in Windows explorer. (The latter of which will run software on the frame, regardless of AutoRun settings).
However, if your goal is to make a change that is malware-resistant, forget it! If you've already got malicious code on your system, it's game over. It can make any software changes that it likes.