Slashdot Mirror

← Back to Stories (view on slashdot.org)

Big Day For Browser Vulnerabilities

Posted by timothy on from the uh-oh dept.

An anonymous reader writes "All browsers have been reported vulnerable to different vulnerabilities today. Starting with: Internet Explorer on XP SP1/SP2, which suffers a new system compromise (of course) vulnerability. Continuing with: Opera, Mozilla / Mozilla Firefox / Camino, Safari, Netscape, Konqueror, Avant Browser and Maxthon, which all suffers some new spoofing vulnerabilitities. Demonstrations of the spoofing vulnerabilities are available here and here."

5 of 429 comments (clear)

  1. Safari Exploit demonstration did not work by 99BottlesOfBeerInMyF · · Score: 5, Informative

    I just tried the exploit demonstration for Safari, but it did not work. The active tab switched back to the one providing the pop-up, not the target site. Did anyone else try it and have it work?

  2. About the second tab issue by ESqVIP · · Score: 5, Informative
    This was already filed as bug 124750, and has already been fixed. I'm using a 2004-10-19 build, and I can assure I already tested it.

    As I can't link bugzilla form Slashdot... go to http://bugzilla.mozilla.org/ and type in there the bug number. (None: it's not marked there as FIXED, but you should look at the "fixed-aviary1.0" keyword, which is what matters for Firefox 1.0)

  3. It's interesting to compare these by Anonymous Coward · · Score: 5, Informative

    This is an excellent example of two facts:

    • All software suffers security problems, and many of the security holes are actually just unintended side effects of useful features; and
    • Microsoft's software is much, much worse than the rest, because it's plagued by old design decisions that make it easy to turn a minor security problem into a remote root exploit.

    Here's what the vulnerabilities are:

    In all the non-IE browsers, there's a potential issue with how tabbed browsing works. Basically, the problem is that stuff on tabs other than the active tab can still (a) pop dialogs and (b) have the keyboard focus. It's pretty clear that (b) is just a problem that should be fixed, because although it's possible to concieve of a circumstance where a user would want to look at one tab while typing into a box on another, it's clearly way too surprising and not nearly useful enough to be allowed. But (a) is more interesting. It's a side effect of the fact that pages continue functioning in all ways even when they're not the active tab. This includes running Javascript/Java/Flash programs, loading, rendering, etc. And that's a good and useful thing. But when a background tab pops a dialog, it may appear to the user that the dialog was created by the active page. If the user trusts one page more than the other, that can lead to problems.

    The solution to this dialog-popping problem isn't obvious. Perhaps dialogs need to be labeled with the name of the site that created them. Perhaps some other solution. But it will be worked on, even though the risk is fairly small.

    The IE vulnerability is very different in that it's a system compromise flaw. It's similar in one way, though: it's caused by a subtle interaction of features. In this case, dragging and dropping of image or media files with embedded HTML code, which may be malicious. This malicious code isn't a problem, really, because IE is security-conscious and won't execute it -- except that Microsoft has that terrible "security zones" design feature. Once the malicious code is moved from the "Internet" zone to the "Local Computer" zone, the code will be executed. What makes it especially funny is that Microsoft fixed this problem in SP2 by changing the Local Computer zone so tht it will no longer execute Active Scripts. But yet another bug in the security zones can be exploited to bypass that "problem" so SP2 is vulnerable as well.

    Security flaws are everywhere, but what really kills Microsoft is their rash of bad design decisions in the past, turning little holes into remote root exploits. They're getting better, I believe, but it's going to be a long hard road for them to patch all of the problems that are created by their bad design decisions. It's too late, of course, to change the design. Too much depends on it.

  4. You have to be kidding. by argent · · Score: 5, Informative

    The Mozilla etc problem seems equally serious.

    Mozilla etc... "If the user explicitly opens a page in a background tab, it may not be possible to tell what webpage a dialog box is associated with". Note that the exploit can not open a page in a background tab, it can only take advantage of that if it happens.

    Exposure: If the user can first be tricked into opening a page in another tab, and the exploiter can guess whether the user has "open tabs in background" (or the equivalent option) selected or not, then they may be able to trick them into entering confidential information a little easier. There are other ways to get similar results without having to trick the user twice, using frames or with multi-stage popups.

    Internet explorer: The exploit can be used to launch web pages in the local security zone. The hole here is really the fact that there is such a thing as a "local security zone" at all. For seven years now, exploit after exploit has used this design flaw in the HTML control to run arbitary code as the local user. Spyware, viruses, worms, spam bots, over and over again, malicious software has gained its initial foothold through variants of this attack.

    Exposure: Visiting a web page can allow an attacker to take over your computer, without any further action on your part.

    And you say "The Mozilla etc problem seems equally serious."?

    Jesus.

  5. Re:NY Times Ad... by DAtkins · · Score: 5, Informative

    Actually, according to MozillaZine the fix has been fixed in the 1.0 code tree, but hasn't been merged into the existing builds yet. I would expect a fix before 1.0 goes gold.