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.
Update: 04/20 14:06 GMT by KD : Microsoft's Security Response Center has issued a statement on the vulnerability.
I have no idea what XSS does in IE8, like 99.9999% of those that use it.
And the [?] help never has any help at all.
/nt
cat
Strike 1: Using Winblows
Strike 2: Using Internet Exploder
Strike 3: Surfing suspicious sites
Yeeeerrr OUT!
http://blogs.technet.com/msrc/archive/2010/04/19/guidance-on-internet-explorer-xss-filter.aspx
.
stick to IE6. Long live Internet Explorer 6!
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!
This was already reported last November: http://tech.slashdot.org/story/09/11/24/2141247/Major-IE8-Flaw-Makes-Safe-Sites-Unsafe
I remember years ago MS arbitrarily filtered any query string in profiler that contained the word "password" in order to prevent potential leakage of plain text passwords using the profiler tool. All it did was provide people with an additional opportunity to avoid logging of their activities and more importantly pissed off a whole lot of developers and administrators. After massive outcry they subsequently removed the filter in future versions.
I hate when vendors think they can be too cute by half and overload the semantics of a context in the name of security. The road to hell really is paved with good intentions... There are a whole lot of well intentioned vendors in the security space spewing worthless products that will never provide acceptable security by hueristic dection of attacks but companies spend huge sums of money purchasing these systems anyway .. money better served scrutinizing their own crappy application or educating clueless developers. Every time you overload a system like this you introduce the possibility of additional attacks, breakage or more than likely just pissing a whole lot of people off who actually know what they are doing.
In general the web software stack community appears to still be as idiotic as ever.. What the hell were PPL thinking with JSON?
Take note people this is irony.
What about if someone simply made a Firefox addon that emulated this broken IE behaviour?
Would that not simply mean the sites were simply insecure as opposed to Internet Explorer somehow being responsible?
Not if IE8 wanders over to my site. Any version of IE gets a header redirect straight to the eu browser choice web site.
It will remain so indefinitely unless (Which I doubt) IE9 becomes ECMA javascript compliant and w3c standards compliant. Neither of which any existing single version of Internet explorer is.
I made the decision as a result of the IE attacks on Google and IE's failure to correctly render the site's w3c validated css and xml template correctly.
I haven't found any other major browser that can't render it correctly. Even webkit enabled phones have no trouble.
The sooner everyone starts doing the same, the safer the web will be and the easier web developer's jobs will be.
Web sites don't need Internet explorer. Internet Explorer needs websites.
. . . you can't fix it in the implementation. They have sent themselves down this path and are too far to turn back. Their only hope is to make it too proprietary for anyone outside Microsoft to understand. IE9 must use the IRS tax code interface, which will render it indecypherable and, therefore, unusable.
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.
My cousin works for 3D Realms. He says that Duke Nukem Forever will be released this summer and it will be even more bestest than Nintendo's next system.
$browser=isitie(); if $browser then ieisbrokepage() else [...]
Help stamp out iliturcy.
Now you know how far you can trust micros~1 code: Even the supposed security enhancements are abuse waiting to happen.
Malice? Criminal incompetence. And that for a company that employs thirty five thousand of supposedly the world's bestest pro-grammers.
Also, it has to be a nigger joke. ESPECIALLY if you're a subscriber. Just don't post links to gore or you'll have your IP banned.
So, what's up with that "trolltalk" username? How do they put the link to goatse embedded in their slashdot page thing? Have they hacked Slashdot?
This demonstrated the point that apparently is lost on the majority of people who are in various ways are responding to various "threats":
In the overwhelming majority of cases the best response to the possibility of attack is TO DO NOTHING.
In a large subset of those, fixing underlying problem is the best direction of efforts, security-related or otherwise.
It's simple -- when you (be it a person, organization or a piece of software) respond to something in a predictable manner your actions are controlled by it. If the original problem was the possibility that "you" could be coerced into doing something stupid and self-destructive, adding more predictable and complex reactions only provides more possibilities for doing the same.
Contrary to the popular belief, there indeed is no God.
If a site is capable of executing user submitted content it's hardly immune from attacks.
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.
So, what's up with that "trolltalk" username? How do they put the link to goatse embedded in their slashdot page thing? Have they hacked Slashdot?
http://encyclopediadramatica.com/Trolltalk
Read and learn! :)
Do what thou wilt shall be the whole of the Law
... the browser will automatically alter the response ...
This smacks of the thinking behind PHP's magic quotes.
Microsoft's so-called security experts should have known that this was a bad idea, especially if they'd worked with the UTF-7 XSS vulnerabilities. Any time you take a parsed language and haphazardly change the way that it parses, you're opening the door to security holes. That's probably why Dan Bernstein, years ago, said "Don't parse" in his page about qmail security.
http://outcampaign.org/
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, <img src=x:x onerror=alert(document.cookie);><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, <img src=x:x onerror=alert(document.cookie);><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.