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

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.

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

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

Comment removed

[account_deleted]

Comment removed based on user account deletion

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.

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

[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

[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

[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: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: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: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: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: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: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: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: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).