EricLaw's IEInternals

Understanding the Protected Mode Elevation Dialog

2009-12-01T02:56:00Z

Internet Explorer 7 introduced Protected Mode, a feature which helps ensure that the browser and its add-ons run with a minimal set of permissions. Code running inside the “Low Rights” process doesn’t have permission to write to your user-profile’s folders or registry keys, which helps to constrain the damage if a bad guy manages to find a vulnerability within the browser or its add-ons.

To help ensure compatibility, Protected Mode employs a system of virtualization to help ensure that code that runs within Protected Mode will continue to work even when its permissions are restricted.

In some cases, virtualization can lead to surprising outcomes, some of which Mark Russinovich describes in his blog post The Case of the Phantom Desktop Files. Beyond such surprises, some functions just cannot be virtualized effectively—for instance, if you want to offer a feature that sets the current user’s Desktop wallpaper, your code simply must write to their user-profile.

How does IE resolve the tradeoff between security and functionality? The answer is “by using brokers.” The idea is that Internet Explorer (and some add-ons like Flash and Java) will run a broker process with “Medium Rights” that can use the current user’s permissions to take actions that would otherwise be prohibited when rendering content inside the Protected Mode sandbox. A broker process must be carefully designed to accept untrusted input (since its caller could be malicious code trying to escape the sandbox), sanitizing data and confirming any security-sensitive actions with the user directly before making changes.

When an add-on running inside Protected Mode attempts to launch a broker process (or any other program), the ElevationPolicy registry key (HKLM\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy) is checked to determine how the process should be launched. One of four policy values may be specified:

Policy Result

0 Protected mode prevents the process from launching.

1 Protected mode silently launches the broker as a low integrity process.

2 Protected Mode prompts the user for permission to launch the process. If permission is granted, the process is launched as a medium integrity process.

3 Protected Mode silently launches the broker as a medium integrity process.

The problem arises when a broker process fails to properly register an elevation policy. If no ElevationPolicy is specified, then the default policy is #2, and the user sees a prompt for permission to launch the process. In the case of a broker process, this can lead to a very confusing user-experience. For instance, if Flash’s Broker’s elevation policy is missing from the registry, any page that uses Flash will trigger the following prompt:

Now, keeping in mind that average users (and most super users) don’t have any idea what a broker is or why they’re seeing this dialog, it’s understandable that they might click either “Allow” or “Don’t allow” just to get rid of it. However, the next time the add-on attempts to launch the broker process, the user will be presented with the same prompt. As you might imagine, they will quickly get tired of this!

Users tired of banging the “Don’t allow” button (not really understanding what the broker is and why it exists) are likely to try checking the “Do not show me the warning for this program again” box before clicking the “Don’t allow” button.

Unfortunately, this exercise is doomed—the “Do not show” checkbox only takes effect when you push the “Allow” button—you cannot automatically deny access for a given process.

Why not? Because it would break things unexpectedly, and there would be no way for a normal person to figure out what went wrong and subsequently fix it. An add-on that tried to launch its broker would always fail, and might try repeatedly (hanging the browser). Worse still, there’s no way for the user to go back and change their mind—there was no reasonably affordable way to build a UI that would allow for such reversals.

Add-on developers should take care to ensure that the ElevationPolicy for their broker process is properly set at install time (and may wish to confirm that it’s set properly if the broker ever fails to launch due to an Access Denied error, and notify the user accordingly).

End-users encountering unexpected Protected Mode Elevation prompts should consider either reinstalling whatever add-on is triggering the prompt (it’s often obvious) or disabling any unrecognized or unwanted add-ons. Beyond reducing attack surface and prompts, disabling unwanted add-ons will often improve browser performance.

-Eric

The JVM Install Prompt

2009-11-27T20:37:00Z

Many years ago, Microsoft developed an implementation of a Java Virtual Machine to run Java content. Internet Explorer 5 included code that would download and install the JVM (if needed) when a user encountered Java content on the web. After some time, support was discontinued for the Microsoft JVM, and no further updates were made available. The Microsoft JVM should no longer be used, as security patches are no longer released for it-- installation is blocked on Vista and Windows 7.

To help ensure that Internet Explorer users still are able to recognize when a page requires a JVM, the existing Microsoft JVM install code in IE was replaced with a dialog box that helps direct the user toward an available JVM (namely, Sun Microsystems’ implementation).

That dialog box looks like this:

If you click the “More Info” button, you are taken to a web page explaining how to install the Sun Java Virtual Machine.

When you check the “Do not show this message again” box, Internet Explorer stores this preference in the registry. It does so by creating a registry string named {08B0e5c0-4FCB-11CF-AAA5-00401C608501} inside the HKCU\Software\Microsoft\Active Setup\Declined Install On Demand IEv5\ branch.

If you decide not to install a JVM, you may quickly grow tired of this modal dialog box and thus tick the “Do not show this message again” box. Subsequently, IE will never show this prompt again.

Unfortunately, depending on how pages using Java Applets are constructed, this may result in a confusing user-experience. Consider, for instance, this National Ice Center page which requires Java. When you visit this page without a JVM installed, you will see the following information bar:

The text of this information bar is misleading—the page doesn’t use an ActiveX control—the prompt is merely a side-effect of how Applet support was built into IE. Unfortunately, there’s no indication that this prompt is really related to Java. If you choose “Install This Add-on” from the Information bar’s menu, you’ll see another misleading dialog box:

Fortunately, the National Ice Center page also includes some fallback text in the Applet tag so that if the Applet cannot be rendered, the page itself will explain that Java is required:

<APPLET>
<PARAM></PARAM> <PARAM></PARAM><PARAM></PARAM>
<b>You must install Java to use this page!</b>
</APPLET>

Additionally, if you develop your page using an OBJECT tag with an APPLET tag embedded within, Internet Explorer will show only the “You need Java” dialog, and will not display the misleading ActiveX information bar.

-Eric

Troubleshooting Authentication with Fiddler

2009-11-22T20:54:00Z

Over the last few weeks, I’ve been exchanging mail with a webmaster (Vladimir) in Russia who reported that his customers were having problems using IE8 on Windows 7 to log into his website. His site uses HTTP Basic Authentication, so users are prompted to enter their credentials using the following dialog:

I asked the webmaster to submit some HTTP Traffic Logs collected by the lightweight network traffic capture tool known as FiddlerCap. He obliged, and I used Fiddler to take a look at the captured .SAZ traffic log.

Fiddler includes an “Auth” Inspector that allows you to easily look at the HTTP Authentication credentials sent for a given request. I opened the .SAZ file captured with FiddlerCap. In the failing case, he had entered the username test and the password ABCDEFG. The Auth inspector, however, showed that the password wasn’t being sent:

As you can see, the base64-obfuscated string is quite short, and the decoded username:password string contains only the username and the colon, but no password at all.

Now, I didn’t have ready access to the customer’s test page, but wanted to try to reproduce the problem myself. I don't have a server that required Basic auth handy, but Fiddler makes it simple to simulate scenarios such as this. I simply used the AutoResponder tab to create a rule that responds to any request for a URL that contains the string “AUTH” with a HTTP/401 response that demands Basic authentication:

Fiddler includes about a dozen sample responses like the 401_AuthBasic.dat, and you can easily use Fiddler to capture other responses, or even create your own using any text editor.

With this AutoResponse rule in place, I can request any invented URL containing the word "auth" and get an authentication prompt in response. I tried http://www.example.com/auth and received the expected authentication prompt. I typed in some credentials, submitted them, and took a look in the response inspector. I found that the credentials were submitted perfectly:

As you can see, the base64-obfuscated string is longer, and the decoded username:password string contains both the username and password, split by the colon. So, I wasn’t able to reproduce the behavior reported by the web developer, despite trying a number of different reproduction cases. However, he was fortunately quite persistent and did some additional research, determining that the problem only existed when the password was pasted from the clipboard.

This was an interesting finding, and narrowed down the problem substantially.

First, a bit of background. In Windows 7, WinINET was updated to call the CredUIPromptForWindowsCredentials function to collect HTTP Authentication credentials. The function shows a new CredUI dialog that offers an improved UI over the legacy password prompt, and its use is recommended for use on Windows Vista and later (although IE8 only uses it when running on Windows 7).

Now, experienced developers in the audience know that any time anything is changed, there’s always a chance of regression, so, coupled with the fact that the problem was narrowed down to just the password-paste case, we had some leads. At first, I thought it likely that the problem was related to the Russian version of Windows 7, because I didn’t have any problems with pasting in the password with CTRL+V on the English OS. So, I asked Vladimir to collect screenshots of all of the different formats on his clipboard. This is easily done with a free little utility called ClipSpy. I suspected that perhaps there was a codepage-related problem where the password characters were perhaps being mangled because the system codepage was Cyrillic. However, the output of the ClipSpy tool didn’t reveal anything interesting; Vladimir's clipboard's bytes looked just like my clipboard's.

At this point, I was stumped. I wasn’t able to reproduce this problem in-house, and had tried on many different Windows 7 computers, using a variety of different sites and passwords. Then, Vladimir saved the day by forwarding along a posting on a message board where a customer complained of exactly the same problem. The response from “auggy” indicated that the user should try using CTRL+V to paste rather than using the context menu.

I had always been pasting with CTRL+V and had never tried using the context menu; Vladimir's repro steps hadn't mentioned the context menu, and it didn't even occur to me that it could make a difference-- typically the context menu and CTRL+V behave identically.

After playing with the context menu’s Paste option, I was very quickly able to reproduce the problem. It turns out that there is a tiny bug in the CredUI dialog on Windows 7. If you use the CredUI dialog's context menu to paste into the username or password dialog box without pressing any key in the box (e.g. tab, CTRL+V, CTRL+A, etc) then, while the text appears to be updated, the internal data structures are not updated. The internal username or password data remains unchanged from its original value until a key is pressed. In the failing cases, the boxes started out empty, so when the user used the context menu to paste into the password box, the password data was never updated away from the blank value.

I’ve passed this bug along to the CredUI team for further investigation. I’d like to thank Vladimir for his patience as we hunted down the core problem and for his willingness to provide network captures and other information.

Hopefully, this post has shown you a few ways that you can use Fiddler to find the root cause of problems (and eliminate confounding variables from the repro) and reiterates the value of providing painstaking detail when sharing bug repro steps.

-Eric

PS: My "Debugging with Fiddler" talk at the Microsoft PDC is now available for online viewing.

Inline AutoComplete

2009-11-11T08:30:00Z

Internet Explorer 8 removed support for one of my favorite browser features: Inline AutoComplete (IAC) for the address bar. This feature was off-by-default, but for almost a decade the first thing I did when setting up a new computer was enable IAC using the checkbox Tools > Internet Options > Advanced > Use inline AutoComplete.

For IE8, we introduced a new Smart Address Bar which offers a bunch of improvements including better and more relevant suggestions in the new flyout window. The feature also includes keyboard tips, which show how to take advantage of keyboard combos to open pages in new tabs, background tabs, etc. Unfortunately, as a consequence of the rewrite, we lost the legacy AutoComplete behavior provided by the Shell. The consensus was that, while IAC had some vocal proponents (myself especially), the fact that it was off-by-default and most users didn't have it enabled meant that it was a reasonable sacrifice when compared to the benefits brought by the new address bar. The most important improvement for keyboard lovers was the SHIFT+Enter hotkey, which navigates to the "best match" in the results list; there have long been complaints and debates about whether the default behavior of IAC was suboptimal. With the relevance engine added to IE8, we have good reason to believe that SHIFT+Enter is a great feature for most folks to more quickly get to the best result.

Nevertheless, I expected that we'd hear from vocal proponents of IAC during the IE8 beta cycles. The initial blog post announcing the change had a few heated comments, and one bug with a meager 16 votes was filed on Connect, but we didn't receive nearly the level of feedback I was expecting. After two betas and one release-candidate which were used by many millions of users, I could only count a handful of supporters for IAC. Since we shipped the final version of IE8, I've received more mail asking why IAC was removed. The gist of much of the feedback was "You already had the feature, it wouldn't have cost you anything to keep it." Unfortunately, that's simply not true-- IE8 is no longer using the standard controls that support AutoComplete, and even if was, the "free" AutoComplete behavior wouldn't work as expected with the matches in the Smart Address Bar's dropdown.

IE8 has been my default browser for quite a while now, and I've largely adjusted to the change. Beyond getting used to the SHIFT+Enter shortcut, I also heavily use SlickRun, a keyboard-lovers' utility I wrote a long time ago which makes heavy use of command aliasing and offers Inline AutoComplete.

As we build future versions of IE, I encourage you to provide feedback early and often. We've already received some great suggestions from the web developers out there, but we're very interested in UI suggestions as well!

thanks!

-Eric

Security Intelligence Report Volume 7 Released

2009-11-03T00:19:00Z

Security researchers at Microsoft release a biannual "Intelligence Report" containing statistics about the software-related security incidents over the past 6 months. This report is called the SIR, and the latest version can be found here. There are many interesting charts and data points in the report, but I have two favorites from the latest edition.

As browser code quality improves, add-ons become a more appealing target:

Here's a chart of the types of malicious downloads that SmartScreen has blocked over the last six months:

Microsoft remains committed to help protect you on the web-- IE8's SmartScreen and Microsoft Security Essentials are making a significant impact against the bad guys.

-Eric

Using Meddler to Simulate Web Traffic

2009-10-13T21:53:00Z

As mentioned back in July, IE8’s new lookahead downloader has a number of bugs which cause it to issue incorrect speculative download requests.

The “BASE Bug” caused the speculative downloader to only respect the <BASE> element for the first speculatively downloaded script file. Subsequent relative SCRIPT SRCs would be combined without respecting the specified BASE, which resulted in spurious requests being sent to the server. Eventually, the main parser would catch up and request the proper URLs, but the spurious requests waste bandwidth and could cause problems for some servers.

When first investigating the speculative downloader problems, I decided to use the Meddler HTTP Traffic Generation tool to build some test cases. Meddler is a simple little tool that allows you to write JavaScript.NET scripts to emulate a web server. Meddler allows for precisely timed delivery of responses, and includes classes to enable basic fuzzing scenarios. The best part of Meddler is that you can use a single MeddlerScript (.ms) file to contain an entire test case, even if that test case is made up of multiple pages, images, scripts, and other resources. These .ms files can be shared with others, run across multiple operating systems, and attached to bugs or test harnesses for future regression testing. The test machine only requires the .NET Framework and Meddler installed, and does not need IIS, Apache, Perl, ASP.NET, etc.

Because the base issue was so simple, I was able to quickly build a simple MeddlerScript which demonstrates the BASE Bug. If you’d like, you can follow along using my MeddlerScript: PreParserBaseBug.ms.

The test script generates the following sample HTML:

<html><head><base href="http://ipv4.fiddler:8088/pass/"></base>
<script type="text/javascript" src="inc/1.js"></script>
<script type="text/javascript" src="inc/2.js"></script>
<script type="text/javascript" src="inc/3.js"></script>
<script type="text/javascript" src="inc/4.js"></script>
<script type="text/javascript" src="inc/5.js"></script>
<script type="text/javascript" src="inc/6.js"></script>
<script type="text/javascript" src="inc/7.js"></script>
<script type="text/javascript" src="inc/8.js"></script>
<script type="text/javascript" src="inc/9.js"></script>
</head>
<body> Test page.</body></html>

Note that I plan to watch the network traffic with Fiddler, and because traffic sent to localhost isn’t proxied, I will use “ipv4.fiddler” as an alias to 127.0.0.1.

When visiting the Meddler test page, the traffic from IE is as follows:

As you can see, there are spurious download requests containing the wrong path; these are shown in red as the MeddlerScript is designed to return failure for such requests. Later, the correct URLs are downloaded as the main parser encounters the script tags and correctly combines the URLs.

Today's IE8 Cumulative Update (KB974455) fixes the BASE Bug. After installing the update, loading the sample HTML results in no spurious requests-- each script URL is correctly relative to the specified BASE.

Please note that while the BASE bug is fixed, the “4k Bug” is not fixed by this update. If you want to view that bug in action, try this script: PreParser4kBug.ms. As it is a timing issue, you may need to reload the “hammer” page a few times to encounter the problem.

While Meddler is rather simplistic, it can be very useful for sharing test cases and simulating the behavior of web servers. You can use Meddler to build reduced test cases that reliably generate problematic HTTP responses.

Until next time,

-Eric

Capturing Crash Dumps for Analysis

2009-10-12T11:01:00Z

Sometimes, folks report crashes to the IE team that we are unable to reproduce internally. That’s usually because, as mentioned often, most crashes are caused by buggy browser add-ons.

In some cases, however, crashes occur even when running with browser add-ons off, and if we cannot reproduce the problem, the next best thing is a crash dump file from the affected machine.

Collecting crash dumps isn’t hard:

Install WinDBG from http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx#ERB
Configure WinDBG to run whenever a crash occurs: In an elevated command prompt, run WinDBG with the -I (case-sensitive) parameter. For instance:

C:\debuggers\windbg.exe –I
When the crash occurs, WinDBG opens. Type the following command to generate a .DMP file:

dump /ma %USERPROFILE%\Desktop\IECrash.dmp

Dump files tend to be dozens to hundreds of megabytes in size, so they typically cannot be readily passed around via email (although they often compress well). If a DMP file is requested, the person asking for the file will typically tell you how to return the file to them.

Depending on the problem reported, we may also want to get a network traffic log or a Process Monitor log.

-Eric

Understanding DEP/NX

2009-10-10T18:51:00Z

Despite being one of the crucial security features of modern browsers, Data Execution Prevention / No Execute (DEP/NX) is not well understood by most users, even technical experts without a security background.

In this post, I’ll try to provide some insight into how DEP/NX works, explain why you might encounter a DEP/NX crash, and convince you that turning off DEP/NX is almost never the right decision.

More than anything else, I hope you take away two important facts from reading this post:

In many cases where you encounter a DEP/NX crash, the browser would have crashed anyway.
The vast majority of DEP/NX crashes are caused by browser add-ons. If you run IE in No Add-ons Mode, it’s very unlikely that you will encounter a DEP/NX crash.

Background

I’ll begin by providing some background information on DEP/NX and how the browser makes use of it.

What is DEP/NX?

DEP/NX is a feature of modern CPUs that allows marking of memory pages as Executable or non-Executable. This allows the CPU to help prevent execution of malicious data placed into memory by an attacker. If the CPU detects that it is about to jump to (begin execution of) data which is in a memory page which is not marked as Executable, the CPU will raise an exception which results in termination of the process.

Stated another way, if DEP/NX determines that if a potentially dangerous jump is about to be made, the process is intentionally “safely crashed” to prevent a potential security exploit.

Checking Your Protection

You can see which processes are protected by DEP/NX using Task Manager’s Process tab. On Windows XP, you need to use Process Explorer instead. In either case, ensure that the “Data Execution Prevention box” is checked in the View > Select Columns menu, and a column in the process list will show the DEP/NX protection status.

As mentioned last year, Internet Explorer 8 enables DEP/NX protection by default. In IE7 and earlier, DEP/NX was disabled by default due to compatibility concerns that were resolved in IE8.

Opting-in to DEP/NX

Internet Explorer 8 uses the SetProcessDEPPolicy() API to enable DEP/NX. This provides the following benefits versus using the /NXCOMPAT linker flag:

It allows us to offer an Internet Control Panel checkbox and Group Policy option to disable DEP/NX if desired.
It enables DEP/NX on Windows XP SP3. The Windows XP loader does not check the NX Compatible bit.
It ensures that ATL_THUNK_EMULATION, an important compatibility feature, works properly.

Note: New applications without 3rd-party code compatibility concerns, targeted for use on Vista and later, should simply use the /NXCOMPAT linker flag.

Recognizing a DEP/NX Crash in Internet Explorer

When Internet Explorer 8 recovers from a DEP/NX-induced crash, it will not automatically recover the current tabs. This is a security measure designed to help prevent a malicious site from having multiple attempts to exploit a vulnerability. Instead of reloading the tabs, the browser will show the following error page:

Unfortunately, the nature of DEP/NX crashes makes it infeasible for the browser to “pin the blame” on the specific add-on that is responsible for the problem.

Why do DEP/NX Crashes Occur in the Real World?

Now, let’s take a look at why users encounter DEP/NX crashes in the real-world.

When the CPU is about to jump to a non-Executable memory page, there are three possible types of data in that page: malicious code, non-malicious code, and garbage data. I’ll discuss each of these in the following sections.

Jump Target: Malicious code

This is the scenario where DEP/NX shines. In this scenario, an attacker has put malicious data in memory that will be executed as x86 instructions if he can get the CPU to jump to it. The attacker then exploits some vulnerability to induce the CPU to jump to his data, typically using a memory-related vulnerability in an add-on or the browser itself.

In this scenario, the CPU notes that the attacker’s code is not in an executable memory page and prevents the interpretation of the attacker-supplied data as instructions. The attack is foiled and the user’s machine is protected. If not for DEP/NX, the attacker would have been able to execute his instructions and potentially infect the user’s machine with malware, steal their data, or achieve some other nefarious goal.

Now, the obvious next question is: What if the attacker can somehow get his data marked as executable?

The answer is that doing so is intentionally difficult. IE8 blocks the best known trick used to get the attacker’s data in an executable page. That means that the attacker must find some other way to get the memory page containing his instructions marked as executable.

The obvious choice would be for the attacker to call VirtualProtect() directly, passing PAGE_EXECUTE_READ as the flNewProtect flag. However, thanks to Address Space Layout Randomization (ASLR) it is difficult for the attacker to guess where the VirtualProtect function is in memory. If he guesses wrong (and he almost always will), the process will crash and not execute his attack instructions.

Jump Target: Non-malicious code

In this scenario, a browser add-on is designed in such a way that it expects to be able to execute data from memory pages which are not marked as executable, or otherwise makes a bad assumption.

There are a number of possible cases where this may happen.

Case #1: Code Generation

In the first case, the add-on (or the technology it is built upon) depends on the ability to execute dynamically generated instructions at runtime. Examples of this are the Java Virtual Machine (JVM) and the Active Template Library (ATL). These frameworks generate (“JIT compile”) executable code at runtime and jump to it. Older versions of these frameworks did not mark the memory pages containing the generated code as executable and would hence crash when DEP/NX was enabled. The Java team fixed this problem in the JVM years ago, and the ATL team also fixed this problem several versions ago.

Because ATL is so commonly used to build Internet Explorer add-ons, additional work was done to allow Windows to “emulate” the ATL Thunk code which violated DEP/NX, so that even if an add-on was compiled against an ancient version of ATL, ATL Thunk Emulation will ensure that the code runs properly inside Internet Explorer with DEP/NX enabled.

Case #2: Code Rewriting

In another common case, the add-on depends on “thunking” or modifying an existing Internet Explorer API or Windows function at runtime by rewriting the instructions in the existing function’s memory page. In order to accomplish this, the add-on uses VirtualProtect() to change the memory protection of the target page to allow Write and then update the memory with new instructions that point to some code that the add-on would like to have run inside the target function.

If the add-on fails to subsequently call VirtualProtect() to revert the memory protection back to allow Execute, the process will crash with a DEP/NX violation the next time that function is called.

More commonly, the add-on will later change the memory protection back to allow Execute, but the developer ignores the fact that it’s entirely unsafe to perform modification of shared code while any other threads are executing. While an add-on thread is modifying the code in a memory page, if any thread attempts to call any function in the same memory page, the process will crash. Internet Explorer makes extensive use of threads, so such crashes are likely if an add-on uses thunking.

Because timing is a critical factor here, the add-on may seem to “work fine” on one machine (e.g. a slower single-core machine) and always crash on another (e.g. a fast multi-core machine). This problem is just one of the major reasons why function thunking by Add-ons is not supported and is strongly discouraged.

Jump Target: Garbage data

In this scenario, inadvertent memory corruption has occurred such that the CPU is about to jump to arbitrary data somewhere in memory. This scenario is probably the most common source of DEP/NX crashes, particularly when the crash occurs at a seemingly random time, or when a browser tab is closed.

This arbitrary data isn't usually chosen by an attacker, and usually doesn’t even represent sensible x86 instructions. For instance, the jump may be to an address near 0x000000 where no code is loaded (near-null jump), if a virtual function was called off an object pointer which has been nulled. Or, the jump may be to some other address where code used to exist (stale pointer) but that memory was later freed and potentially reused for another purpose.

In this “garbage data” scenario, the process will almost always crash, even if DEP/NX were not enabled. That’s because the CPU is very unlikely to reliably execute arbitrary data as sensible x86 instructions. Most likely, the process will crash within a microsecond with an exception like “Access Violation”, “Invalid Instruction”, “Divide by 0” or similar.

Attackers look for this type of memory corruption to use as an entry point in their attacks; they may, for instance, “spray the heap” with many copies of their malicious data, then trigger the memory corruption vulnerability with the hope that the CPU will jump into a copy of their malicious code.

Resolving DEP/NX Problems

Your best bet to resolve DEP/NX problems in Internet Explorer is to first confirm that the problem is caused by a buggy browser add-on. You can do this by running IE in No Add-ons Mode. After confirming that the problem is related to an add-on, you should use the browser’s Manage Add-Ons feature to disable unwanted add-ons and find updated versions of any add-ons that you wish to keep.

If you find that you’re encountering DEP/NX crashes in multiple software applications, it’s possible that you have malicious or buggy system software installed (e.g. malware or a buggy anti-virus product). You should check your system for malware and ensure that you install the latest updates for your system software.

Frequent DEP/NX crashes also suggest that your computer might have a hardware problem (e.g. bad system memory). To help rule out hardware failure, you can use the Windows Memory Diagnostic.

Conclusion

DEP/NX provides an important defense against malicious websites that may try to exploit vulnerabilities in your add-ons or web browser. By ensuring that you are running the latest version of add-ons and system software, you can improve your security and minimize the incidence of DEP/NX crashes. If you're currently using an older version (6 or 7) of Internet Explorer that does not have DEP/NX protections enabled by default, you should upgrade to IE8 as soon as possible.

Thanks for reading!

-Eric

DotNet UserControls Restricted in IE8

2009-10-09T05:17:00Z

In the past, Internet Explorer supported a really easy way to host .NET UserControls in HTML. These controls worked much like ActiveX controls, but because they ran with limited permissions, sandboxed by the .NET Framework, they would download and run without security prompts.

It was a very cool technology, but didn’t see much use in the real-world, partly because the .NET Framework wasn’t broadly deployed when the feature was introduced. Later, ClickOnce, WPF, and other technologies took center stage, leaving this relic around, mostly unused beyond developer demonstration pages and tutorials.

Until the summer of 2008, that is. At BlackHat 2008, security researchers Dowd and Sotirov revealed that the loader for UserControls enabled bypass of memory-protection mechanisms, meaning that browser vulnerabilities could be exploited with improved reliability.

While Protected Mode and other features are useful to constrain the impact of vulnerabilities, DEP/NX and ASLR memory protection are a very important part of the overall mitigation strategy. After investigating the options, crawling the web to examine use “in the wild,” and consulting with the .NET team, we elected to disable UserControls in the Internet Zone by default for IE8.

Now, since the UserControls feature was first introduced, IE’s security settings allowed disabling ".NET Framework-reliant components," but the existing settings were overly broad. They controlled not only UserControls, but also out-of-process features like ClickOnce. Because out-of-process use of .NET is not a vector for memory-protection-bypass in the browser, we chose to create a new URLAction that would restrict only use of UserControls.

IE8 introduced the URLACTION_DOTNET_USERCONTROLS setting, which allows .NET UserControls to load only from Intranet and Trusted pages by default. On Internet pages, the controls are blocked as if they had failed to download. This setting is not exposed in the Internet Options dialog or in the Group Policy editor; it can only be controlled via the registry keys.

Reducing attack surface by removing an extensibility feature was painful decision, but ultimately a good one. Not long after we made this change, the new URLAction would cleanly block exploitation of a browser vulnerability that was unveiled at the CanSecWest security conference.

IE8 includes a number of important security features and defense-in-depth changes that raise the bar against the bad guys. If you haven’t upgraded yet, you should do so today!

thanks,

-Eric

The User-Agent String: Use and Abuse

2009-10-08T05:19:00Z

When I first joined the IE team five years ago, I became responsible for the User-Agent string. While I’ve owned significantly more “important” features over the years, on a byte-for-byte basis, few have proved as complicated as the “simple” UA string.

I (and others) have written a lot about the UA string over the years. This post largely assumes that you’re familiar with what the user-agent string is and what it’s commonly (mis)used for.

In this post, I’ll try to summarize why the UA string causes so many problems (beyond browser version sniffing), and expose the complex tradeoff between compatibility and extensibility.

Background

First things first-- you can check the UA string currently sent by your browser using my User-Agent string test page.

Do you see anything in there that you weren’t expecting?

Changing the User-Agent String at Runtime

For IE8, we fixed significant bugs in the UrlMkSetSessionOption API, which allows setting of the User-Agent for the current process. Before IE8, calling this API inside IE would (depending on timing) set the User-Agent sent to the server by WinINET, or set the User-Agent property in the DOM, but never properly set both.

I developed a simple User-Agent Picker Add-on for IE8 that allows you to change your User-Agent string to whatever you like. You can then easily see how websites react to various UA strings. For instance, try sending the GoogleBot UA string to MSDN to see how that site is optimized for search.

Internally, the add-on simply exercises the URLMon API:

UrlMkSetSessionOption(URLMON_OPTION_USERAGENT, szNewUA, strlen(szNewUA), 0)

Alternatively, Web Browser Control hosts can change the User-Agent string sent by hyperlink navigations by overriding the OnAmbientProperty method for DISPID_AMBIENT_USERAGENT. However, the overridden property is not used when programmatically calling the Navigate method, and it will not impact the userAgent property of the DOM's navigator or clientInformation objects.

Extending the User-Agent String in the Registry

It’s trivial to add tokens to the User-Agent string using simple registry modifications. Tokens added to the registry keys are sent by all requests from Internet Explorer and other hosts of the Web Browser control. These registry keys have been supported since IE5, meaning that all currently supported IE versions will send these tokens.

Other browsers (Firefox, Chrome, etc) do not offer the same degree of ease in extending the UA string, so it’s uncommon for software to extend the UA string in non-IE browsers.

The Fiasco

Unfortunately, the ease of extending IE’s UA string means that it’s a very common practice. That, in turn, leads to a number of major problems that impact normal folks who don’t even know what a UA string is.

A few of the problems include:

Many websites will return only error pages upon receiving a UA header over a fixed length (often 256 characters).
In IE7 and below, if the UA string grows to over 260 characters, the navigator.userAgent property is incorrectly computed.
Poorly designed UA-sniffing code may be confused and misinterpret tokens in the UA.
Poorly designed browser add-ons are known to misinterpret how the registry keys are used, and shove an entire UA string into one of the tokens, resulting in a “nested” UA string.
Because UA strings are sent for every HTTP request, they entail a significant performance cost. In degenerate cases, sending the UA string might consume 50% of the overall request bandwidth.

Two real-world examples:

My bank has problem #1. They have security software on their firewall looking for “suspicious” requests, and the developers assumed that they’d never see a UA over 256 bytes.

Some major sites are using super-liberal UA parsing code (problem #3) to detect mobile browsers. Unfortunately, for instance, Creative Labs adds the token “Creative AutoUpdate” to the UA string. Naive server code sees the characters pda inside that token and decides that the user must be on a mobile browser. The server might then return WML content that the desktop browser will not even render, or provide an otherwise degraded experience. Worse still, some sites don’t send a Vary: User-Agent response header when returning the mobile content, meaning that network proxies will sometimes start sending everyone content designed for mobile devices.

Ultimately, the problem is what economists call the Tragedy of the Commons, although personally I prefer the visual representation. You might remember that the extensibility of the Accept header leads to the same problem, although that header is sent so unreliably that no sane website would depend upon it.

Standards

It’s tempting to look to the standards for restrictions on the UA string. Unfortunately, the RFC for HTTP has little to say on the topic:

14.43 User-Agent

The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens (section 3.8) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application.

User-Agent = "User-Agent" ":" 1*( product | comment )

Example:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Notably, the RFC does not define a maximum length for the header value, and does not provide much guidance into what “subproducts which form a significant part of the user agent” means. It suggests a few broad uses of the UA string on the server-side, without discussion of what problems such usage might introduce.

Motivations for UA Modification

OEMs and ISVs have a number of motivations for adding to the UA string.

Metrics. Every server on the web can easily tell if your software is installed.
Client capability detection. JavaScript can easily detect if your (ActiveX control / Protocol Handler / Client application / etc) is available.
User Tracking. I don’t know of any current offenders, but at some point in the past some software would add a GUID token to the UA string. This token would effectively act as an invisible “super-cookie” that would be sent to every site the user ever visited.

Now, scenario #3 is clearly evil, and we have no desire to support it. Scenarios #1 and #2 aren’t inherently bad—but advertising to every site in the world that a given piece of software is available on the client is probably the wrong design.

Known UA Tokens

Here are some explanations of common tokens found in real-world IE UA strings.

Token	Meaning / Component
SV1	Security Version 1- Indicates that XP SP2 was installed. Removed from IE7.
SLCC1	Software Licensing Commerce Client- Indicates Vista+ AnyTime Upgrade component is available.
MS-RTC LM 8	Microsoft Real Time Conferencing Live Meeting version 8
InfoPath.2	InfoPath XML MIME Filter
GTB6	Google Toolbar
Creative AutoUpdate	Creative AutoUpdate software
Trident/4.0	IE8 version of HTML Renderer installed
Zune 3.0	Zune Software client
Media Center PC 6.0	It's a Media Center PC
Tablet PC 2.0	It's a TabletPC
.NET CLR 3.5.30729	The .NET Common Language Runtime
chromeframe	Google ChromeFrame addon
fdm	FreeDownloadManager.org add-on
Comcast Install 1.0	Comcast High-speed Internet installer
OfficeLiveConnector.1.3	??
OfficeLivePatch.0.0	Comcast browser installer
WOW64	Running in 32bit IE on 64bit Windows
Win64; x64	Running in 64bit IE
msn OptimizedIE8	Installed with MSN branding and services
yie8	Installed with Yahoo! branding and services

Alternatives to UA Modification

In many cases, allowing client-side script to detect a capability without forcing the browser to send that information to the server would be sufficient. While new APIs might be proposed for this purpose, we need an alternative that already works in all versions of IE.

You probably know that Conditional Comments can be used to detect the IE version, but they can also be used to detect custom information about any component listed in the registry’s version vector key. For instance, Windows 7 uses the new WindowsVersion entry to allow script to detect the OperatingSystemSKU.

To expose your capabilities via conditional comments, simply create a REG_SZ inside HKLM\SOFTWARE\Microsoft\Internet Explorer\Version Vector. The new entry should be named uniquely (e.g. EricLaw-SampleAddon) and contain a string in the format x.xxxx (e.g. 1.0002).

You can then detect the version (or absence) of your component using conditional comments:

These conditional comments are hidden from non-IE browsers, and will work properly in IE5 and above.

Conclusions?

Extensibility is an important aspect for any major software project, but can also be the source of severe compatibility problems that are extremely painful to fix in the future. As we increase the power of the web platform, we need to find ways to ensure that extension points and the tragedy of the commons don’t destroy the user’s experience.

Until next time,

-Eric

Good News: Microsoft Security Essentials Released

2009-10-06T18:08:00Z

Microsoft’s free new anti-virus / anti-malware realtime scanner is now available as a free download. Installing MSE, a traditional signature-based scanner, alongside IE8’s URL Reputation-based SmartScreen Filter yields comprehensive protection to help keep your computers safe from malicious software.

There are a few things I like about MSE over other scanners:

You won’t see advertisements trying to “upsell” you to a professional version.
You won’t see “scareware” style warnings trying to convince you that MSE is providing value-- “oh my gosh, we found a cookie! Panic!”
Signature updates are free—there’s no “subscription” that will expire and leave you unprotected.
The product doesn’t install a bunch of 3rd party toolbars or other such nonsense— unfortunately, a common business model for other “free” products.

The product has been getting some great reviews. I’ll definitely be installing this on my parent’s computer the next time I’m home. :-)

-Eric

Internet Explorer Cannot Download https://something

2009-10-03T00:55:00Z

Earlier today, I was asked to troubleshoot a secure site where file downloads were always failing. Having seen this problem many times often over the years, I immediately suspected that the web developer wasn’t aware that

if a user tries to download* a file over a HTTPS connection, any response headers that prevent caching will cause the file download process to fail.

* Note that this applies to “downloaded” files that open in programs other than IE. It does not apply to resources that render inside IE’s HTML rendering engine, like images/script/css/etc.

When Internet Explorer encounters a HTTPS download that will not be cached, the download is aborted with the following dialog box:

The Fiddler web debugger allows you to easily check to see whether a download contains headers that prevent caching.

Cache-preventing headers include:

A Cache-Control header with the tokens no-cache, no-store, or max-age=0
An Expires header that specifies a time in the past
A Vary header that specifies almost anything

Without changing the site’s code, you can easily confirm that the problem is caused by cache-prevention headers using Fiddler’s Filters tab:

Fiddler allowed me to determine that today’s instance was caused by cache-preventing headers. After the web developer updates these headers to allow local caching (e.g. Cache-Control: private, max-age=15) the file download process will work correctly.

-Eric

PS: In the unlikely event that the user has checked the Do not save encrypted pages to disk option inside Tools / Internet Options > Advanced, this error dialog may be shown for any file downloads from secure sites, regardless of caching headers. I recommend that folks avoid enabling this option, and use the Delete Browser History on Exit feature instead.

New Tool: Compare IE Security Settings

2009-10-02T00:11:00Z

“IE Zone Comparer” was designed to provide additional visibility into URLMon's security zone settings. Pick any two collections of security zone settings, and IE Zone Comparer displays the values of those settings, highlighting any differences between the two collections.

Note: Updated on 11/7/2009 to offer details on "Effective" policy.

http://blogs.technet.com/fdcc/archive/2009/11/07/viewing-and-comparing-ie-security-zone-settings-enhanced.aspx

Understanding Domain Names in Internet Explorer

2009-09-19T03:01:00Z

Web browsers use domain names for a variety of purposes, but how they’re used is much more complicated than most developers realize. In this post, I’ll attempt to cover the most important aspects of this topic.

Definitions

When talking about “domains” the terminology alone is confusing (and contentious). So, let’s start with some simplistic definitions for terms used in this post:

A label is a single component of a domain name string, delimited by periods. For instance, “www” “microsoft” and “com” are the three labels in the domain name “www.microsoft.com”
A plainhostname is an unqualified, single label hostname like “Payroll”, which typically refers to a server on a local intranet.
A FQDN is an absolute, fully-qualified domain name, like “www.microsoft.com”
A Public Suffix is the suffix portion of a FQDN under which independent entities may register subdomains. For example, ltd.co.im is a Public Suffix. A Public Suffix contains one or more labels. Sometimes the term “effective TLD” is used as a synonym.
A TLD is a top-level-domain, the right-most label of a domain name
A gTLD is a generic TLD, like ".com”, “.net”, “.gov”, etc
A ccTLD is a country-code TLD, like “.us” or “.ru”
ICANN (the Internet Corporation for Assigned Names and Numbers) is responsible for the creation and management of TLDs

When web developers talk about “the domain,” they’re often referring to what this post calls the Private Domain:

A Private Domain is a single label with a Public Suffix appended.

For instance, the two Private Domains “Acme.ltd.co.im” and “Bayden.ltd.co.im”, are each independently operated subdomains of Public Suffix “ltd.co.im”.

Okay, now on to the fun stuff.

Domains and the IURI Interface

First, some foreshadowing…

IE7 and above use a Consolidated URI handling feature which exposes the IURI interface. Let’s have a quick look at a partial list of IURI property values from a sample URI: http://www.example.com/path/file.ext?query=val#frag

Uri_PROPERTY_ABSOLUTE_URI "http://www.example.com/path/file.ext?query=val#frag"

Uri_PROPERTY_DISPLAY_URI "http://www.example.com/path/file.ext?query=val#frag"

Uri_PROPERTY_RAW_URI "http://www.example.com/path/file.ext?query=val#frag"

Uri_PROPERTY_SCHEME_NAME "http"

Uri_PROPERTY_DOMAIN
aka Private Domain "example.com"

Uri_PROPERTY_HOST
aka FQDN or Plainhostname "www.example.com"

Uri_PROPERTY_HOST_TYPE 1

Uri_PROPERTY_PORT 80

Uri_PROPERTY_PATH "/path/file.ext"

Uri_PROPERTY_QUERY "?query=val"

It’s important to note that if the URI contains only a plainhostname (e.g. “http://example/”) or a Public Suffix (e.g. “http://co.uk/”), then Uri_PROPERTY_DOMAIN is null.

Why Do Browsers Care About Domains?

Every browser must be able to determine the Private Domain for a number of uses, but in this post I’ll concentrate on IE’s use of this information.

1. Domain Highlighting in the Address Bar

IE8’s Domain Highlighting feature renders the Private Domain in black text and the rest of the URL in gray to help prevent the use of misleading URLs in spoofing attacks.

If the URL contains a plainhostname, the address bar will render the plainhostname in black instead.

2. Quota management for Local Storage

IE8 applies a per-Private Domain quota to values stored using the HTML5 Local Storage API.

If the Uri_PROPERTY_DOMAIN is null (because the URL contains a plainhostname) the browser will enforce the quota against Uri_PROPERTY_HOST instead.

3. document.domain relaxation

Same-Origin-Policy typically means that two pages must have exactly-matching FQDNs in order to script against each others’ DOM. However, HTML allows a page to relax its document.domain property to a suffix of its current value to enable cross host DOM communication within a single Private Domain. Script is not permitted to change its document.domain property to a string shorter than the private domain. This prevents sites from unrelated organizations from intentionally or inadvertently scripting against each others’ DOM.

4. HTTP Cookies

When setting a cookie, a website may specify which hosts the cookie should be sent to using the domain attribute. The browser must block attempts to set a cookie where the domain attribute does not end with the current page’s Private Domain. Failure to do so results in privacy and security concerns.

Privacy: Allowing unrelated domains to share cookies can result in “super-cookies”-- cookies which are sent to multiple unrelated organizations that happen to share a Public Suffix.

Security: Session-fixation attacks, where a good site and an evil site share a Public Suffix, and the evil site sets a malicious cookie on the Public Suffix so that the Good site is sent the evil cookie.

5. Security Zones – Mapping Domains to Zones

Because Public Suffixes are typically shared by multiple unrelated organizations, URLMon does not permit users to add all sites in a given public-suffix to a security zone.

We are aware that there are scenarios where such assignments may be desirable to some organizations (e.g. perhaps I would like to assign *.mil to the Trusted Sites Zone).

6. Security Zones – Automatic Zone Determination

URLMon (subject to some caveats) is configured by default to map plainhostnames to the Intranet zone.

7. Per-site ActiveX

When the user uses the Information Bar to allow an ActiveX control to run, Internet Explorer 8’s Per-Site ActiveX feature adds the current Private Domain to the Allow list for that control.

8. Compatibility View

Internet Explorer 8’s Compatibility View button adds the current Private Domain to the compatibility view list.

9. XSS Filter

IE8’s XSS Filter uses the Private Domain to determine whether a given navigation crosses from one Private Domain to another.

10. InPrivate Filtering

IE8’s InPrivate Filtering feature uses Private Domain information to help determine whether a given request is being sent to a 3rd party site.

11. Preserve Favorite Website Data

IE8’s Delete Browsing History feature includes a new “Preserve Favorites website data” option. As I described back in this post from June, this feature relies on the Private Domain to help determine whether stored data is related to one of the user’s favorite websites.

The Challenge of ccTLDs

In the early days of the web, most ccTLDs were organized in such a way that it was relatively easy to heuristically determine the Public Suffix of any FQDN. Over time, however, different ccTLDs decided that they wanted to create new Public Suffixes within their ccTLD, or decided to allow registration of Private Domains that the heuristics would incorrectly treat as Public Suffixes. Some nations (like Tuvalu) have outsourced registration of subdomains and allow anyone to obtain Private Domains within their ccTLD (.TV).

Prior to IE8, there was no one codepath in IE where the Private Domain was calculated, so over time several point-fixes were made to liberalize cookie setting in certain ccTLDs.

The heuristic Private Domain determination algorithm in IE5+ is:

1> If the final label is empty, drop it for the purposes of this algorithm
Otherwise "www.example.com." would have four labels "www", "example", "com", "". Instead, we drop the final label.

2> Name the labels Ln,...,L3,L2,L1; decreasing from start (Leftmost=Ln) to finish (Rightmost=L1).
If at any point in this algorithm the result demands >n labels, getPrivateDomain returns "".

3> Check n > 1. If not, there's no PublicSuffix, just a plainhostname. Return ""; exit.
Dotless FQDNs consist of a host only, there is no domain.

4> Check L1 == "tv". If so, getPrivateDomain returns L2.L1; exit.
"tv" is a special-case "completely flat" ccTLD for historical reasons.

5> Check Len(L1) > 2. If so, getPrivateDomain returns L2.L1; exit.
Len(L1)>2 suggests L1 is a gTLD rather than a ccTLD.
If Len(L1)<=2 we assume L1 is a part of a ccTLD.

6> Check if L2 in gTLD list "com,edu,net,org,gov,mil,int". If so, getPrivateDomain returns L3.L2.L1; exit.
gTLDs, when they appear immediately left of a ccTLD (modulo exception in step 4), are considered a part of the Public Suffix.

7> If L1 is in the list "GR,PL" AND L2 is NOT in the gTLD list, getPrivateDomain returns L2.L1; exit.
GR and PL are considered "flat" ccTLDs EXCEPT when a gTLD appears in L2.
getPrivateDomain("a.pl") returns "a.pl"
getPrivateDomain("a.uk") returns ""

8> If Len(L2) < 3 getPrivateDomain returns L3.L2.L1; exit.
getPrivateDomain("aa.bb.cc") returns "aa.bb.cc"

9> Otherwise, getPrivateDomain returns L2.L1
getPrivateDomain("aa.bbb.cc") returns "bbb.cc"

While this heuristic worked pretty well for many years (and still works reasonably well in general) it clearly was becoming increasingly complicated due to the fact that each ccTLD established different operating practices (and those, in turn, changed over time).

Changes in Internet Explorer 8

For IE8, we’ve updated major codepaths to use CURI’s Uri_PROPERTY_DOMAIN for Private Domain determination, helping to ensure consistency throughout the various browser components.

IE8's version of URLMon maintains a list of special-cases which are used as exceptions to the default heuristics that CURI uses. You can click this link to view the list maintained as an XML resource inside URLMon.dll. The list contains elements which should be treated as Public Suffixes (the XML nodes named “tld”) and elements which should be treated as private domains (the XML nodes named “domain”).

From a browser architecture perspective, lists like this one are the option of last resort, for a number of important reasons. However, there’s no currently no standard that promises relief. One proposal which has been discussed in a few forums is to allow the DNS itself to indicate (via a new record) which names are part of a Public Suffix and which are part of a Private Domain, but that approach is not without problems.

The (Coming) Challenges with gTLDS

ICANN recently voted to allow organizations to create new generic TLDs. Introduction of new gTLDs may introduce additional problems, because previously most of the “special cases” were found only in ccTLDs. Other parties (like Certificate Authorities) would also likely be significantly impacted by this liberalization of gTLDs.

As this area is still developing, it will likely be the topic of a future post.

Until then…

-Eric

Two New Tools Available from the SDL Team

2009-09-18T04:18:00Z

Yesterday, IE Team alumnus Jeremy Dallman posted over on the Security Development Lifecycle team’s blog, announcing the release of BinScope and MiniFuzz. These two tools are part of the toolset that the Internet Explorer team uses to help verify the security of our product code.

If you’re building an Internet Explorer add-on (or any other product really), they’re great (free) additions to your toolbox to help ensure that the bad guys can’t abuse your code. The SDL team also posted two demo videos (BinScope video & MiniFuzz video) explaining the tools, and a whitepaper on how to integrate the SDL into an existing VSTS project.

-Eric

Policy	Result
0	Protected mode prevents the process from launching.
1	Protected mode silently launches the broker as a low integrity process.
2	Protected Mode prompts the user for permission to launch the process. If permission is granted, the process is launched as a medium integrity process.
3	Protected Mode silently launches the broker as a medium integrity process.

Uri_PROPERTY_ABSOLUTE_URI	"http://www.example.com/path/file.ext?query=val#frag"
Uri_PROPERTY_DISPLAY_URI	"http://www.example.com/path/file.ext?query=val#frag"
Uri_PROPERTY_RAW_URI	"http://www.example.com/path/file.ext?query=val#frag"
Uri_PROPERTY_SCHEME_NAME	"http"
Uri_PROPERTY_DOMAIN aka Private Domain	"example.com"
Uri_PROPERTY_HOST aka FQDN or Plainhostname	"www.example.com"
Uri_PROPERTY_HOST_TYPE	1
Uri_PROPERTY_PORT	80
Uri_PROPERTY_PATH	"/path/file.ext"
Uri_PROPERTY_QUERY	"?query=val"