MS06-053 revisited ?
When we first read MS06-053 we ended up discussing and not fully understanding what Microsoft was trying to say (or hide, depending on your level of trust). It seemed like every time we thought we had it, the confusion crept in again.
Well, the confusion is still not fully gone, but some seem to have developed the thing to a point where there is no ignoring that you do not need an Indexing Service, nor an IIS server in the picture, in fact all you need is Microsoft's browser.
CVE-2006-0032 seems to indicate in its description that it indeed is a problem in the server allowing UTF-7 encoding.
Wait a second, "+ADw-" is supposed to represent "<" ? How many application developers know of this encoding?
UTF-7 is defined in RFC2152, titled "Mail-Safe Transformation Format of Unicode". How many of those developers do really care about something designed for email when writing their application for the web?
Ok, back to the core of the problem: this UTF-7 XSS vulnerability in the indexing service, was that it? Or was it just the tip of the iceberg, and is there something wrong in MSIE (as well)?
Not giving encoding back and including some seemingly innocent strings ([A-Za-z0-9+\-] is enough) -based on user input- is enough to create a XSS vulnerability for visitors using MSIE.
The "ouch" part are e.g. custom error pages that might not include any character set information but might include (part of) the requested URL: CVE-2006-5152.
Conclusion
Swa Frantzen -- Section 66
0 comment(s)
Well, the confusion is still not fully gone, but some seem to have developed the thing to a point where there is no ignoring that you do not need an Indexing Service, nor an IIS server in the picture, in fact all you need is Microsoft's browser.
Back to the start
MS06-053 is about a vulnerability in the Indexing Service it seems. The title is "Vulnerability in Indexing Service Could Allow Cross-Site Scripting (920685)". It references to CVE-2006-0032. And has hidden deep inside the workarounds: "Disable page encoding auto-detection in Internet Explorer". So the confusion is really if this is a server problem or a client problem and it somehow seems we're not the only confused ones out there. Now with XSS it's the client that's abused by trusting a vulnerable server. Yet it seems that making the client do things differently the server is saved?CVE-2006-0032 seems to indicate in its description that it indeed is a problem in the server allowing UTF-7 encoding.
Now what does that encoding look like?
+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-
Wait a second, "+ADw-" is supposed to represent "<" ? How many application developers know of this encoding?
UTF-7 is defined in RFC2152, titled "Mail-Safe Transformation Format of Unicode". How many of those developers do really care about something designed for email when writing their application for the web?
Ok, back to the core of the problem: this UTF-7 XSS vulnerability in the indexing service, was that it? Or was it just the tip of the iceberg, and is there something wrong in MSIE (as well)?
MSIE
Well it seems that if MSIE is not given a character set, it will autoselect one, and might just choose UTF-7. I'm sure somebody must have found it a cool feature, just like having a flight simulator in excel is cool.Not giving encoding back and including some seemingly innocent strings ([A-Za-z0-9+\-] is enough) -based on user input- is enough to create a XSS vulnerability for visitors using MSIE.
The "ouch" part are e.g. custom error pages that might not include any character set information but might include (part of) the requested URL: CVE-2006-5152.
Conclusion
- Well we could put on the recorded message of not using MSIE. It does sound broken, doesn't it? But those that would listen will have done so already by now.
- We could urge people to change the settings of MSIE:
- Launch Internet Explorer
- Click on View;
- Click on Encoding;
- Deselect Auto-select if it is selected.
- We can ask people to take care of their visitors and make the applications stronger in authenticating users before taking actions and in not storing authentication, sensitive information etc. in cookies and the like.
- If you develop web applications, make sure you always set the encoding, don't ever let MSIE guess as perfectly innocent looking strings might cause XSS problems.
- We could urge people to look at their errorlog and find 404 results and see if there was recon on using UTF-7 in it, but the recon can be very subtle. So at least check if your custom 404 web pages return the requested URL and stop doing that.
Swa Frantzen -- Section 66
×
Diary Archives
Comments