Almost a month ago, I reported this vulnerability to Microsoft, and they came back and confirmed it was a problem, but then came back and said “It’s no big deal, we’ll fix it in the next release”.
Microsoft has this track record with me of saying “It’s no big deal”, and then later making it a big deal, and never giving me credit for helping them. So I told them I was bringing this one public if they really thought it was no big deal, then no harm done… – they never asked me not to…
So I tried posting it to bugtraq – 24 hours after my first post didn’t show up, I reposted with a second account, thinking that the first post was blocked because I used an email address that wasn’t subscribed – almost 15 hours later, and the second post hasn’t shown up – I’m begining to wonder if someone is blocking the post (for whatever reason).
I emailed the list owner, and no response and after about 18 hours no response… so I guess it’s up to me to just start posting the problem around on the internet to get the word out.
I’ve tried posting this thread on two different security forums, and each forum throws an exception and doesn’t let me post… I think the world is out to squash Microsoft Internet Explorer Vulnerabilities….. at least I can post here!
This vulnerability may have limited destructive powers based on the current description that I’ve come up with, because of it requiring both the server owner and the client user to practice poor security habits – but isn’t that what the world is filled with – people that don’t practice safe security habits? It is also possible that someone else with more time on their hands can come up with other variants that would be a bit more destructive.
Web application Scenario:
1.Website accepts file uploads from users
2.Website follows recommended security for file uploads including two that are important to this discussion:
a.The document being uploaded is not stored in a directory that is accessible by Web Users (it is served up from a back end process when requested by users)
b.The users do not have execute permissions on the documents that are stored on the server (only permissions that are granted for download)
Attack scenario:
1.Attacker uploads HTML file to site
a.This HTML file contains:
i.Copy of logon form from the website, including relative pathing to website for cascading style sheets, images, etc.
ii.Attacker modifies form post location, so form posts go to a site the attacker controls
2.Website provides other users the ability based on their authorization to download and view the HTML file that the attacker uploads
IE Response:
1.Authenticated users click on HTML file and are presented with the download popup, file is streamed from a repository other than a web accessible location from the server
2.When prompted, users choose “Open” from the download popup, allowing default application to open the downloaded file
3.IE opens the HTML page in the current IE window (this has been verified against both IE 6 and IE 7), but IE does not change the security zone, or the URL of the IE address bar, so now the user sees the (modified) logon page of the site, but is given no indication (apart from opening and reviewing source code) that this page is not hosted on the site they are visiting
4.IE, thinking the HTML page has been served up from the remote site in the normal use case, also resolves all relative paths (cascading style sheets, images, etc) from the server
5.User – while thinking it odd that they are being prompted to logon again, looks and sees they are still in the same security zone, and URL of their trusted website
6.User logs on again (sending credentials to the attacker), and attacker does anything he wants with the post (serve up the actual file, redirect back to the original site, etc.)
Contrast IE’s response to FireFox’s response.
FireFox response:
1.Authenticated users click on HTML file and choose to download, when prompted, users choose “Open” for HTML file, allowing default application to open the downloaded file
2.Default browser (or alternate browser) opens the HTML page from local internet cache after download complete
3.Browser does not resolve relative paths, and URL is changed to show it’s running from a local location
4.Attack is obvious, User doesn’t proceed.
Perhaps I’ve missed something that makes this of no use to an attacker, and perhaps I’ve missed something that makes this an even bigger problem than I realized – but none-the-less, here it is.
r/Darth Jedi