Microsoft Adds Selective ActiveX Filtering to IE9

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'"

Comments

Flash?

[SilverHatHacker]

I didn't realise Flash was an ActiveX control.

Re:Flash?

[game kid]

For IE, it is. For others it's a NS plugin thingy. The plugin and control are separate downloads but otherwise work much the same way once installed (except maybe tech details like wmode or IE9 hardware surface support or such).

Re:Flash?

[Anonymous Coward]

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?

[shutdown -p now]

Both extensibility models run non-sandboxed native code on your machine. In either case, security is zero.

Re:Flash?

[yuhong]

I wonder how many bash ActiveX without realizing this.

Re:Flash?

[LO0G]

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, the IE sandbox is disabled (for instance it's disabled in the local machine zone and for intranet sites).

The original Chrome sandbox only applied to its rendering and JS engine, plugins like flash ran with full access to the desktop. However I believe that Chrome's current extension model runs most extensions in its sandbox as well (I'm not 100% sure - the wikipedia page for chrome is ambiguous on this).

A sandbox acts as a defense-in-depth feature, like data execution protection and ASLR. In general, the more of these features which are enabled, the safer you are when browsing the web.

Re:Flash?

[shutdown -p now]

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?

[LO0G]

If you read this article from the IE blog (from 2005), they claim that ActiveX plugins run in a sandbox. The MSDN documentation for low rights IE has similar contents.

Re:Flash?

[LO0G]

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:Flash?

[Anonymous Coward]

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 visiting a webpage.

Re:Flash?

[Warll]

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?

[LO0G]

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:Flash?

[Warll]

Ah, thank you that does make much more sense. I certainly don't envy Microsoft's legacy commitments.

Well this is disappointing

[scourfish]

Microsoft was doing so great on their new feature set for IE9 up until they listed the ability to turn ActiveX back on.

Re:Well this is disappointing

[Anonymous Coward]

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:Well this is disappointing

[Bengie]

Plugins work great on the internet, but ActiveX is more of an intranet thing.

I have yet to see a plugin for FireFox/Chrome/etc that allow tight intranet integration.

Kind of a functionality requirement.

Re:Well this is disappointing

[GameboyRMH]

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:Well this is disappointing

[jellomizer]

If Microsoft turned it off... The corporations and governments would find the budget. That should be the penalty for using ActiveX anyways.

Re:Well this is disappointing

[kevinmenzel]

Which is ActiveX in Internet Explorer... so... that would still require ActiveX....

Re:Well this is disappointing

[GameboyRMH]

Only because Flash basically runs on top of ActiveX in IE. ActiveX wouldn't be required if IE used a different plugin architecture.

Disappointing

[mysidia]

'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

[MrEricSir]

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

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

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:Disappointing

[MrEricSir]

Before anybody asks, all the the above post is speaking from firsthand experience. Unfortunately.

Re:Disappointing

[MrEricSir]

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

[vistapwns]

"the ActiveX Installer Service checks whether the URL requesting the ActiveX control installation is approved in Group Policy." The URL has to be approved (by the administrator of the PC) before active-x can be auto-installed. You did know this right? The second link talks about making your own broker process to bypass IE sandbox, but you need again code running (and authorized by the user) on the box first.

Re:Disappointing

[MrEricSir]

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:Disappointing

[Tim C]

They're telling the administrator of the PC how to work around them. That's a good thing surely?

Re:Disappointing

[vistapwns]

Like the other guy said, it's a good thing for the Admin to be able to bypass this security when and where he needs to. The point of these protections is to prevent unwanted code on the internet from running on the user's box. And they do that just fine. BUT if the Admin wants to make exceptions for specific sites (for corporate intranet sites that need this or whatever) then he can, but that's all. Normally, without an Admin setting an exception in group policy, active-x can not auto-install and you can not bypass the IE sandbox. Not sure how much more clear I can make this...

Re:Disappointing

[MrEricSir]

You're missing a key point: namely that the ActiveX control itself can change these settings.

Re:Disappointing

[mysidia]

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

[account_deleted]

Comment removed based on user account deletion

Microsoft Virus Installer

[MrEricSir]

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

[BitZtream]

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

[93 Escort Wagon]

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

[MrEricSir]

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:Microsoft Virus Installer

[kevinmenzel]

XP has back doors? If only Microsoft would release a new version of the OS with some of those blocked. OH WAIT. THEY DID. TWICE. Not to mention that if they ever say, included the functionality of say MS Security Essentials in the OS, well, they would never be allowed to because OMG monopoly.

NoScript

[slinches]

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:NoScript

[jack2000]

The basic features of NoScript exist for IE since forever, you can define custom levels of trust for stuff like Javascript, cookies and ActiveX per zones, you can stick sties into trusted and untrusted with variety of customization for each. It's just that getting to that and configuring it is going to be hectic for joe6pack and no one has noticed it.

I wouldn't care about this myself if I didn't have to support IE for people who absolutely must use it. :\

Re:NoScript

[dakameleon]

No, Javascript is not an ActiveX plugin.

How Slashdot perceives things

[bonch]

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:How Slashdot perceives things

[MrEricSir]

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:How Slashdot perceives things

[im_thatoneguy]

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:How Slashdot perceives things

[BitZtream]

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

[jonwil]

The difference is that ActiveX is allowed to do anything it likes, Google Native Client is sandboxed and limited.

Re:How Slashdot perceives things

[Simon80]

Code verification in this context doesn't imply an attempt to understand the intent of code before running it. Rather, they verify that the code sticks to a safe subset of possible operations that effectively sandbox it out of being able to do anything nasty. They seem to have thorough design documentation on their wiki. I have no prior familiarity with NaCl, but this seems like an appropriate page to look at: http://www.chromium.org/nativeclient/design-documents/nacl-sfi-model-on-x86-64-systems

Re:How Slashdot perceives things

[Anonymous Coward]

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:How Slashdot perceives things

[Anonymous Coward]

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:How Slashdot perceives things

[Jahava]

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 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 set, removing things like direct system calls, far jumps, etc.

The system also uses x86 segmentation capabilities to enforce a specific sandboxed execution environment. Doing this implicitly limits the scope of the code's branching and allows the verifier to make some critical assumptions that validate the assembly.

Rather than reproduce the paper, you should check out the link that I provided. Regardless, to say that the code verifier is not adequate is just foolish. The papers clearly explain, using logical proofs, how the various constraints enforced by the NaCl runtime, sandboxes, and code verifier are enforceable and provide reliable security. The "custom C library" is used in conjunction with the constraints to retain a general usefulness, facilitate inter-process communication (the primary mechanism of action), and work within NaCl constraints to perform higher-level operations like system calls.

Re:How Slashdot perceives things

[shaper]

Not all of us. IMHO, native code in the browser is still a bad idea and an unnecessary one at that, regardless of who is doing it, Microsoft or Google. The state of the web is progressing very nicely without introducing potential security problems and platform dependencies. And yes, Google Native Client is platform specific to both hardware and OS. There are a few potential hiccups looming with (the language formerly known as) HTML5 and standard technologies like video codecs. But I'd still rather go that route than just go native.

Re:How Slashdot perceives things

[gig]

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:How Slashdot perceives things

[gig]

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 care of it for good. For example, you provide fallback content for modern tags in your markup and you play ISO media in FlashPlayer or QuickTime Player on PC's with IE6-IE8 or Firefox. You still have 100% support.

So there is no need for running native code in the browser.

Re:How Slashdot perceives things

[Nutria]

GNOME on Choice: "Option to turn feature on? Users are too stupid to be trusted with extra features!"

Fixed that for you...

Re:How Slashdot perceives things

[bytesex]

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:How Slashdot perceives things

[hairyfeet]

And I can see their point as JavaScript sucks security wise. lets be honest folks all these hacks like NoScript and sandboxing is just bandaids on bullet wounds, when what we need is either to rewrite JavaScript from the ground up with a focus on security or come up with a new language that allows the features we have come to depend on without having the wide latitude that we have with JavaScript.

I mean it is pretty sad that by just blocking JavaScript ads with ABP I cut my customers infection rate by a good 70%+ and if I add NoScript to that their risk of infection drops to practically nothing. I have a feeling we are gonna end up with the JavaScript equivalent of Code Red and then we'll have to find something else to use on websites because folks will simply kill JavaScript the way they don't use ActiveX anymore.

It is frankly just getting too risky to allow much JavaScript and while I feel sorry for website owners when so much malware comes in via JavaScript ads it simply isn't wise to allow them at all.

I thought ActiveX died

[bedouin]

Like -- in iE7 or something?

At least I haven't encountered it in years.

Re:I thought ActiveX died

[dakameleon]

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 mechanism used in Firefox, Chrome et al.

Re:"Web pages run on your PC"

[ThePromenader]

...they crawl on mine.

Re:1st post

[andrea.sartori]

You are a moron.

O RLY?

[GameboyRMH]

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

http://www.youtube.com/watch?v=Vva36undIss&feature=related

Re:O RLY?

[GameboyRMH]

"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.

Wow!

[mordejai]

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?