XP SP2, IE, the Local Machine Zone Lockdown, and you

Summary

XP SP2 is especially tough on content running in the Local Machine Zone (meaning html files running on your desktop, a CD, or elsewhere on your machine). XP SP2's changes to the LMZ prevent all active content, including Javascript, Java, ActiveX.

Behavior

Blocked content triggers an Information Bar message saying "To help protect your security, Internet Explorer blocked this site from downloading files to your computer. Click here for more options...".
Clicking on the information bar brings up a prompt: "Allow Blocked Content".
Clicking that gives you a prompt: "Enabling active content on your Local Machine may harm your computer. Do you want to continue?"

Some examples of affected applications:

  1. Dave's Quick Search Taskbar Toolbar Deskbar is a toolbar that hosts a tiny browser window with an input box that can run searches on several different sites based on shortcut keys ("sp2" does a default Google search, "msft intc csco$" does a Bloomberg search, etc.). It uses a plugin architecture with Javascript files to allow you to add your own shortcuts. Under XP SP2, it pretty much stops working because the Javascript in the Local Machine Zone is blocked.
  2. HTML based CDROM's (such as training or educational CD's with simple Javascript menus).
  3. HTML Help applications with Javascript / ActiveX / Java.
  4. HTML developers working on HTML files with Javascript menus.
  5. HTML / Javascript utilities, such as auto-login pages (described below).

Why?

There are good reasons for this change - content running in the Local Machine Zone is by default higly trusted, so in the wrong hands it can do quite a bit of damage. Zone Elevation Attacks are among the most exploited IE attack vectors. However, the LMZ Lockdown can cause your local HTML content to stop working. Like it or not, this is how it works in XP SP2.

Microsoft MSDN information on the LMZ lockdown (more resources at end of post):
http://msdn.microsoft.com/security/productinfo/XPSP2/securebrowsing/locallockdown.aspx
http://msdn.microsoft.com/security/productinfo/XPSP2/securebrowsing/lockdown_devimp.aspx

Solutions

There are several solutions if the LMZ Lockdown affects your application:

  1. Give your HTML "The Mark Of The Web." This is probably the simplest solution, and is discussed below.
  2. Wrap your HTML in an HTML Application (HTA).
  3. Use a web browser control to display your content inside an application, rather than just showing it inside IE. Content shown within an application can be given higher privleges. Note that you have the option of using a Gecko browser control in addition to the IE browser control.
  4. Bad solution A - Don't download XP SP2 or block SP2 Auto Update for your network. SP2's improved security is a good thing - think big picture and fix your HTML.
  5. Bad solution B - Circumvent the LMZ Lockdown. Heck, we should probably be opting in to the LMZ Lockdown for other apps, not trying to disable it for IE.

Examples

I have several "auto-login" pages use javascript to log me into sites that I have to log into daily. These all stopped working when I upgraded to XP SP2. These pages are HTML files on my local filesystem. They contain HTML source from the original online page, modified it to prefill my username and password[1]. There's also a body onload statement so the form submits itself:

<html>
<head></head>
<!--several javascript functions such as hash() removed to keep this simple-->
<body onload="document.login_form.submit();">
<form method=post action=https://login.yahoo.com/config/login_verify2?pbnj42pbnj
name=login_form onsubmit=
"return hash(this,'http://login.yahoo.com/config/login_verify2')"ID="Form1">
<!--several hidden form fields removed to keep this simple-->
<input type=hidden name=".slogin" value="pretendyahoousername" ID="Hidden7">
<input name="passwd" type="password" size="17" maxlength="32" ID="Password1" value="notmyrealpassword">
</body>
</html>

The Javascript in the LMZ tiggers the blocked content warning. I'm given the option to allow the blocked content, but that However, IE will give your page a free ride if you include the magic MOTW tag at the top[2]:
Either:

<!-- saved from url=(0014)about:internet -->

Or[3]:

<!-- saved from url=(0023)http://www.somesite.com -->

So my new HTML reads:

<!-- saved from url=(0014)about:internet -->
<html>
<head>
</head>
<body onload="document.login_form.submit();">
<form method=post action=... >

And all is well and good.

The PHDCC site has a good description of this and the HTA solution, with screenshots, so I won't go into too much more detail here. Here's an example of the HTA code to host HTML, though (via PHDCC):

<HTML> <HEAD> <TITLE>HTML Application</TITLE> <HTA:APPLICATION 
ID=
"oMyApp"
BORDER=
"thin"
INNERBORDER=
"no"
SCROLL=
"no"
CAPTION=
"yes"
SHOWINTASKBAR="yes"
SINGLEINSTANCE="yes"
SYSMENU=
"yes"
WINDOWSTATE=
"normal">
</HEAD>
<BODY>
<IFRAME
src=
"index.htm"
trusted=yes
width=100%
height=100%
marginwidth=0
marginheight=0
border=0>
IFRAMES not supported
</IFRAME>
</BODY>
</HTML>

Links for further information

  1. Microsoft Technet summary on Browser Security Changes for SP2
  2. Analysis and help by PHDCC

Footnotes

[1] A free thump on the melon to the first astute person that tells me that this is not secure. Of course it's not secure. I only do this with passwords and sites I don't care about.
[2] This makes me wonder - couldn't the evil hacker guys just put this in their HTML and get the same free ride? I'm sure I'm missing something there.
[3] The number in perintheses, (0023), is the number of characters that follow. This code was taken from the www.phdcc.com site, but I didn't use their site URL in case the sample code gets copied and pasted.

UPDATE: Eric Law clarified in the comments:

Regarding your question #2: What's ~really~ happening when you use the MOTW is that the page is treated as having originated from the internet.  This means two things:

1> It runs with Internet permissions, not local machine zone permissions.

2> It no longer is able to access your local file system.  So, for instance, it cannot use the ADODB stream to read files off your harddisk and then send them to the Internet in a form post.

Note also: A MOTW cannot say that a page came from a more secure zone (e.g. can't claim it came from the trusted zone).

 

5 Comments

  • You say there are several good reasons for this security change. If we assume that is true, why is it so easy to get around? This change just seems to break things without giving us real security. Any malware will inclue the mark of the web while everyday developers have to change how they develop and have their existing apps broken. What's the point?

  • Regarding your question #2: What's ~really~ happening when you use the MOTW is that the page is treated as having originated from the internet. This means two things:

    1> It runs with Internet permissions, not local machine zone permissions.
    2> It no longer is able to access your local file system. So, for instance, it cannot use the ADODB stream to read files off your harddisk and then send them to the Internet in a form post.

    Note also: A MOTW cannot say that a page came from a more secure zone (e.g. can't claim it came from the trusted zone).

    -ericlaw

  • Thanks, Eric! I updated the post.

  • to David M Lee

    Actually, the 0013 one is wrong. 13 is meant to be the number of chars in about:internet - if you count, you will see there are actually 14 chars. Someone at Microsoft can't do Maths, but the writer of this blog can.

  • Okay... so the MOTW works in straight HTML pages - thanks for that, btw!

    BUT - I now want to use an XML file with javascript in there (using Spry Framework, in Dreamweaver)

    I can't find where to place the MOTW in the XML file - nor in the XSLT...

    Any ideas?

Comments have been disabled for this content.