A Follow up to Low-Rights IE


Hi, I’m John Bedworth, the Development Manager for
Internet Explorer Security.  I wanted to address some of the excellent questions
that came up in the feedback to Rob Franco’s “Clarifying Low-Rights IE” post.

How is “low-rights” IE
different than, in XP, running as a regular (limited) user? At home, I use a
limited user account–is there anything about low-rights IE that is different
than my situation?

The primary difference is that IE 7 on Longhorn
will be running with fewer rights than a limited user.  As a limited user, you
are still able to write to a part of the registry known as the “user hive” or
HKCU, as well as the My Documents folder, etc.  With these permissions, it is
possible to write to parts of the system that contain sensitive user information
and application configuration information.  In practice, even a limited user
needs access to write to these areas. For example, without these permissions, it
would be impossible to put a file in a predictable location on the hard drive,
change an application’s configuration settings, or to put an application in the
user’s Startup folder.  However, IE does not generally need the ability to do
these things.  This is what Low Rights IE is all about.

“As a result, even if a
malicious site attacks a vulnerability in IE, the site’s code won’t have enough
privileges to install software, copy files to Startup folder, or hijack the
settings for the browser’s homepage or search provider.”

Firefox and other modern browsers have it from scratch. What’s innovative in
it?!

This is important to understand, so I’m going to
try to be very clear.  Defense in depth means that we have to assume that every
application has at least some potential for vulnerability that could allow 3rd
party binary code to run within its process.  In a traditional system, this code
would execute and run
with the user’s full permissions and if attacked, could do anything the user is capable of
doing.

This is true on any Operating System and
application running today.  The advantage IE 7’s users are going to have on
Longhorn is that IE 7 will run with a more restricted set of permissions than
even the lowest privileged user account.  If IE 7 doesn’t have rights to install
software, copy files, or change settings, exploit code running inside that
process can not do these things either.  This is very different from what you
get with applications that run with the full user’s permissions today – “other
modern browsers” included.

As the team continues to develop the Low Rights IE
feature, you can expect to see more technical posts that explain how other
applications can take advantage of the new functionality in Longhorn to provide
a more secure user experience.  I can candidly say that the hardest part of
doing this right is maintaining the balance between security and compatibility. 
We want to share what we learn along the way to help other developers implement
a security model using the least possible permissions necessary while still
providing users with a usable product.

— John

Comments (51)

  1. Anonymous says:

    Thanks for elaborating on this, John.

    Still I was wondering in how far this technique was restricted to Longhorn? Windows 2000/XP seems to have got a corresponding API:

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure11152004.asp

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncode/html/secure01182005.asp

    Unfortunately, running IE6SP2 as an untrusted user on my machine results in an initialization failure (0xC0000142). However it should already today be actually possible to do what you are describing, shouldn’t it?

  2. Anonymous says:

    I am really intersted to see how the conflict useability vs. security will be solved. I have seen too mant times post-product-design added security turning into such an encumberance that users switch it off asap.

    One of the first and most significative (read: worst) examples that comes to my mind is outlook: 1st designed to run any kind of script in incoming mails, with plenty of scurity breaches wide open, then closed down so hard that to allow useful attachments to be open the user has to hunt on msdn and edit the registry.

  3. Anonymous says:

    Hmm.. I’m not sure how that sounds like a ‘feature’. Reads to me like IE7 will be run with its own privilege set (lower than the lowest privileged user account, rite?).

    Doesn’t that mean the whole system can only run IE7 with THAT particular privilege set? Can’t even raise privileges for some, and not for some other? Or must I now separate privileges by physical boxes now?

  4. Anonymous says:

    Is this an application feature, or is it highly dependant on OS features built into XP SP2?

    Is there any public documentation on how to take advantage of any XP features that allow an app to use a "low rights" mode?

  5. Anonymous says:

    Does this mean Windows Update will no longer be browser based? If it remains browser based how will it have the permissions to install?

    It’d be good is the system tray auto update checker thing have its capabilities expanded so you can also use it to check for optional updates too.

  6. Anonymous says:

    But I can create limited XP account and run "any modern browser" with "Run as…" command and that account.

  7. Anonymous says:

    Now if you could add these following permissions:

    "Do not display adverts"

    "Do not allow pop up/under windows"

    🙂

  8. Anonymous says:

    A couple of things strike me about this.

    Firstly, given that ActiveX controls are foreign binaries executing on a local machine, I always wondered why a separate user context wasn’t part of the implementation (at least on NT) from the very start.

    Second, an awful lot of malicious ActiveX controls could be got rid of fairly easily if each browser manufacturer provided something akin to the old Netscape Plugin Finder service, instead of downloading controls/plugins from random sites and taking it on trust that the description of the control that the user is presented with is actually accurate.

    This wouldn’t be tricky to implement, and the creators of the ActiveX components would only have limited control over what the user would see as a description – not only that, but a policy could be implemented such that components must adhere to certain requirements (not do X, Y or Z without user’s permission, be easy to uninstall, and so forth) in order to be included in the list. Things like Flash, Shockwave, QuickTime, et al, which are generally well-behaved get through. Random browser toolbars that pop up advertising don’t. It won’t solve the problem, but it’d be a big step towards helping.

    (Implementation details: ActiveX controls already have a GUID – that’s easy enough to look up in a plugin-finder; the browser just has to have a UI to take the user through the process, display the relevant information, and completely ignore the download location currently specified as part of the <object> tag).

    Just a thought.

  9. Anonymous says:

    Will IE7 use this features in Longhorn Beta 1?

  10. Anonymous says:

    > … IE 7 will run with a more restricted set of permissions

    > than even the lowest privileged user account. If

    > IE 7 doesn’t have rights to install software, …

    Presumably, if IE7 cannot "install", this has some effect on the way plug-ins are handled. Of course, the point is to stop malicious plug-ins, but what about the ligitimate ones, such as Flash? On a virgin install, how would the user get the Flash plug-ins, etc if IE7 won’t allow *any* kind of install to happen?

  11. Anonymous says:

    An update to my first post:

    The mentioned tool – DropMyRights – works only under Windows XP, but there it works without problems. If you run IE as constrained user, you’ll get a browser as safe as possible (in fact so safe that you can’t even store bookmarks anywhere ;-)).

    Heise Security assumes that Low Rights IE requires Longhorn as it will run under a separate user account (where it’ll have write access to the disk):

    http://translate.google.com/translate?u=http://www.heise.de/security/news/meldung/60585

    If this were true, however, you could get the same effect already today by running IE as Guest – using RunAs (see Aaron Margosis blog for more details: http://blogs.msdn.com/aaron_margosis/).

    Anyway, as long as you’ve got a sanely configured system, surfing with IE can be as safe already today… so this initiative is most probably just an incentive for unexperienced users to pay for security which an experienced user already has (and which OS X and Linux users already have – thus there won’t be Low Rights Safari/Konqueror).

  12. Anonymous says:

    These are much needed and very welcome changes to the browser. It is a great concept and I hope that it works out well.

    But what about legitimate downloads, such as yahoo’s toolbar, or gaming site. If the browser doesn’t have rights to do this how is it accomplished?

  13. Anonymous says:

    Mo:

    IE had (and probably still has) the ability to lookup ‘registered’ activex controls via their GUID using the CodeBaseSearchPath. If you put an object tag in your HTML with no codebase attribute and the control is not already installed, IE will send a request to activex.microsoft.com in an attempt to find the download location via the GUID. alas, it was never very well advertised and so it was never used by many customers.

    thanks,

    mark

  14. PatriotB says:

    "As a limited user, you are still able to write to a part of the registry known as the "user hive" or HKCU, as well as the My Documents folder, etc. … However, IE does not generally need the ability to do these things. This is what Low Rights IE is all about."

    So it’s kind of like the "Protect my computer and data from unauthorized program activity" check box on the Run As dialog box?

  15. Personally I’m more in favor of <object> tags using

    type=

    rather than clsid=

    (it’s just easier to read)

    … and having an <a href="…">Download plugin</a> on the inside, rather than having some browser-manufacturer-blessed system of assigning plugins to MIME-types or GUIDs.

    Seriously. If I don’t want to install Flash, it’s easier for me to ignore the <a>Download Flash</a> links than it is to constantly click "No, thanks" on the "D’ya wanna install Flash?" plugin popups.

    I don’t consider auto-install prompts to be a convenience.

  16. Anonymous says:

    "So it’s kind of like the "Protect my computer and data from unauthorized program activity" check box on the Run As dialog box?"

    Kind of, but IE7 on Longhorn will have lower rights, protection against message and secondary process attacks, and the ability for the user to elevate to unblock core scenarios. There are a couple of ways to do this on pre-Longhorn OS’s, and even some 3rd party tools that make running with lower permissions easier out there. However, we couldn’t achieve the level of security or user experience we were after without Longhorn.

    A lot of people seem concerned about how IE 7 will allow legit user initiated downloads. I can say doing this right (meaning secure) is a challenge. We’ll spend some more time talking about how this is done in subsequent posts. I will say now that these scenarios are supported in IE 7.

  17. Anonymous says:

    kL: you’re right but that’s not exactly what we’re talking about.

    Yes, on Windows you can ‘run as’ a program with different (perhaps lower) priveleges than the logged in user, but the app that you run is still running as that user. Everything that user can do, your app can do.

    Low-rights IE says that IE will run with even lower priveleges than the user who owns the IE process. So whether you run as an admin or a regular user in Longhorn, IE will have even lower priveleges. As John points out, no other browser that we’re aware of today goes this far. IE 7 will. And, we’ll make it happen with a great user experience too.

    -Christopher

  18. Anonymous says:

    *sigh* I hate it when I mis-spell words. Make that ‘privileges’ in my comment above.

    -Christopher

  19. Anonymous says:

    I am a Windows software developer and I would like to try an IE7 alpha/beta version if this is available, or as soon as it become. Thanks!

  20. Anonymous says:

    "The advantage IE 7’s users are going to have on Longhorn is that IE 7 will run with a more restricted set of permissions than even the lowest privileged user account."

    Will other applications be able to voluntarily surrender the privileges they would normally get?

    Will (power-)users be able to forcibly remove those permissions from programs? (yes, that might mess them up, but it could be useful to "sandbox" something suspicious, just to see if it behaves) Sort of a "run as…" way of accessing the reduced privilege set?

  21. Anonymous says:

    Can you please confirm whether IE 7 in its default configuration, both under XP and Longhorn, will have JavaScript enabled?

    As a comparision, in the default, lockdowned state under Win Server 2003 there is no JS available. I hope that will not be the case under any default security settings for any platforms. Please confirm. Thank you!

    — Darrin

  22. Anonymous says:

    Using Longhorn APIs to develop IE7 before others can access them is anticompetitive and against the DOJ ruling – in letter, I think, but definitely in spirit.

  23. Anonymous says:

    I can’t find an email address or anything so I’m posting this here in the hopes that it gets read by the IE team.

    I am a web designer, and one of the biggest headaches is IE’s lack of CSS support or CSS bugs. Now, don’t stop reading. I’m not complaining about the bugs – all software has bugs and shortcomings. The problem was that Microsoft stopped development of IE, and that was obviously out of all your hands.

    I wanted to bring up something that I haven’t heard mentioned. I am sure you are away of the star html hack, which is basically that any selector that has * html before it (like * hmtl .header) is only interpreted by IE, because nothing really should fall under that selector but IE doesn’t realize that.

    Here is my concern: I (and many, many others) often use this to give IE different CSS, to overcome bugs or to give more simplified code. My concern is over whether or not IE7 will apply * html rules. Because if IE7 fixes the CSS bugs, but still applies my * html rules Ill be giving a working browser bad code.

    My point:

    If IE7 does indeed have superior standards support, please fix the * html bug so that IE7 no longer applies those selectors, so we can continue to use it to target older IE6 and 5x browsers, since people are slow to update.

    And a follow up, I myself wouldn’t mind seeing a new selector, like * ie7 or something silly, so that in case Microsoft stops dev again we have a way to target just IE7.

    Before other web developers yell at me, I prefer (clean) css hacks like these rather then browser sniffing because UAs can be changed and caching/proxies can mess it up.

    Furthermore, some more IEblog posts about the direction you guys are going with CSS and other standards would be nice. Will IE7 support true xhtml (sent as xhtml+xml)? Will it have full CSS and CSS 2.1 support? Any CSS3 support?

  24. Anonymous says:

    "Can you please confirm whether IE 7 in its default configuration, both under XP and Longhorn, will have JavaScript enabled?"

    Yes, I can confirm that IE 7 on XP and Longhorn will have Javascript enabled in the default configuration.

    John

  25. Jie Ren says:

    So instead of simply inheriting current user’s priviledges, the "low right IE" removes those unnecessary ones. This is a clever idea. Conceptually it is like taking a less priviledged role based on the executable in a role-based access control model. This level of indirection is rather powerful.

    While theoretically it is possible to create a lower priviledged user account (or any account you like), asking end users and admins to do this is too much trouble. A secure default configuration pays off.

    A possible improvement, maybe just for developers, is to have a graphical tool to let the executing user to decide what priviledges each process can have. It is not a simple task, and how useful it really will be is arguable, but it can at least serve as a good development tool.

  26. Anonymous says:

    Just to re-iterate a question already asked: will other applications be able to use the same/similar, or application configurableversion of, low rights mode under Windows XP or Longhorn?

    This is a good feature for Internet Explorer – but I’m even more keen to know if this can be enabled by developers or maybe even power users for other applications.

    The time has come for applications to stop assuming they can do whatever they like on a system. Sandbox them and we have a much improved security environment.

  27. Anonymous says:

    ‘"Do not display adverts"

    "Do not allow pop up/under windows"

    🙂

    This would be a bit of a draconian approach for Microsoft to take. It’s ok for an ‘alternative’ browser to offer these features but I can’t see a browser that’s built into the OS being even allowed to do this.

    Off topic, but I still use firefox because of its speed of rendering. Is IE7 going to improve the speed of rendering, which IE use to be the leader of until FF came along.

  28. Anonymous says:

    Its great to see you guys working so hard on a great product.

    Is the IE7 team planning on additional popup controls (such as flash ad’s and flash banners)? I personally find flash ad’s annoying and flash/java popup’s always bypass popup controls on any browsers ive used (even with the settings blocking all popups).

  29. Anonymous says:

    Lots of questions about power users and admins being able to apply different permissions to applications either via a tool or API call…

    As you can see with most of the existing software utilities, including "Run as", out there that try to do this today, the problem you have is if the application isn’t architected to run at a very low permission level, it will break left and right when run under lower permissions – sometimes unrecoverably. At best, this can be described as a poor user experience.

    We’re working hard to make IE run properly under this configuration, and I recommend other applications, especially those that connect to the internet, to do the same thing. Again, there are API’s in Longhorn that make doing this easier and more robust than it has been in the past. These API’s will be public, and we will be posting more information in subsequent entries and MSDN articles on how other application authors can offer a similar level of security.

    Oh, and thanks for keeping the majority of the comments on topic. 🙂

  30. Anonymous says:

    I’m glad that the low-rights feature is available to all apps in Longhorn.

    Will the feature be available at all in WinXP? And if it is, will 3rd party apps be able to use it, or are we talking about IE only?

  31. Anonymous says:

    "Will the feature be available at all in WinXP? And if it is, will 3rd party apps be able to use it, or are we talking about IE only?"

    As noted earlier in the comments, there are API’s in XP and Win2K that make doing something similar to Low Rights IE possible on those platforms. However, the level of security you can achieve with these API’s is not the same as what can be achieved on Longhorn, and quite frankly, the older versions didn’t meet IE team’s expectations for security or usability.

  32. Anonymous says:

    so, I should say that it’s not clear wether we will be able to get this working to the level we want on XP…

  33. Anonymous says:

    In the security settings in IE there is an option to only allow Administrator approved ActiveX controls which is a great idea prevented from being used fully because it’s difficult to get at which controls you want to allow/disallow.

    For example if I browse the MSDN documentation in IE an ActiveX control is used for the tree, how do I easily find what it is to allow it? At the moment it’s very hard and is an area where much improvement could be made.

  34. Anonymous says:

    Thankyou for your reply John.

    I’m looking forward to the day that I can run a Windows user account without admin rights and I can reasonably expect my application to run correctly.

    I also hope that MS are going to make a general push for developers to ensure their programs run in low-rights mode as well – it would be a big step forward for security on the MS Windows platform.

  35. Anonymous says:

    "Defense in depth means that we have to assume that every application has at least some potential for vulnerability that could allow 3rd party binary code to run within its process."

    This is a good start, but I would personally like to have a version of the HTML control that did not include a mechanism to download and execute third party binary code at all. Not just "it doesn’t allow it in this or that zone" or "it provides a dialog asking if you want to do it", I want a version where the relevant HTML tags and attributes and the scripting commands that correspond to them simply don’t exist.

    There should be a complete separation between the version of the control that provides these facilities and the one that is used by the control panel and other elements in Windows Explorer. That is, the one used by Windows Explorer would not include a mechanism to download documents via a URL, and the one used by Internet Explorer would not include a mechanism to name files on the local disk nor request the execution of any downloaded code.

    The ONLY options available on downloading a file would be: to display it as a web page, to pass it on to a previously installed plugin that implements the same level of security, or to allow the user to save it directly to the disk.

    As for the "low rights" feature… UNIX systems have had the basis for this kind of mechanism, albeit not one usable by ordinary users, for decades. It’s called the "chroot" call. A process in a chrooted environment can not access any resources outside that environment. This was easier in traditional UNIX because all resources available to a process were available through names in the file system alone, and this is no longer true for modern UNIX. There are mechanisms whereby a malicious program can cause trouble or, if the chrooted environment is set up badly, even break out of it… so FreeBSD has a mechanism called a "jail" that’s kind of a "super chroot" that also applies to network connections, internal system tables and IPC, and so on. A "jail" is almost as secure as a completely virtual environment using a hypervisor, but much much more efficient. There are companies that actually provide customers "root" access within a jail as their colo facility.

    That kind of environment is the minimum I would consider appropriate for running code that is expected to have a risk of being compromised. If you can’t provide at least this level of security, I would much rather you fixed the basic design flaw in your browser (as suggested in this message) before messing around with half-measures like this "restricted" account.

  36. Anonymous says:

    This is only slightly related to the original post.

    One simple thing that would really help improve security against the cross-site-scripting exploit that allows stealing of cookies (in particular cookies that contain an authentication ‘ticket’) would be if IE7 could return a random session ID in the HTTP header. This would just be a random number that would persist for the session. That way developers could use that number to add ‘salt’ to the encoding for their auth. tickets. Then even if someone managed to steal a cookie it wouldn’t work from any other session.

    Alternately, but probably much harder, would be the ability to write a special kind of cookie that was not accessible to Javascript. It could work just like cookies work today but Javascript wouldn’t be able to get it’s paws on it.

  37. Anonymous says:

    "For example if I browse the MSDN documentation in IE an ActiveX control is used for the tree, how do I easily find what it is to allow it? At the moment it’s very hard and is an area where much improvement could be made."

    I agree. The admin approved list of controls User eXperience is not for the average user. I hadn’t thought of using for this purpose; this is sort of what we created manage-add-on’s for. I’ll take another look here.

  38. Anonymous says:

    "Alternately, but probably much harder, would be the ability to write a special kind of cookie that was not accessible to Javascript. It could work just like cookies work today but Javascript wouldn’t be able to get it’s paws on it."

    Um, we have exactly this feature today. I think it actually shipped as part of IE 5.5. These are called "httponly" cookies and are fully documented up on http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wininet/wininet/http_cookies.asp.

    Cheers,

    John

  39. Anonymous says:

    I posted a question in the previous article. But i think it’d make more sense in posting it over here instead so here. My question..



    I would like to know when the kind of code i’ve got posted at http://flum.se/ie/ WON’T be able to crash your IE & Computer. The latest entry to my crash page puts down both IE 6 SP1 AND WinXP totally!! And what exactly is this? Some naughty ActiveX code? Nope, it’s just a normal <img src=… height="9999999999" width="999999999999"> As you can see, totally out of propotion and it even crashes the "beloved" firefox!

    When will we see a fix for this and the other crash codes i’ve got there?

    ——-

    Please note that i do not mean to teach "bad guys" how to code webpages how to crash users computers i simply put these pages together because i’d like to raise the question of when will we see a fix and a place where people can test their systems to see if they are "protected" or not. Also please note that going to the above page won’t crash your pc. You need to click on a link on the page itself. Also, the webpage does nothing other than attempt to crash your IE. It does not attempt to steal anything or hack you in anyway.

  40. Anonymous says:

    Kenneth: Camino (a browser using the same Gecko engine as Mozilla/Firefox, but with a more native GUI) eats your firefox crasher and pops down a dialog saying that a Javascript program was running too long.

    I’m surprised it was happy with it, I’ve found that it’s generally a bit fragile.

  41. Anonymous says:

    How is "low-rights" IE different than, in XP run as, ‘Protect my computer amd data from unauthorized activity’? Essentially running IE under a restricted token. This sounds very much similar to it as any process launched under restricted token will not have access to the launching user’s profile.

    For people writing third party plugins in IE it may important to have an idea of the things to come.

  42. Anonymous says:

    <<I would like to know when the kind of code i’ve got posted at http://flum.se/ie/ WON’T be able to crash your IE & Computer.>>

    When driver manufacturers learn how to properly author video drivers.

  43. Anonymous says:

    >When driver manufacturers learn how to properly author video drivers.

    Did you even check out the website? Only ONE of the crash pages could be remotely connected to your statement and that would be when the <img code> crashes through GDI. So in your mind it is reasonable to allow webmasters to code pages that use parameters like "9999999" and then accept it without whatsoever thinking it might hurt the visitor? The problem is NOT with the way the software renders through video drivers but that the browsers allow the code to be executed in the first place.

    What about the other pages? Like the one where standard xml code crash IE?

  44. Anonymous says:

    I guess the idea of shipping a browser with an inherently secure design is right out, then?

    Microsoft could provide a version of the HTML control that doesn’t even include any APIs that displayed content could use to read or write arbitrary files, execute native code, and so on… rather than having such interfaces available but subject to a privilege mechanism. If an application needs to make more capabilities available, let that application install plugins or other extensions.

  45. Anonymous says:

    > Using Longhorn APIs to develop IE7 before

    > others can access them is anticompetitive and

    > against the DOJ ruling – in letter, I think,

    > but definitely in spirit.

    > hum v

    Mr. V,

    If we were doing anything wrong, I’m sure one of the lawyers who look over our shoulders would put a stop to it very quickly.

    John

  46. ieblog says:

    Kenneth: thanks for the link. We have someone investigating what’s going on with the links on the web page you’ve provided.

    -Christopher [MSFT]

  47. Anonymous says:

    I heard of a company that already applies this low-rights theory to applications, however their download demo appears to apply low-rights to IE and anything IE downloads. http://www.greenborder.com/downloads/TestDrive.html

  48. Anonymous says:

    No problem Christopher. My hopes are that IE 7 will not have a problems with the links. I will provide more links on that page when I find them. But for now I believe I’ve covered all code that ‘should’ crash the current release of IE.

  49. Anonymous says:

    I think the concept of ‘low-rights IE’ is good as far as it goes. But I think that Windows needs to move much further.

    In particular I would expect that the vast majority of programs would not need to have the type of full user rights you are describing here. I would like to see the ‘low rights’ regime raised to the level of an operating system trope rather than an IE specific facility.

    For example, when I install Tomb Raider I really do not need the run time executable to do anything more than read/write to saved game and interact with the sound and graphics subsystems.

    I can see how a game like this might well need access to more privilleges during installation (although I still think developers need to be encouraged to be spartan with their demands). But I think it would be good to impose more structure and constraints on programs. For a start the expectation that the program will have write access to the directory it is installed in must go. I am fed up with programs that demand write access to the system partition to run.

    I would also like to see the registry management set up in a much more transaction oriented fashion so that it is possible to roll back malicious registry edits more easily.

  50. Anonymous says:

    Hi, I’m Patrick Mann, a security tester on the IE team. It’s a big week for me and a few other folks…