Microsoft Adds Selective ActiveX Filtering to IE9 94
An anonymous reader writes "A post on the IE blog details the new ActiveX filtering feature in the IE9 release candidate. Microsoft's Herman Ng writes, 'ActiveX Filtering in the IE9 Release Candidate gives you greater control over how Web pages run on your PC. With ActiveX Filtering, you can turn off ActiveX controls for all Web sites and then turn them back on selectively as you see fit. While ActiveX controls like Adobe Flash are important for Web experiences today for videos and more, some consumers may want to limit how they run for security, performance, or other reasons.' My favorite quote from the article is one of the image captions: 'ActiveX content may prevent you from having a good experience viewing a Web site'"
Re: (Score:2)
Flash? (Score:2)
Re:Flash? (Score:5, Informative)
Re: (Score:2, Interesting)
For all browsers, except for IE, Flash uses NPAPI. However, Microsoft switched to ActiveX with IE6. I've always wondered if one over the other allowed for different exploits in the different version.
Re:Flash? (Score:5, Interesting)
Both extensibility models run non-sandboxed native code on your machine. In either case, security is zero.
Re: (Score:3, Insightful)
I wonder how many bash ActiveX without realizing this.
Re:Flash? (Score:4, Insightful)
Well, the difference with ActiveX in IE is that it allows the website to prompt downloading the plugin. Historically, the big problem was that it was a simple OK/Cancel type dialog, essentially click-thru. Many more hoops today, but old painful memories die hard.
Re:Flash? (Score:5, Insightful)
Mod parent up +1 informative.
You've hit on the key difference between ActiveX and NPAPI - for NPAPI, the user has to download and install the plugin outside the browser, which means that an attacker couldn't guarantee that a particular plugin was present. For ActiveX, a web page could cause the plugin to be installed automatically which meant that an attacker could be sure that a plugin was present. Of course the code that allowed for silent installs has been gone for the better part of a decade but as you said, old painful memories die hard.
Re: (Score:2)
Wait, am I to understand that IE used to allow installation and execution of arbitrary binaries? From the web!? How did any one ever think that this was a good idea?
Re:Flash? (Score:4, Interesting)
Not quite. IE used to allow the installation of arbitrary *signed* binaries (in the internet zone).
Back when the ActiveX plugin model was created (1996), the internet was a very different place.
The signing requirement was thought to make a difference (since it blocked arbitrary binaries). What Microsoft didn't realize was that the bad guys just had to find a control with a security vulnerability in it (and there are thousands of controls with security vulnerabilities), host it on their site and ask the browser to load the vulnerable control - the signing requirement wasn't as useful as people though.
Because of this, Microsoft has steadily increased the restrictions on ActiveX controls, adding things like site lock (an ActiveX control can indicate that it only works on a particular site), running the ActiveX controls in a sandbox, adding a killbit list to block vulnerable controls, etc..
The IE team can't get rid of ActiveX controls because of the staggering number of sites that rely on them (apparently the South Korean banking industry is completely dependant on ActiveX controls not to mention the number of intranet sites that depend on them).
Re: (Score:2)
Ah, thank you that does make much more sense. I certainly don't envy Microsoft's legacy commitments.
Re: (Score:3)
If you read this [msdn.com] article from the IE blog (from 2005), they claim that ActiveX plugins run in a sandbox. The MSDN documentation for low rights IE [microsoft.com] has similar contents.
Re: (Score:2)
On Windows XP, there are effectively no differences between ActiveX and NPAPI - plugins carry the same risks. For Windows Vista and Windows 7, ActiveX plugins run in the IE "sandbox" which runs with restricted access to the desktop (it's called "low rights IE"). Since Firefox doesn't support a restricted access sandbox (yet), NPAPI plugins are thus more dangerous since they can instantly do anything that the user can do (ActiveX controls need to break out of the sandbox first). Note that in some cases, t
Re: (Score:1)
ActiveX is not limited to IE, Windows and other MS programs use them extensively as well even 3rd-party programs (not even meant for IE use either). The problem with IE/6 is that it allows ActiveX controls not meant to be used in IE used in IE, MS regularly releases killbit updates that are a list of ActiveX controls not allowed to run in IE. Drive-by exploits instantiated vulnerable Windows ActiveX controls not meant for IE a lot and able to execute code without the user having to do anything other than vi
Well this is disappointing (Score:2)
Re: (Score:1)
They have to. Too many corporations (and in some cases government services) running the stupid things without budget to upgrade to something more standard.
Re: (Score:2)
Yep, unfortunately idiot companies are still to this day building web interfaces for security cameras that require ActiveX. I mean if you have to use a shitty proprietary solution, at least use Flash.
Re: (Score:2)
Re: (Score:2)
Only because Flash basically runs on top of ActiveX in IE. ActiveX wouldn't be required if IE used a different plugin architecture.
Re: (Score:2)
If Microsoft turned it off... The corporations and governments would find the budget. That should be the penalty for using ActiveX anyways.
Re: (Score:2)
I have yet to see a plugin for FireFox/Chrome/etc that allow tight intranet integration.
Kind of a functionality requirement.
Disappointing (Score:3, Funny)
'ActiveX content may prevent you from having a good experience viewing a Web site'"
Since I define a good experience as having at least 3 unknown, untrusted executables run in the background, doing god knows what, with only routine prompting.... I am highly skeptical about the improvement.
Now my users are going to have to go to the tried and true old fashioned way of getting their computers' infected. Clicking the executable, and then hitting the 'Run' button, or Saving first.... And Windows 7 was being touted as 'user firendly'...feh. :(
<eg>
Re:Disappointing (Score:5, Insightful)
Don't worry, every time Microsoft plugs one hole, they add another for legacy services.
For example, look at the workarounds for installing various types of ActiveX controls -- without prompting -- on this page.
http://msdn.microsoft.com/en-us/library/cc721964(v=ws.10).aspx [microsoft.com]
Or read this page about starting elevated executables from within ActiveX -- again, without prompting.
http://msdn.microsoft.com/en-us/library/bb250462(v=vs.85).aspx#wpm_elebp [microsoft.com]
Now consider the following: on Vista and Win7, all of the registry values described on these pages can be set from within the ActiveX installer itself! In other words, you can write an ActiveX component that installs, runs, and performs IPC with elevated processes. And the user will have no idea.
So if Microsoft keeps up their practice of adding holes while they plug others, then rest assured that you'll be able to continue your practice of installing viruses with minimal hassle.
Re: (Score:2)
Before anybody asks, all the the above post is speaking from firsthand experience. Unfortunately.
Re: (Score:2)
Define "low level." The ActiveX control I created was signed, which automatically gives it certain powers. There is a point during the install process during which the DLL gets hooked into the installer service and you have write access to an alarmingly large portion of the registry. It's not a documented feature as far as I was ever able to tell.
The product I worked on was canceled, afaik, so I can't send you a link to it. But it's not like I invented all of this myself.
Re:Disappointing (Score:4, Insightful)
Re: (Score:2)
Sure, but that's not the point -- the point is they made all these security features, then told you exactly how to work around them right there on MSDN.
Why did they bother?
Re: (Score:2)
They're telling the administrator of the PC how to work around them. That's a good thing surely?
Re: (Score:2)
You're missing a key point: namely that the ActiveX control itself can change these settings.
Re: (Score:2)
Re: (Score:1)
I'll take Javascript over flash any day.
At least Javascript is cross-browser.... [when it doesn't improperly use IE-specific extensions]
Comment removed (Score:3, Funny)
Microsoft Virus Installer (Score:2, Flamebait)
ActiveX really is like Microsoft Virus Installer. For legacy reasons it requires elevated privileges to install, which is pretty much the opposite of a sandbox.
Leave it to Microsoft to screw up something to simple.
Re:Microsoft Virus Installer (Score:5, Informative)
Explain, in detail the differences between ActiveX and any Mozilla extension with a compiled binary XPCOM component or any nsplugin api based plugin.
Not the implementation specific but the flow of how they work.
I'm afraid you'll find that ActiveX is really no different than any other plugin system.
The problem is that ActiveX is more or less a GLOBAL, system wide plugin system versus a web browser specific api like nsplugin.
IE previously had serious problems because it would allow ActiveX controls to be downloaded and installed in a multitude of ways sometimes with the user being prompted, but due to bugs it also happened without the user ever being prompted. It defaulted to allow in early version as well, which of course is the exact wrong thing to do.
Add too that the high number of ActiveX controls that incorrectly had themselves flagged as safe to be used by websites and you have a horrible implementation ... several years ago.
Badly written ActiveX controls much be registered globally, requiring admin to install it, however properly written ActiveX controls are happy to install themselves on a per user basis. As long as you are warned and given the option to say no, there is no issue, it gives the user a way to make it work without having to go to command line to register the component or finding a gui tool to do it.
The overall features provided by ActiveX surpass pretty much every other plugin system currently implemented, they are essentially self describing DLLs that contain everything needed for any random developer to use, no source code required (which of course OSS fans don't appreciate but thats another story entirely).
Unfortunately, even with the extra things built into ActiveX (like the ability to flag it as unsafe for use in untrusted environments like a web browser, Microsoft fucked up the original implementation and didn't fix it for years, and then it took them several years to make it actually fix all of the major problems.
ActiveX controls no longer install without multiple clicks of user interaction. Its easier to get owned with a gecko based application such as Firefox or Thunderbird than it is with IE, it takes fewer clicks.
Yes, there are a lot of shitty, broken ActiveX controls, no argument there, but to say 'ActiveX is bad' is like saying 'plugins are bad' because thats all they are.
Microsoft has COM, which ActiveX is built on (And the entire .NET framework as well), Mozilla uses XPCOM, and you can generate code for both from the same IDL file if its fairly simple.
Re:Microsoft Virus Installer (Score:5, Insightful)
Badly written ActiveX controls much be registered globally, requiring admin to install it, however properly written ActiveX controls are happy to install themselves on a per user basis. As long as you are warned and given the option to say no, there is no issue, it gives the user a way to make it work without having to go to command line to register the component or finding a gui tool to do it.
Here's the problem I have with this statement. Sure, you can write secure ActiveX if you know what you're doing. But in my experience, most still-being-written ActiveX code seems to be put together by poorly trained coders who, back in 2003, took a 2-day free Microsoft course "how to quickly and easily write intranet apps" and who have never updated their skillset since then. Those intranet developers who HAVE updated their skills stopped using ActiveX when it became obvious that being tied to IE-only development was not a good long-term strategy for numerous reasons - everything they've done in the last several years has been more of a LAMP-style model (even if it's on a Windows server with MS SQL behind it) that works with any reasonably recent client browser and doesn't treat HTTP as just a delivery platform for transferring Windows applications from server to desktop.
Re:Microsoft Virus Installer (Score:4, Insightful)
I think you're missing the point here -- ActiveX was built to do things that it should never have been allowed to do, and with minimal user interaction.
Microsoft encourages writing a "proper" ActiveX control, sure. But your boss will not. Why? Because that "proper" control means more warnings for the user, and more warnings are bad for business. What you're referring to as a "broken" ActiveX control is a "perfect" ActiveX control to the guys in suits.
Re: (Score:1)
Re: (Score:2)
...they crawl on mine.
NoScript (Score:2)
This may be a dumb question (IANAWD), but does this also block javascript from the same site? If so, it seems like MS is making the basic features of NoScript available to IE users. Seems like a good idea to me. With this I might not hate IE9 that much as long as they move the home, stop and refresh buttons back to a sane location.
Re: (Score:3)
I wouldn't care about this myself if I didn't have to support IE for people who absolutely must use it.
Re: (Score:2)
No, Javascript is not an ActiveX plugin.
How Slashdot perceives things (Score:2, Interesting)
Slashdotters on Google Native Client: "Native code running in the browser is the future! I can't believe this. It's amazing! Google rocks."
Slashdotters on ActiveX: "Haha, even Microsoft is adding a way to turn off ActiveX. It sucks. Look at that caption saying it can interfere with a webpage! Hahaha! Who ever thought native code in the browser was a good idea?"
Re: (Score:2)
Google Native Client has a code verifier and requires the use of a custom version of the C library.
So while it might potentially have negative consequences, Google has learned from the mistakes of ActiveX.
Re: (Score:1)
A custom C library doesn't matter, if its 'native code' the C library is irrelevant as you're producing x86 machine code in the final NCI file.
To be safe, they essentially need to run it in a virtual machine without access outside the VM.
x86 code verifiers are about as useful as enabling heuristics detection in a virus scanners, the only thing they catch is something thats already more or less been seen in the exact same sort of form.
Re:How Slashdot perceives things (Score:4, Informative)
Re: (Score:1)
A code verifier is certainly effective when it refuses to run the assembly upon finding unsafe opcodes. That's precisely why Native Client requires a custom compiler, and is why NaCl binaries are slower compared to regular native binaries.
As if that's not enough, the processes are then chrooted on Linux, and are assigned a null token on Windows & run under low-integrity mode.
Re: (Score:3)
A custom C library doesn't matter, if its 'native code' the C library is irrelevant as you're producing x86 machine code in the final NCI file.
To be safe, they essentially need to run it in a virtual machine without access outside the VM.
x86 code verifiers are about as useful as enabling heuristics detection in a virus scanners, the only thing they catch is something thats already more or less been seen in the exact same sort of form.
Maybe you should read up a bit on it [google.com] before you make stupid comments. Their code verifier doesn't scan for known attacks (antivirus-style). Instead, Google has identified a subset of instructions which, when run in a specific sandboxed environment, eliminate the ability for the code to perform malicious activities. One pruning of the instruction set removes instructions that enable code to hide from the verifier (alignment requirements, removal of register jumps, etc.). The second constrains the instruction
Re: (Score:2)
But you can never prove that code is not going to smash the stack. Or the context that I'll be in, when that happens.
Re: (Score:2)
Running anything other than HTML, CSS, and JavaScript in the browser is antiquated and impractical.
If you want to run native code, there are native windows for that.
Re: (Score:2)
Re: (Score:3)
It's even worse since it also goes:
Android on Choice: "Let the user choose what programs and features they want to run? Yay freedom!"
Microsoft on Choice: "Option to turn feature on? Users are too stupid to be trusted with extra features!"
Re: (Score:1)
It's even worse since it also goes:
Android on Choice: "Let the user choose what programs and features they want to run? Yay freedom!" Microsoft on Choice: "Option to turn feature on? Windows Users are too stupid to be trusted with extra features!"
Fixed that for you...
Re: (Score:2)
GNOME on Choice: "Option to turn feature on? Users are too stupid to be trusted with extra features!"
Fixed that for you...
Re: (Score:2)
The difference is that ActiveX is allowed to do anything it likes, Google Native Client is sandboxed and limited.
Re: (Score:1)
Quote:
"Because Native Client runs within its own sandboxed execution space and validates executable modules against a special set of rules designed to protect the resources on the user's system, it offers the safety of traditional web apps in addition to its native performance benefits."
Re: (Score:1)
Re: (Score:2)
O RLY? (Score:2)
No matter how hard you try, HTML5 and JavaScript will never be able to simulate large 3D environments, regardless of any browser enhancements made over the next 10 years.
Good thing nobody told that to these guys:
http://en.wikipedia.org/wiki/WebGL [wikipedia.org]
http://www.youtube.com/watch?v=Vva36undIss&feature=related [youtube.com]
Re: (Score:2)
"Simulating" can mean a lot of things. I can simulate a ball bouncing in a large transparent box at 1/10th speed and that will be a simulated large 3D environment. That shouldn't bog down a JS engine too much.
Re: (Score:2)
There's a markup standard called W3C HTML5 with 100% deployment on every platform. There's an audio video standard called ISO MPEG-4 with 100% deployment on every platform. There's a photo standard called ISO JPEG with 100% deployment on every platform. Every PC, smartphone, and set-top comes out of the box with support for all of these standards and more. The ISO standards are hard coded into every GPU. The only issues are with legacy devices, but HTML5 provided many ways to deal with that until time takes
I thought ActiveX died (Score:2)
Like -- in iE7 or something?
At least I haven't encountered it in years.
Re: (Score:3)
ActiveX is the plugin mechanism for IE - they haven't replaced that yet, and it's not like they would replace it with the NPAPI [wikipedia.org] mechanism used in Firefox, Chrome et al.
Wow! (Score:1)
C'mon guys, give them a break... it's not like other browsers have supported this for, I dunno, five years, because they put the user in charge instead of the content providers... Right?