Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Internet Explorer Microsoft

Microsoft Adds Selective ActiveX Filtering to IE9 94

Posted by Roblimo
from the yet-another-icon-in-the-address-bar dept.
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'"
This discussion has been archived. No new comments can be posted.

Microsoft Adds Selective ActiveX Filtering to IE9

Comments Filter:
  • I didn't realise Flash was an ActiveX control.
    • Re:Flash? (Score:5, Informative)

      by game kid (805301) on Monday February 28, 2011 @10:46PM (#35344566) Homepage
      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: (Score:2, Interesting)

      by 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? (Score:5, Interesting)

        by shutdown -p now (807394) on Monday February 28, 2011 @10:56PM (#35344626) Journal

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

        • Re: (Score:3, Insightful)

          by yuhong (1378501)

          I wonder how many bash ActiveX without realizing this.

          • Re:Flash? (Score:4, Insightful)

            by shutdown -p now (807394) on Monday February 28, 2011 @11:14PM (#35344708) Journal

            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)

              by LO0G (606364) on Monday February 28, 2011 @11:42PM (#35344842)

              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.

              • by Warll (1211492)

                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)

                  by LO0G (606364) on Tuesday March 01, 2011 @12:36PM (#35348852)

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

                  • by Warll (1211492)

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

        • by LO0G (606364)

          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.

      • by LO0G (606364)

        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

      • by 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 vi

  • Microsoft was doing so great on their new feature set for IE9 up until they listed the ability to turn ActiveX back on.
    • by 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.

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

        • Which is ActiveX in Internet Explorer... so... that would still require ActiveX....
          • Only because Flash basically runs on top of ActiveX in IE. ActiveX wouldn't be required if IE used a different plugin architecture.

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

    • by Bengie (1121981)
      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.
  • by mysidia (191772) on Monday February 28, 2011 @10:47PM (#35344572)

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

      by MrEricSir (398214) on Monday February 28, 2011 @11:11PM (#35344694) Homepage

      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.

      • by MrEricSir (398214)

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

      • Re:Disappointing (Score:4, Insightful)

        by vistapwns (1103935) on Tuesday March 01, 2011 @01:13AM (#35345300)
        "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.
        • by MrEricSir (398214)

          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?

          • by Tim C (15259)

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

            • by MrEricSir (398214)

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

          • 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 ca
  • by cozzbp (1845636) on Monday February 28, 2011 @10:48PM (#35344574)
    who just takes a crap on every product before it's released? It sure seems that way...
  • 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.

    • by BitZtream (692029) on Monday February 28, 2011 @11:34PM (#35344794)

      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.

      • by 93 Escort Wagon (326346) on Tuesday March 01, 2011 @12:41AM (#35345148)

        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.

      • by MrEricSir (398214) on Tuesday March 01, 2011 @01:04AM (#35345260) Homepage

        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.

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

    • by jack2000 (1178961)
      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. :\
    • No, Javascript is not an ActiveX plugin.

  • 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?"

    • by MrEricSir (398214)

      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.

      • by BitZtream (692029)

        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.

        • by Simon80 (874052) on Monday February 28, 2011 @11:51PM (#35344898)
          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 [chromium.org]
        • by 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.

        • by Jahava (946858)

          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

          • by bytesex (112972)

            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.

      • by gig (78408)

        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.

    • 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!"

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

      • by Nutria (679911)

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

        Fixed that for you...

    • by jonwil (467024)

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

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

    • by washort (6555)
      Ignorance on parade.
    • by shaper (88544)
      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 r
      • by gig (78408)

        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

  • Like -- in iE7 or something?

    At least I haven't encountered it in years.

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

  • by mordejai (702496)

    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?

We don't know who it was that discovered water, but we're pretty sure that it wasn't a fish. -- Marshall McLuhan

Working...