Slashdot Mirror


IE8's XSS Filter Exposes Sites To XSS Attacks

Blue Taxes writes "The cross-site scripting filter that ships with Microsoft's Internet Explorer 8 browser can be abused by attackers to launch cross-site scripting attacks on websites and web pages that would otherwise be immune to this threat. The IE8 filter works by scanning outbound requests for strings that may be malicious. When such a string is detected, IE8 will dynamically generate a regular expression matching the outbound string. The browser then looks for the same pattern in responses from the server. If a match is made anywhere in the server's response, the browser assumes that a reflected XSS attack is being conducted and the browser will automatically alter the response so that the XSS attack cannot succeed. The researchers figured out a way to use IE8's altered response to conduct simple abuses and universal cross-site scripting attacks, which worked against sites that would not otherwise have been vulnerable to XSS." Here is the researchers' backgrounder (PDF) on the attack. Microsoft says that they have issued two patches that address the issue, but the researchers insist that holes remain.
Update: 04/20 14:06 GMT by KD : Microsoft's Security Response Center has issued a statement on the vulnerability.

22 of 84 comments (clear)

  1. Microsoft's response by seifried · · Score: 4, Informative
    1. Re:Microsoft's response by Z00L00K · · Score: 5, Funny

      As usually they have a disclaimer too:

      *This posting is provided "AS IS" with no warranties, and confers no rights*

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    2. Re:Microsoft's response by StuartHankins · · Score: 4, Interesting

      An additional update to the IE XSS Filter is currently scheduled for release in June. This change will address a SCRIPT tag attack scenario described in the Blackhat EU presentation. This issue manifests when malicious script can “break out” from within a construct that is already within an existing script block. While the issue identified and addressed in MS10-002 was identified to exist on high-profile web sites, thus far real-world examples of the SCRIPT tag neutering attack scenario have been hard to come by.

      (emphasis mine)

      JUNE??? They are waiting until JUNE to "schedule the release" for this bugfix? And what is this "hard to come by", either they have found examples or they haven't. My guess is they have or they would have been quick to state "we have found no examples in the wild". And somehow, I don't know, maybe someone giving a presentation on the topic might signify that others know about this too and may be actively taking advantage of it now? Maybe a teensy chance of that?

      <sarcasm>Yes, folks, that's why you pay Microsoft all the big bucks. Their process seems to work so well... maybe they can work this into a regular Patch Tuesday so you don't have to reboot your servers / schedule an outage so many times that week.</sarcasm>

      This is fast-food software design, cheap and not particularly good for you. This is what you get when people have low expectations and are sensitive only to price -- how many patch Tuesdays so far this year didn't affect every version of IE, every version of Office and every recent version of Windows (and for most of these, require reboots)? It's way beyond sad and way past "whoops" when a major software manufacturer has this many bugfixes and problems with almost all of their software. Yes, software is complicated, but slow down and implement some quality control techniques for goodness' sake.

      This is just churning turds for profit, and we're stupid enough to eat them.

    3. Re:Microsoft's response by gzipped_tar · · Score: 2, Interesting

      April is the cruellest month, breeding
      Bugs out of the crap app, delaying
      Fixes and patches, stirring
      Angry geeks with slashdot dupe.

      --
      Colorless green Cthulhu waits dreaming furiously.
    4. Re:Microsoft's response by gzipped_tar · · Score: 5, Funny

      Nah, it's more like this:

      $ make meal
      [tons of compiler output]
      $ ./meal
      Segmentation Fault. Core dumped.

      --
      Colorless green Cthulhu waits dreaming furiously.
    5. Re:Microsoft's response by totally+bogus+dude · · Score: 2, Informative

      Well maybe they've decided to actually test the patch before releasing it? :)

      I discovered today that a patch for a vulnerability in the IIS SMTP service causes the settings for the service to be reset if you're running it on Server 2008 (2003 doesn't seem to be affected, AFAIK).

      Unfortunately we applied that patch (and others) last Wednesday and don't have regular automated testing of our website's ability to deliver mail to localhost, so took a while for us to notice... a quick Google lead me to this discussion where I discovered the cause.

    6. Re:Microsoft's response by LinuxAndLube · · Score: 2, Informative

      I just read this: "Now when you look at Microsoft today they do more to secure their software than anyone. They're the model for how to do it. They're not perfect; there's room for improvement. But they are definitely doing more than anybody else in the industry, I would say." [ http://news.cnet.com/8301-27080_3-20002317-245.html?tag=rtcol;inTheNewsNow ] I think most people in the know would agree with him.

    7. Re:Microsoft's response by thornmaker · · Score: 5, Informative

      The last sentence of the article's summary is completely wrong. I am one of the "original researchers" for this issue (p42.us is my website). The patches that have been issued by Microsoft up to this point are successful at eliminating the primary security vulnerability, to the best of our knowledge. The main security vulnerability described in our white paper was disclosed to Microsoft last fall and Microsoft fixed the issue in January 2010. The one case that has not been addressed by the filters is very rare and extremely unlikely to be found on a given websites.

    8. Re:Microsoft's response by Culture20 · · Score: 2, Interesting

      The one case that has not been addressed by the filters is very rare and extremely unlikely to be found on a given websites.

      Between now and June 8th? That's seven weeks! Seems we're lucky that we're not waiting until June 14th this year.

  2. More reason to... by Anonymous Coward · · Score: 5, Funny

    stick to IE6. Long live Internet Explorer 6!

    1. Re:More reason to... by julesh · · Score: 3, Funny

      stick to IE6. Long live Internet Explorer 6!

      Why stick with 6? I'm using IE3. When was the last time you heard of an IE3 exploit being released? I'm considering a switch to Netscape Navigator 1.1, just in case.

  3. Re:My first! by Fluffeh · · Score: 4, Funny

    Close, but no cigar.

    Really, if you want a first post, subscribe to the site. You will get your silly kicks, and the rest of us will at least know you are making a valuable contribution to the site by paying the rest of the users to be silly.

    --
    Moved to http://soylentnews.org/. You are invited to join us too!
  4. Re:Deserve what you get by TrancePhreak · · Score: 5, Informative

    And there is no way to control it either.

    You mean like right clicking and selecting "not junk" ?

    --

    -]Phreak Out[-
  5. Re:What if someone made a firefox addon? by gzipped_tar · · Score: 3, Insightful

    You hired a guard and he raped your daughter. Now your neighbor also has a daughter and he hired another guard. Somehow, that guard decided to emulate the broken behavior of your guard as well.

    Would that not simply mean that those who were born daughters were simply inviting rapists as opposed to rapists somehow being responsible?

    If you can't understand the above analogy, here's a Car Analogy for you.

    You drove a Toyota on the road and killed a pedestrian due to negligence. Someone else driving a Ford emulated your broken behavior and killed another pedestrian. It means that the pedestrians were simply choosing the insecure way of transportation as opposed to drivers somehow being responsible.

    --
    Colorless green Cthulhu waits dreaming furiously.
  6. Oh the horrors! by Hurricane78 · · Score: 4, Insightful

    will dynamically generate a regular expression matching the outbound string

    RegEx? Dynamic? Generated?? I don’t think I’m the only one who got the chills and raising hackles from this...
    I think this deserves an award for the most made-for-disaster concept even conceived. ^^

    --
    Any sufficiently advanced intelligence is indistinguishable from stupidity.
    1. Re:Oh the horrors! by Statecraftsman · · Score: 2, Interesting

      The only thing crazier than a dynamically generated regex is running a proprietary browser on top of a proprietary operating system.

    2. Re:Oh the horrors! by AaxelB · · Score: 2, Insightful

      Even auditing the code doesn't help. The only thing crazier than running a browser and OS whose code you've not audited is auditing the browser's and OS's code but then compiling them! The only way out is to write the compiler in pure machine code yourself.

      ...and then you just have to run it in your head -- you can't trust hardware!


      More seriously, proprietary software requires you place all your trust in one entity. With open-source software, that trust is more distributed, and it's less likely that someone was able to bury something malicious, especially if there's an active and large developer community. This isn't at all to say there can't be anything malicious (or flawed) in OSS, but it's easier to trust a large group of people that have nothing to gain from duping you and who know they would probably get caught than it is to trust a single company that might have something to gain and can probably get away with it.

      With proprietary software, you're betting that a specific company won't fuck you over.
      With OSS, you're betting that at least one person out of a community of developers (and users who actually do audit code) won't fuck you over.

  7. Re:Not my site... by grrowl · · Score: 5, Funny

    I'm sure your user will be deeply affected by this.

  8. I don't see why by Moraelin · · Score: 5, Insightful

    Honestly, I usually am the first to lay the blame on developers for doing half-arsed jobs, but in this case... really, why would I blame a site for a modification a third party plugin does to their HTML code? As per the specs, their code is secure. Then someone comes and changes it to something insecure. Why would you hold the former responsible for something done by the latter.

    I mean, let's say you write some program, and check your array bounds and everything. Then a year later I'm brought in as a consultant and, perhaps in the name of optimizing speed, inadvertently bypass one of your checks and introduce a buffer overflow vulnerability. Would you say that you should be held responsible for my changes? Would you say your code was simply insecure if it allowed that? Why? By what definition of "insecure"?

    Plus, I always believed that responsibility should also come with enough power to do what you're responsible for. E.g., if you're responsible that a project finishes on time, then you should also have the power and budget to make sure it does. Responsibility without any power is IMHO just a name for "scapegoat."

    In this case, the IE code and its modifications are completely outside the web designer's control. If Microsoft introduces a new vulnerability next month, which turns a whole other chunk of perfectly good web programming into an XSS exploit vector, the web designer can't do anything to prevent them. It's exactly that scapegoat scenario. You're proposing to hold someone responsible for something they can't prevent or even influence at all.

    Plus, it's not like MS's code is public domain or even has an open and detailed specification. You can work around Javascript or HTML problems because you can know exactly what they are, what that code does, what does it output for a given input, etc. (Well, that is, if the browsers actually implemented the specs;)) In this case to work around MS's bug du jour, someone has to keep basically reverse-engineering whatever idiocy MS implemented this time. It seems to me like an undue burden.

    Plus, honestly, writing stuff that only works because of a bug in another module (in this case the browser) is bad practice. Now I'm aware that it can't always be avoided. But at least in an ideal world, it should be MS's job to fix MS's bugs, not the devs job to work around it. The devs job should be to write stuff that is correct and secure by the Javascript/HTML/whatever standards, not code that works with the IE bug of the day.

    --
    A polar bear is a cartesian bear after a coordinate transform.
  9. This is how it works. by clone53421 · · Score: 4, Informative

    No.

    The sites were previously not susceptible to cross-site scripting. They escaped their input, whatever needed to be done.

    IE cleverly tried to prevent cross-site scripting and in the process they screwed up the properly-escaped response so that now, you can execute a xss attack that didn’t even exist until IE8 changed it.

    This is how.

    If I enter “<img src=x:x onerror=alert(document.cookie);><script” in a username field, the next page that says “Hi, $name” should not result in a script alert. And if the page also sends the username as a Javascript string, the (PROPERLY ESCAPED) response might look like this:

    <script type="text/javascript">
    var username = "<img src=x:x onerror=alert(document.cookie);><script";
    </script>
    Hi, &lt;img src=x:x onerror=alert(document.cookie);&gt;&lt;script

    Note that the site properly escaped the angle brackets when it was presented as HTML, and there were no illegal characters that needed escaping in Javascript.

    IE8 will detect your “<script” in the input and replace all instances of <script with “<sc#ipt” in the resulting page. (No, I’m not making this up. That is what the researchers claim.) Which, naturally, kills most of the Javascript functionality in the resulting page. But more importantly, it does this:

    <sc#ipt type="text/javascript">
    var username = "<img src=x:x onerror=alert(document.cookie);><sc#ipt";
    </script>
    Hi, &lt;img src=x:x onerror=alert(document.cookie);&gt;&lt;script

    ...which looks like this, when the browser renders it:

    var username = "[broken image bitmap] Hi, <img src=x:x onerror=alert(document.cookie);><script

    AND THE INJECTED SCRIPT EXECUTES.

    Now you just replace the alert() with some Ajax code to send the stolen cookies to your server, craft a URL containing the malicious code in a GET query, and go phishing.

    --
    Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
    1. Re:This is how it works. by clone53421 · · Score: 2, Informative

      Actually, no. The site sent code that was executed by the browser to a malicious result. Normally in such a situation you’d blame the site, and rightly so.

      The blame goes on IE in this one, though, for breaking correct code generated by the site and turning it into something incorrect (and malicious).

      --
      Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
  10. Re:Good to know by CorporateSuit · · Score: 2, Informative

    When you go to a website, and it says "Welcome, Thomas!" because your referrer website sent them to their homepage with something like "http://www.website.com/?name=Thomas" these guys set up the referrer to send you to a page that says something like "http://www.website.com/?name=[malicious code]" and the site says "Welcome !" and congratulations on your new site-specific keylogger.

    --
    I am the richest astronaut ever to win the superbowl.