Eight new IIS security holes exposed
A patchy Web server
There are eight new security stuff-ups affecting various editions of Microsoft IIS (Internet Information Server), the most serious of which will enable an attacker to take over the system, MS revealed today.
If you're wondering why you haven't heard about them before, chalk it up to Trustworthy Computing, a Redmond policy which leaves everyone exposed to attack until MS is satisfied with its patches and spills the beans. We prefer to know these things as soon as possible so we can look into temporary workarounds and shutter the window of opportunity straight away, but MS is clearly opposed to that approach. (One workaround we rather like is called Apache, but we digress....)
Before we get into the gory details, we have to mention that we've received anecdotal reports that some of the MS patches have been breaking some of the machines they're installed on. So do test them before integrating them into critical systems. If you've installed one of the patches, I'd like to hear from you whether your experience was good or bad, in hopes of confirming the problem or, alternatively, putting the rumor down.
And now for a brief roundup.
First up, a buffer overflow involving chunked encoding with the ASP (Active Server Page) ISAPI filter. This can be exploited to crash or run arbitrary code on the machine. Essentially, an attacker can cause IIS to miscalculate incoming data and so allocate undersized buffers. There's a good writeup and a sample exploit by eEye, which discovered it, posted here. Affects IIS 4.0 and 5.0.
Next, a mysterious one which Microsoft claims to have discovered and which it says "is related to the preceding one, but which lies elsewhere within the ASP data transfer mechanism." Whatever it is, it appears it can be exploited much like the chunk encoding flaw above, and affects IIS 4.0, 5.0 and 5.1.
We have another buffer overflow involving HTTP header processing, in which an attacker can spoof delimiter checking and persuade IIS that delimiting characters are present when they're not. Thus a malicious URL with bogus HTTP header field values can overstuff the buffers created to process them. Affects IIS 4.0, 5.0 and 5.1.
And we have yet another buffer overflow, this time caused by a bad safety check for server-side includes, which MS caught. It's possible for an invalid and very long file name to pass the include safety check, resulting in a file name bigger than its intended buffer, and obviously a buffer overflow. Affects IIS 4.0, 5.0 and 5.1.
We have one more, this time involving the HTR ISAPI extension in which malformed .htr file requests can cause a heap overflow. According to MS, an attacker can "cause [IIS] to temporarily stop providing Web services or, in very unusual cases, could gain control of the server." According to @Stake's Dave Aitel, who discovered it, "this heap overflow can be used to execute arbitrary machine code. In the default installation, this results in remote execution in the IUSR_machine security context." The difference in these two accounts is a matter of emphasis. In any case an attacker wouldn't get administrator privileges directly from exploiting it, but the ability to run arbitrary code means he wouldn't have terribly far to go. The relevant @Stake advisory contains a few details left out of the MS bulletin, and is worth reading. Aitel has also developed a free tool called Spike which finds the HTR and ISAPI overflow vulns, available here. Affects IIS 4.0 and 5.0.
For a change of pace, we've got a denial of service vulnerability involving the way an ISAPI filter included in FrontPage Server Extensions and ASP.NET generates a errors when a request is received containing a URL exceeding the maximum length set by the filter. IIS attempts to process the URL while returning an error message, resulting in an access violation which causes it to crash. Affects IIS 4.0, 5.0, and 5.1
We've got another denial of service vulnerability where an attacker can establish an FTP session in which a status request can interfere with normal error reporting, causing an access violation. This can crash both FTP and HTTP services. Affects IIS 4.0, 5.0 and 5.1.
And last but not least, we've got three CSS (Cross-Site Scripting) vulnerabilities, which MS has lumped together thus: "One involving the results page that?s returned when searching the IIS Help Files, one involving HTTP error pages; and one involving the error message that?s returned to advise that a requested URL has been redirected."
"All of these vulnerabilities have the same scope and effect: an attacker who was able to lure a user into clicking a link on his web site could relay a request containing script to a third-party web site running IIS, thereby causing the third-party site?s response (still including the script) to be sent to the user. The script would then render using the security settings of the third-party site rather than the attacker?s."
If you'd like to know what that means, you can check out a Web page by Thor Larholm which tells you a few things MS neglects. Such things as how CSS allows for "stealing cookies from any IIS site, cross-domain scripting to any IIS site, hijacking Hotmail and Passport accounts, elevating privileges through ActiveX components, hijacking the MSN Messenger client, etc." Affects IIS 4.0, 5.0 and 5.1.
The Microsoft bulletin, from which much of the above has been drawn, is located here. It also contains links to the three patches MS has released, with cautions, caveats and useful advice. And don't forget to check out the IIS lockdown tool, and the URL Scanning tool which MS provides free. ®