IE8 Security Part II: ActiveX Improvements

Hi, I’m Matt Crowley, Program Manager for Extensibility with Internet Explorer. The team was very excited to be at the RSA security conference last month discussing the security features of Internet Explorer 8 Beta 1. In this, the second part of the IE8 Security blog series, I describe the ActiveX improvements in IE8 and summarize the existing ActiveX-related security features carried over from earlier browser versions.

Per-User (Non-Admin) ActiveX

Running IE8 in Windows Vista, a standard user may install ActiveX controls in their own user profile without requiring administrative privileges. This improvement makes it easier for an organization to realize the full benefit of User Account Control by enabling standard users to install ActiveX controls used in their day-to-day browsing.

If a user happens to install a malicious ActiveX control, the overall system will be unaffected, as the control was installed only under the user’s account. Since installations can be restricted to a user profile, the risk and cost of compromise (and, in turn, the total cost of administering users on a machine) will be lowered significantly.

Per-User ActiveX was designed with compatibility in mind—most existing ActiveX controls will not have to be rewritten to benefit from this feature; the only change will be repackaging. As in Internet Explorer 7, when a webpage attempts to install a control, an Information Bar is displayed to the user.

IE8 Information Bar prompt when a webpage attempts install of an ActiveX control

By clicking on the information bar, users can choose to either install the control machine-wide, or install it only for their own user account. The options in this menu will vary depending on the packaging of the control and the rights of the user.

The available options depend on Group Policy settings for per-user ActiveX installations and whether or not the control has been packaged to allow per-user installation.

IE8 Information Bar menu to install an ActiveX control

While this feature offers the possibility of lowering total cost of ownership, IT Administrators running managed environments may elect to disable this feature via Group Policy. For more information regarding Per-User ActiveX, please refer to the Non-Admin ActiveX Controls article in MSDN’s IE8 Beta 1 Whitepapers.

ActiveX Opt-In

Recognizing that any binary extensibility mechanism increases attack surface, ActiveX Opt-In was introduced with Internet Explorer 7.

By default, ActiveX Opt-In disables most controls on a user's machine. When the user encounters a Web page with a disabled ActiveX control, they will see an Information bar with the following text: "This website wants to run the following add-on "ABC Control" from "XYZ Publisher". If you trust the website and the add-on and want to allow it to run, click here …" The user can then choose to enable the ActiveX control from this Information bar.

ActiveX Opt-In allows some controls to run by default:

  • A small list of common controls intended for use in the browser.
  • Controls which were used in IE on a user’s machine before upgrading to IE8.
  • Controls which are installed through IE.

For more information on ActiveX Opt-In, please refer to the MSDN Article Best Practices for ActiveX.

Per-Site ActiveX

When a user navigates to a Web site containing an ActiveX control, IE8 performs a number of checks, including a determination of where a control is permitted to run. This check is referred to as Per-Site ActiveX, a defense mechanism to help prevent malicious repurposing of controls. If a control is installed, but is not permitted to run on a specific website, an Information Bar appears asking the user whether or not the control should be permitted to run on the current website.

IE8 Information Bar prompt to authorize run of an installed ActiveX control

Users can use the Information bar to allow the control for a specific Web site or allow the control for all Web sites.

IE8 Information Bar menu to authorize run of an installed ActiveX control

IT Professionals administering a system of computers running Internet Explorer 8 may choose to preset allowed controls and their associated domains. Such settings can be configured using Group Policy.

For more information regarding Per-Site ActiveX, please refer to the Per-Site ActiveX article in MSDN’s IE8 Beta 1 Whitepapers.

Enforcing Per-Site with ATL SiteLock Technology

If your ActiveX control is designed for use only on your web site, then locking it to the domain of that Web site will make it harder for other sites to repurpose the control in a malicious manner. See Developing Safer ActiveX Controls Using the Sitelock Template for more information.

Reducing Exploit Risk with DEP/NX, “Killbits,” and Servicing

Working with your processor and Windows, IE8 helps reduce the exploitation of vulnerable controls through Data Execution Prevention. See the previous post in this series, IE8 Security Part I: DEP/NX Memory Protection, for more information on how to ensure that your ActiveX controls are DEP/NX compatible, as well as information on how to opt-in to other available protections.

If a vulnerable control has been exploited, IE has included a poison-pill option—the “killbit”— to block usage of specific controls within the browser. Vendors who are aware of a vulnerability in their control should contact Microsoft to setup a killbit for a future software update package. For more information, please refer to Knowledge Base article 240797, How to stop an ActiveX control from running in Internet Explorer.

As with standard desktop software, it is important to keep controls up-to-date to ensure compatibility with newer systems and lower the risk of compromise through evolving security threats. For more information on updating ActiveX controls, please refer to the IE Blog entry Good Practices for ActiveX Updates.

Working with Users through Manage Add-Ons

While most end users aren’t aware of the inner-workings of ActiveX controls or their enterprise policy on them (if applicable), users are able to find out information about the controls installed for use in Internet Explorer through Manage Add-Ons. It is important for developers to ensure that their controls are not only performant and secure, but also open in the information they provide.

Controls are identified by Name, Publisher, Version, and Class ID within the Manage Add-Ons interface. Given this, control developers are encouraged to include this metadata in release builds of their controls.

For more information on making sure that your ActiveX control properly conveys information about itself to users, please refer to Christopher Vaughan’s post Add-on Management Improvements in Internet Explorer 8 as well as the MSDN Article Best Practices for ActiveX.

Thanks for your help in ensuring your ActiveX controls are secure!

Matthew David Crowley
Program Manager
Internet Explorer Extensibility

Comments (65)

  1. anony.muos says:

    All these security improvements for XP and Vista users while other Windows versions don’t even get the core improvements made in IE6 for XPSP2. It’s still possible in IE6SP1 to malware to silently install an ActiveX control. Although the marketshare of these operating systems is negligible, it makes no sense supporting IE6SP1 or IE5 SP4 because anyways they’re so insecure, users of these OSes will be forced to use an alternative browser.

  2. jes says:

    ActiveX Improvements is nice can we also have the option to temporary install an activeX add-on then when we close the IE browser it delete or disable the add-on. In standard user account (non-admin in Vista) when user choose to "install this add-on for all user on this user" will they be prompted with a UAC password.

    The Favorites Bar is nice but can you also add a search favorite or search commands functionality so user can find what ever they want in IE 8 User interface. Something similar to the office 2007 search command add-ins.

  3. Mark Sowul says:

    Wow, per-user ActiveX – that’s pretty huge (and arguably how it should have been done since the beginning).  

  4. PS says:

    I will agree that it could have been done from the beginning, but we should remember the first environment that IE was developed for… the Win9x environment.

    In any case I’m happy to see something like this, please continue making our life (as sysadmins) a bit easier!!

  5. It’s good that IE 8 has this feature. Improving the security measures on the Internet is a very good idea. Internet security nowadays are at risk since hackers are always ready to do their unpleasant doings. There are many preventive measures, all we have to do is follow what is right.

  6. Mike says:

    Will this feature be enabled for XP users as well?


    Running IE8 in Windows Vista, a standard user may install ActiveX controls in their own user profile without requiring administrative privileges


    This makes it seem like it won’t but a definate answer would be awsome.

  7. mattcrow [msft] says:

    @Mike: The per-user ActiveX feature is for Vista and higher.

  8. Andreas Lanjerud says:

    Does this work without "Emulate IE7" too?

  9. Mitch 74 says:

    And what, pray tell, prevents per-user ActiveX to be implemented in XP?

    Oh, sorry: limited user accounts in XP are unusable anyway; it would have worked with Win 2000 (which has working ‘advanced users’ accounts), but since Win 2000 is stuck with IE 5 and 6 (at best) anyway…

    I guess then that users of Win XP will just switch to other browsers that allow user-level extensions and plugin installations, and get rid of ActiveX altogether.

    If they haven’t already done so.

    You do realize that this ‘great security improvement’ can only be used to demonstrate how ANCIENT IE actually is? I mean, program a Firefox extension today, it already works as a user level extension only, works with all OS version supported by Firefox (from win9x to Vista), and as long as it doesn’t make use of assembly language or OS dependent features (relying on Gecko’s CSS, HTML and Javascript engine), can run ANYWHERE Gecko has been ported, and in the browser’s context?

    What’s left to implement is an independent Javascript engine (but then, Chris Wilson protested the Mozilla’s foundation attempt at writing one that could be plugged into IE, so, either you’re arrogant, or you’re not planning to do that), and you’d get a browser mostly unstuck from the OS, and the ability to improve it again.

    Remember that XP just got a new lease on life, due to Vista being too bloated to run on machines that are all the rage today: UMPCs. So, spending time improving ActiveX just for Vista is of little to no interest, especially when your competitors are going at these new markets aggressively:

    – Firefox 3 got a smaller footprint than version 2, making it eligible to run on very small devices;

    – Opera already is there;

    – KHTML/Webkit are geared to go that way too.

    What browser do you want to see outside the desktop? If people spend more time with their mobile devices, and notice that they can keep the same browser in and out of their desktop machine, and cumulate it with nice stuff like roaming browser preferences (yes, it exists for at least Firefox, hosted by Google), what’s getting more interesting? IE 8, glued to costly, underperforming machines, or Firefox/Webkit/Opera that you can bring with you?

    If separating first rendering contexts, then ActiveX from the core OS is part of a strategy to unglue IE from Windows, it’s really good, congrats!

    If not, pfeh.

  10. rdavl says:

    First of all you should all burn in hell for ever making Internet Explorer 6 and any kind of Active X…

    And as for the security concerns with Active X, how can you patch up something that is fundamentally flawed!?

    Get rid of the IE and make windows installs with FF or something, links even ffs.

    Or buy opera and name it IE but just make it work for F+ sake!

  11. fr says:

    The earlier suggestion of temporary activex would be good, there are occasions where I would like to use something which requires activex but am unlikely to need it again.

  12. killbits question says:

    I have to question the real value of killbits. If the vendor knows there’s a vulnerability in their Active-X tool wouldn’t it make more sense for them to just patch the vulnerability itself unless the vulnerability is required for the add-on to work right? They’d probably have to be close to being able to patch it if they were going to come up with a killbit that wouldn’t break their add-on since there’s no reason to swallow the pill if it’s working fine.

    From my viewpoint, which I’ll admit isn’t as a security expert or researcher in any way, it looks like the killbits only real value would be as a temporary fix while the group responsible for the add-on patches the vulnerability, but even then that assumes that a windows update including the kill bit will come out before the team can fix their problem. The other possibilities I can think of are use the killbit on an add-on that needs something that creates the vulnerability to work, just patch it w/o the killbit if it will still work, or completely ignore this if the add-on will not work without the vulnerability and having a killbit stop the add-on from working is not a possibility.

    Either they know enough about the vulnerability to patch it if they’re going to set a unobtrusive killbit or the add-on will not work if it’s patched or has a killbit set. Is there some middle ground I’m missing here, not counting the set up of an obtrusive killbit?

  13. User Access Control - Huh? says:

    Re: "Running IE8 in Windows Vista, a standard user may install ActiveX controls in their own user profile without requiring administrative privileges"

    So what you are telling us, is that although IT has locked down what you can do on your PC, you can now in fact evade those security measures and install all the spyware infected "CoolSearch", "MyWay", "BonziBuddy", "360" toolbars you want now.

    Can’t wait to see how the IT Crowd responds to this when the news gets out.

  14. SamY says:

    @User Access Control – Huh?

    What part of "While this feature offers the possibility of lowering total cost of ownership, IT Administrators running managed environments may elect to disable this feature via Group Policy." do you not understand?

  15. Dave says:

    I’d really like a solution where I don’t have to train every user to decide whether to trust an add-on.

  16. Marshall says:

    @@killbits question: The problem is that a bad guy could save a copy of the buggy/signed AX control on his server and offer to install it from his page.  Without a killbit, the buggy old version can be installed & run.

    Anyone claiming that Firefox’s model is somehow magically better than ActiveX doesn’t really understand Firefox’s NPAPI plugin model.

  17. Killbits says:

    Thanks for the reply. I had not thought of that. How easy/hard is it for someone to do that, and how easy/hard is it to install an older version of an add-on over the newer one?

    I’ve never actually let an active-x thing download/run on my machine and take the view of, if your site needs it, I don’t need your site; because of this I have not had enough exposure to know the difficulty of setting up the exploit you mention above. I’ll fully admit it’s a good reason for killbits I didn’t think of, but knowing the difficulty level of the exploit and therefore how many people could actually use it is important for determining how big the problem being fixed is.

  18. IE Team describes the ActiveX improvements in IE8 and summarize the existing ActiveX-related security

  19. bond says:

    "Running IE8 in Windows Vista, a standard user may install ActiveX controls in their own user profile without requiring administrative privileges"

    An ActiveX improvement means going back the old xp way user will fall victim on malicios activeX. I feel it’s a Bad choice to allow a standard user to install activeX control without requiring administrative privileges. Sure the overall system will be unaffected if standard user install a malicious ActiveX control but you’re putting inexperienced user (kids, mothers…Etc) at risk and to be an easy target for dangerous active X. Right now I don’t like that admin(possibly home user)have to go through Group Policy to disable this feature I think If you are going to allow standard user to install active X then I think you should add a UI option for user(admin) to easily turn on the default setting which require administrative privilege on every activeX. You have to choose between usability and security but you went with usability user experience.

  20. bond says:

    Basically what I’m saying earlier is that I’m concern about the user. Do you really want the user to look at the information bar and hope that he/she make the right decision in installing activeX.

  21. PatriotB says:

    @bond — it’s no different than the browser allowing you to download arbirary EXEs and the OS allowing you to run them.  Those arbitrary EXEs can install ActiveX controls within your user profile (this goes as far back as Windows 2000 with per-user COM registration under HKEY_CURRENT_USER).

    What IE8 is doing is taking the "in-browser" installation mechanism, and allowing that to be per-user as well.

  22. Lance says:

    As well as the ‘install…’ options, how about an ‘Ignore this request from this site’ option.

  23. Can Silverlight be added as part of the operating system say a part of Windows XP, as it is allready part of Vista, as it is annoying!

    Could you with activeX make it more open source!

  24. Crisp says:

    I like how you’re using Google as your search engine on those screenshots. Replacing MSN search with Google would be a really good improvement in IE8. 😉

  25. Steven Roussey says:

    Per session installation would be a great option.

    And ignore the idiots that don’t even know the difference between a firefox plugin, and a firefox extension. Sheesh.

    Though when you get silverlight merged with IE (for IE9), then ‘extensions’ could be written in that, I suppose.

  26. logistyka says:

    That post is very good, thank you it is very interesting 😉

  27. Mitch 74 says:

    @Roussey: the difference between a Firefox plugin and a Firefox extension is that a plugin is a third-party installable binary that can interact with Firefox; this goes back to the Netscape plugin model, and is usually a system-wide installed software in its own right that gives a handle and a API for some web page content to use it. Current plugins are the Sun Java plugin and the Adobe Flash plugin.

    This model is flawed like ActiveX is, this is why more and more recent improvements to Firefox are done with extensions; but even then, plugins can be installed as user-level restricted binaries – while ActiveX has full SYSTEM read/write/execute access (yes, that was really, really dumb).

    In short, an extension can make use of the browser’s own capabilities to do something un-browser-like, like (as is the case with Firefox) use the chrome engine (which is also Gecko) to create a different GUI, then use the Javascript engine to animate it etc.

    In some cases, an extension can access another, external program to run something more intricate through Firefox’s own mechanisms; that’s the case with the ActiveX wrapper extension used to work Windows Media player’s ActiveX control inside the browser.

    You can perfectly run Firefox unpacked as a standalone software in a limited account in Windows XP, and have its plugins installed as local user binaries too (that’s the way it works in Linux, for example). You have all the power of the brower available to you, but it’s safeguarded inside your user space – subverting the machine requires the user to be root, or a privilege escalation hack.

    What I said in my previous comment then, was that if the IE team is currently trying to unglue IE from the system, then it will also be usable safely inside a limited user account; with the HTML renderer done, and now the ActiveX part, that leaves the Jscript engine part of the system.

    However, Chris Wilson rejected Mozilla’s project to write an external, user-installable ECMAscript 4-compliant engine for IE, leaving us with Microsoft’s seven years old Jscript 5.7, tied into the system, leaks and all, under the pretext that only Microsoft knows how to do a Microsoft Javascript-like engine, but the Jscript team won’t do more than mere bug fixing in Jscript anyway.

    Now, does anyone want to bet when we’ll see an XHTML parser in IE? Or a MathML one, or a SVG one?

  28. Frank says:

    @Match74: Before displaying your lack of understanding in a public forum, you should do some basic research.

    You can already run IE in a limited user account just fine.

    Your assertion that ActiveX runs with "SYSTEM" permissions is incorrect.  ActiveX runs with the permissions of the current user.

    Further, your claim that IE runs with a "seven year old" version of Javascript is also incorrect; beyond the improvements made in the version of Javascript shipped with IE7, myriad improvements have been made thus far in IE8.  If you check out the benchmarks, you’ll find that it’s far faster than the older version it replaced.  The JScript engine isn’t "tied to the system"– it’s a standards IActiveScript engine that runs in the IE IActiveScript host.

  29. JRG says:

    These are good improvements to IE, I am very much looking forward to IE8 and beyond.

  30. pcolmer says:

    It is a shame that this isn’t going to be supported on XP.


  31. StevenR says:

    It is a shame that this isn’t going to be supported on Windows 95.

  32. AjayPathak says:

    these are ver y good improvements introduced by ie 8 team

  33. chaz says:

    Just hated it when one website causes IE 7 to freeze or slow down and it effect every other website in IE 7. Can you isolate the website so that all other website”IE tabs” are not affected?

  34. almhml says:

    I should be watching this Code

    Thank you very much

  35. Mitch 74 says:

    It seems my first answer to Frank was moderated, or something…

    Running an application in a limited account is one thing; running an application in a limited account, said application having access to other authorizations the user has, is called process-bound privilege escalation; it means the process can do stuff the user by itself should be unable to do.

    It seems safe enough; the application should be written to do only what it’s supposed to do, and its evolved privileges can’t be abused.

    Until you get a little bit of code hitting a bug in the application, and processing an unexpected bit of code with the process’ privileges.

    Or, in other words, a user with a limited account goes to a web page with IE, runs a bit of code that hits the Jscript engine, or an ActiveX control in an unexpected way, triggering a buffer overflow and some exploit code execution with IE’s, Jscript’s or ActiveX’s privileges – as in, SYSTEM authorizations (even better than Administrator).

    Now, we learned last time that since IE7, and now even better in IE8, IE actually runs in user space with user’s authorizations in Vista (and maybe XP, too, I don’t remember) and, now, ActiveX can do the same in Vista: run with user’s authorizations, no longer with SYSTEM authorizations. Two down (in Vista; XP still lags behind with those).

    That leaves Jscript, which is supposed to have its own security model, but hasn’t been improved for years, apart from bug fixing. What you read about IE Jscript improvements, were IE’s improved W3C DOM: Jscript, which is still ECMAscript 3 compliant (since 1999), can work more correctly with Jscript and declares more properties and functions to its browser objects. The language hasn’t changed, the interpreter either, and the garbage collector still barely collects.

    What’s left? Well, if Microsoft finally goes all the way, we’ll have IE, ActiveX and Jscript all running as user-level, user-space processes, without access to the rest of the system and little risk to get meaningful attacks and zombified systems. Maybe with IE 8, Jscript 6.0 and Vista or Windows 7.

    Or, you can get a 2k/XP/2k3 system, install Firefox in your limited user account, install those few plugins you really need, and a bunch of extensions, and achieve the same result.

  36. EricLaw [MSFT] says:

    Mitch74: I think you misunderstand how IE, Javascript, and ActiveX run.  

    On all current Windows platforms, IE & Javascript run with the user’s permissions (or lower) and not "System" as you suggest.  

    It’s ~possible~ to develop an ActiveX control that calls into a collaborating service running with higher level of permission, but such an architecture is very rare; the vast majority of ActiveX controls run only with user permissions.

    The advantage of IE7 on Vista (over competitive browsers) is that IE, Javascript, and ActiveX all run at "Low" Integrity, which means they run with even fewer permissions than the user has in their "Limited" account.  Thus, even if IE is compromised, the user’s documents and applications cannot be modified/deleted/etc.

  37. Mitch 74 says:

    Thank you Eric for the clarification.

    My experiences, every time I used IE on a Windows machine, led to complete system subversion in under a few minutes (less with IE 7, true), or, in a very limited user account with manually locked down file authorizations, prompts everywhere and non-working controls at the drop of a hat – which makes what you say quite hard to relate to.

    Or maybe, those cases where the system was zombified (I do mean, clean Win XP installs with updates, no OEM customizations, no third-party softwares – I don’t like bloat) may then have been as you say, a user-level ActiveX and/or Jscript seizing control of another Windows process and using said process to gain privilege escalation.

    But then, if, as you say, on all current Windows platforms, mshtml, ActiveX controls and Jscript run with current user’s authorizations, they should be able to run with ONLY a user’s authorizations, and be installed in a user’s profile, with no administrator rights. Something like, user 1 has IE 6 installed in his profile with Jscript 5.4 and a Flash 7 ActiveX control, user 2 has IE 7 installed with Jscript 5.6 and a Flash 8.5 ActiveX control, and user 3 has has IE 8 with Jscript 6.0 and Sun Java 1.7 plugin, on the same system.

    what I distrust is the fact that, currently, even if the process runs in a user’s space, the file the process started from (because Windows PE still need to run from a disk’s binary) has Administrator rights.

    Stop me if I’m wrong, but let’s take mshtml.dll: it is run as a user-level process, all right; an attack makes it modify itself in memory (buffer overflow, etc.); due to the way a Windows process is linked to its originating binary, it can then modify its originating file, and next time the file is read and run in a SYSTEM context or Administrator context (say, when the Windows Help service restarts), whatever was written in the binary gets executed with said elevated privileges.

    Several processes may mitigate the success of such an attack: on reboot, the modified mshtml.dll file would be restored from the dll cache (maybe not on Windows 2000), an antivirus may catch it…

    But then, a 0-day attack (not detected by AV) restarting the Windows Help service (by causing a crash) right after infecting mshtml.dll (before it’s caught by SFP) will have said code running in a SYSTEM context. As far as I know, that’s a similar process (more complicated) that used Flash (an ActiveX control, running as a Low process) to compromise Vista SP1 (with UAC enabled) recently. XP doesn’t even require privilege escalation, as limited accounts are unusable.

    Don’t tell me "that’s impossible", if there’s a MEAN then there’s a WAY.

    Under a POSIX system (Solaris, Linux, BSD), a process can start from a file that can only be executed ((–x)): it is read by the kernel, locked down in user space, and then run. The process belongs to a user’s memory space and is separated from its originating binary, so it can’t patch itself on disk even if subverted (in the case I just exposed, it can’t even read itself), so this attack vector just plainly doesn’t exist (it would need kernel-level privilege escalation) with properly set-up authorizations.

    In Windows, something similar could be obtained by marking the files as being property of the user, and marking them off-limits to SYSTEM and Administrators (and other users). That would require that each and every user account that requires IE gets a copy of the file only he can execute (that can now be done with ActiveX, and MultipleIEs proved it can also be done with mshtml) barring all others, but that leaves… Jscript (and maybe one day msxml, if you ever start implementing XHTML, SVG and MathML support).

    Too onerous in disk space? Let me count the ways…

    – System32’s copy of those files can be removed

    – Dll cache, ditto

    – System Restore, several times over

    All it needs is a MSI package hosted in All Users, installed when required by a user.

    About the other softwares using (as in my example) mshtml.dll, they are all user-level: SYSTEM doesn’t need Help, Administrators don’t need Flash and very little WWW access (a serious admin shouldn’t browse recklessly), and Messenger should be able to detect and run user-installed mshtml and Flash.

    Back to my point: when will Jscript be unglued from the system and the browser be made really user-level only?

  38. Ted says:


    "the file the process started from (because Windows PE still need to run from a disk’s binary) has Administrator rights"

    Files don’t have rights; processes do.  Most folders in the Program Files and Windows directory provide read and execute rights to all user accounts.  They don’t provide write access to normal User level accounts, and due to System File Protection, they often cannot be overwritten even as Admin.

    The Flash compromised did not happen at all how you think it did, and recall that the terms of the CanSecWest conference were that "winning" meant reading a file from disk.  Protected Mode doesn’t attempt to protect from file system reads.

    You really need to do more reading and less typing.  Its clear that Windows isn’t your system of choice, which is fine, but talking about Windows architecture as if you understand it is a mistake.  If you’re getting compromised on a patched version of Windows "within minutes" that says more about you than it does about windows.


  39. Mitch074 says:

    It seems a comment of mine got ‘lost on upload’ again or something.

    To answer Ted: having used all MS OSes from MS-DOS 3.2 up to and including Vista, I do know a little bit about Windows. You should read up on ACL support for the Win32 naming space in NTFS. Specifically, a Win32 system can support the following on any file:

    – read

    – write

    – become owner

    – change authorizations

    An authorization may be set as allow, neutral (check parent’s) and deny (overrides all other settings).

    A file can also inherit its parents’ authorizations. Any number of user or group of users may be specified for a single file.

    In a POSIX system (a namespace also supported in NTFS), a file has 3 users:

    – owner

    – group (may not be the owner’s group)

    – world

    which each have 3 rights:

    – read (boolean)

    – write (boolean)

    – execute (boolean).

    All in all, the Win32 file authorization is MORE ADVANCED than POSIX’s – it’s just almost never used in Windows, even to protect Windows’ own subsystem (the only exception is the System Volume Information folder, which merely contains the System Restore backups, and is never cleaned up if there’s a lost snapshot: if you bemoan the loss of a few untraceable Gb of space, look no further).

    IF mshtml.dll, the Jscript engine and ActiveX controls resided in a user’s local profile (not anywhere in %SYSTEM%), with tight file access rights, not only would it allow side-by-side installation of IE versions, but it would also mean that IE couldn’t be used in that way to hit the system.

    For installation of a default version, nothing prevents an install package to be put in All Users, deployed every time a new user is created (a small check giving a user the choice: "default IE version is more recent than your installed version. Upgrade Y/N ?").

    And last, subsystems requiring mshtml (like Install/Remove Software and MS Help) may simply link with a user’s installed IE files, and be done with it.

    So I’m asking again, since we already have a somewhat independent mshtml.dll (see MultipleIE), ActiveX controls (see article), when is Jscript becoming local too, so that IE can become unglued from the system?

  40. mihaela says:

    most ActiveX controls are global in nature; once installed, any web page can make use of them. This increases security exposure.

  41. romanet says:

    Another useful ActiveX control lets the Web distribute Microsoft PowerPoint Animation files directly to Internet Explorer, complete with transitions and other presentation attributes, but without the need for PowerPoint itself. Currently, the ActiveX control needs to be manually downloaded and installed from Microsoft at, but once you do, you can interactively work with PowerPoint files directly with your Web browser.


  42. Hypotheek says:

    Romanet, that is a pretty cool feature. Thanks for sharing!

  43. andrewh6 says:

    This is an excellent feature – it will be interesting to see over the next few years how bullet proof it is though.

  44. amine says:

    hhb tfv  u i8y9 i8gifgu uuyfcuynyt

  45. amine says:

    hhb tfv  u i8y9 i8gifgu uuyfcuynyt4ry      67m

  46. I was reading up about IE8 Beta 2 yesterday, and I came across an interesting post about how ActiveX

  47. IEBlog says:

    Yesterday at Tech Ed IT Pro 2008 in Orlando we announced some of the enhancements we’re making in Internet

  48. At 3:00am AEST on Wednesday 18th of June will herald the release of Firefox 3. It’s a big jump ahead from the heady days of Firefox 1 and Firefox 2 days. This version includes over 15,000 enhancements from the 2.x series. It’s faster, funkier an

  49. IEBlog says:

    As someone whose email address is posted in thousands of forum posts, newsgroup discussions, and blogs,

  50. Internet Explorer 8 – Security

  51. 번역은 나같은 초보가 함부로 손대는게 아니구나. 쉽지 않아 쉽지 않아.. 어쨌든 IE 8 보안 파트 2번역 다 했고, 곧 엔쵸비 블로그에 올라갈 예정..

  52. 인터넷 익스플로러8에서 액티브X 없어진다고 낚는 기사 뭐임. 오히려 더 개선되는구만.

  53. IE8의 ActiveX 관련 보안 문서. 그리고 Add-on 관리 기능. 참고로 IE7의 ActiveX 보안

  54. Igor Macori says:

    Si sta avvicinando a grandi passi il rilascio della Beta 2 della versione 8 di Internet Explorer . Come

  55. Windows Internet Explorer 8 Home page (홈페이지) Internet Explorer 8: Worldwide sites (다운로드) Internet Explorer

  56. The next beta for Internet Explorer has been released for broad distribution to the public, according

  57. IEBlog says:

    Back in June, Dean Hachamovitch kicked off a series of blog posts explaining how the IE team approached

  58. A: One of the new features for Internet Explorer 8 (Windows Vista only) is ability to install ActiveX

  59. IEBlog says:

    Hello, I’m Alex Glover and I’m the test owner of the SmartScreen Filter in Internet Explorer 8. The SmartScreen

  60. Изменения в фильтре SmartScreen в IE8 RC1 Привет, меня зовут Алекс Гловер (Alex Glover) и я являюсь главным

  61.     아래 글은 IEBlog에 올라온 IE 8 보안 관련 글 중 두번째 글을 번역한 것입니다. 현재 파트 5까지 나와있는데 시리즈로 번역할 예정입니다. 이 글 뿐

  62.     올랜도에서 개최된 Tech Ed IT Pro 2008 (영어) 에서 Internet Explorer 8 을 조직내에서 배포, 관리하기 위해, 몇가지 기능을

  63. IEBlog says:

    Over the last year, we’ve published two posts about how the IE8 SmartScreen ® filter helps to prevent

  64. В прошлом году мы опубликовали пару статей о том, как фильтр IE8 SmartScreen помогает предотвращать фишинговые

  65. I attended Scott Charney’s keynote this morning at RSA – Moving Towards End to End Trust: A Collaborative

Skip to main content