Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Security The Internet

New URI Browser Flaws Worse Than First Thought 149

narramissic writes "URI (Uniform Resource Identifier) bugs have become a hot topic over the past month, since researcher Thor Larholm showed how a browser could be tricked into sending malformed data to Firefox. Now, security researchers Billy Rios and Nathan McFeters say they've discovered a number of ways attackers could misuse the URI protocol handler technology to steal data from a victim's computer. 'It is possible through the URI to actually steal content form the user's machine and upload that content to a remote server of the attacker's choice,' said McFetters, a senior security advisor for Ernst & Young Global Ltd. 'This is all through functionality that the application provides.'"
This discussion has been archived. No new comments can be posted.

New URI Browser Flaws Worse Than First Thought

Comments Filter:
  • Oh my (Score:5, Informative)

    by zmotula ( 663798 ) on Thursday August 16, 2007 @05:11AM (#20246749) Homepage
    There is not a SINGLE technical detail about the bug in the article. The first paragraph pretty much says it all:

    Security researchers Billy Rios and Nathan McFeters say they've discovered a new way that the URI (Uniform Resource Identifier) protocol handler technology, used by Windows to launch programs through the browser, can be misused to steal data from a victim's computer.

    It is impossible to say whether this bug is really exploitable, whether it matters at all. So far they ("security researchers") can be only getting a free publicity. Is this news for nerds?
    • by jkrise ( 535370 ) on Thursday August 16, 2007 @05:56AM (#20246945) Journal
      There is not a SINGLE technical detail about the bug in the article. The first paragraph pretty much says it all

      If you actually read through till the last para, you ill note that the bug has something to do with Microsoft, Registry, Internet Explorer and registering programs.
      • by Sponge Bath ( 413667 ) on Thursday August 16, 2007 @09:38AM (#20248479)

        ... something to do with Microsoft, Registry, Internet Explorer

        That unholy trinity does not give me a warm and fuzzy feeling.

      • Re:Oh my (Score:5, Informative)

        by Intron ( 870560 ) on Thursday August 16, 2007 @10:07AM (#20248863)
        mozilla bug 389580

        "On Windows XP some urls for "web" protocols that contain %00 launch the wrong
        handler and appear to be able to launch local programs, with limited argument
        passing. It is not yet clear that this can be used to compromise a machine but
        we can always fear the worst.

        The same behavior is observed using "Run" from the Windows Start menu for the
        affected protocols (http, https, ftp, gopher, telnet, mailto, news, snews,
        nttp, possibly others?).

        The behavior seems to be that if there's a %00 in the URL for these schemes
        then the URL Protocol handler is not called, instead the FileType handler is
        called based on the extension of the full url. The url is then passed to that
        File handler. For "non-web" URL handlers the URL is passed to the expected
        handler.

        In Firefox browser protocols are handled internally so are not vulnerable, but
        the mailnews protocols are handed off to the OS and can be abused in this way."

        ====
        So you can construct a uri like: "mailto:/...%00...something.exe"
        Firefox sees mailto and hands it to Windows to give it to the mail program
        Windows sees %00 and mistakenly hands it to the FileType handler.
        The FileType handler sees ".exe" and runs the program.

        • by Torodung ( 31985 ) on Thursday August 16, 2007 @07:51PM (#20255669) Journal
          In other words, it's a backdoor in the URI handler for Windows, and Microsoft is "educating" everybody to scrub inputs before passing things off to the backdoored handler.

          Great. MS became the "gatekeeper" to all networking security bugs in their OS when they integrated IE into the operating system back in 1997. This is easily fixed by not allowing the URI handler in the OS to behave strangely when given specific inputs (such as %00 and " ).

          In short, Microsoft should remove the backdoor. 'Nuff said.

          --
          Toro
    • Re:Oh my (Score:3, Insightful)

      by hanshotfirst ( 851936 ) on Thursday August 16, 2007 @06:29AM (#20247073)

      There is not a SINGLE technical detail about the bug in the article.
      That's on purpose - they don't want their article to give hackers any real direction on how to exploit it. From TFA..."Rios and McFetters plan to release the results of their research after the vendor has had a chance to fix the problem".

      Yes, this is news for nerds - I know I'll be avoiding the URI protocol cautiously, if at all. I am duly informed. (Of course a real nerd would have known this already, so I have to turn in my card, I guess.)

      Nothing to gripe about here - move along.
      • Re:Oh my (Score:4, Informative)

        by martin-boundary ( 547041 ) on Thursday August 16, 2007 @07:17AM (#20247247)

        That's on purpose - they don't want their article to give hackers any real direction on how to exploit it.
        Sorry, but that's bullshit. Anyone can say they discovered an exploit, heck I discovered 14 just today while brushing my teeth :)

        The only thing that happens when people "claim" to have discovered an exploit without proof is that a lot of gullible people start panicking and unscrupulous reporters and bloggers who'll propagate the rumour for weeks. It's like yelling "fire" in a crowded room.

        If they really have an exploit, they should just share it or STFU. There's enough garbage information on the internet as is, there's no need for them to the dung pile.

        • Re:Oh my (Score:4, Insightful)

          by CaymanIslandCarpedie ( 868408 ) on Thursday August 16, 2007 @08:33AM (#20247721) Journal
          Patience grasshopper, details will be released soon enough. Their method of reporting seems to be becoming kind of an accepted best practice for "responsible reporting" of bugs. I fully support ones right to just release day 0 exploit sample code if they so choose, though I don't think it's the best idea. It seems notifying the makers of effected software at roughly same time as releasing very high level information about the exploit is becoming the best way to both avoid in the wild attacks as well as ensure the issue is addressed.

          In this case, additional researchers have even verified the issue after the initial report. If you still don't believe there is an issue (fair enough it's good to be skeptical), you can always do a tad of research into these researches history to help decide if you think they are trustworthy or not. If still that isn't enough, well then I guess you'll have to just find these issues yourself and you can publish anything you want about them. Until then the researchers who find an issue should have the right to handle it any way they choose. They don't answer to you.

          It's like yelling "fire" in a crowded room.

          Seems more like they are more warning that there is a pile of debris in the room which could be a fire hazard. You suggestion would be more like noticing that fire hazard and deciding to dump gas on it and then toss on a match.
          • Re:Oh my (Score:3, Insightful)

            by martin-boundary ( 547041 ) on Thursday August 16, 2007 @09:08AM (#20248089)
            Why should the onus be on others to check their work for them? Can't they check their own work before making an announcement?

            It's very nice of them if they want to give the vendors time to fix their software, but they should announce their results _after_ the patch is ready in that case. Announcing early and claiming "responsible reporting" while not explaining enough for users to protect themselves is a publicity stunt.

            Here's a few things that I think are wrong with the "responsible reporting" idea: it publically slanders software products without proof. It causes people to worry about undisclosed threats which may or may not affect them. It turns security research into a hype game where advisories must be taken on faith rather than fact.

            These problems go away if the researchers either announce with proof ASAP, or if they announce once a patch is ready.

            /2 cents.

            • Re:Oh my (Score:4, Interesting)

              by CaymanIslandCarpedie ( 868408 ) on Thursday August 16, 2007 @09:30AM (#20248343) Journal
              These problems go away if the researchers either announce with proof ASAP, or if they announce once a patch is ready.

              I don't think either of those suggestions are "bad", just that sadly they have historically had thier own issues which at least in many peoples opinions outway the gains of those methods.

              "announce with proof ASAP" - sadly history shows that when this is done unscrupulous people will then take that knowledge and use it to create malware which can cause MAJOR damage. This is why there has been talk of even making this illegal (which I COMPLETELY disagree with). It is true that "with proof" a tiny percentage of the computer using population will be able to avoid the issue. However, the VAST majority still won't even hear of the issue (as they don't follow such news) let alone know what to do about it. The result is hackers are given the gift of complete knowledge of an exploit which many millions of computers and users will have no defense against.

              "announce once a patch is ready" - again sadly it has been shown over and over again that many (if not most) products will not put the urgency into a security fix unless there is public pressure to do so. This has certainly improved greatly over the last decade, but I still don't think we are at a point where we can trust them on this without pressure.

              There is a fairly popular variation on your second idea which is to notify the software developer but don't announce until you have given them reasonable time to patch it. This will give them the chance to do the "right thing" on thier own without the public pressure but researchers can still release the information later if they feel the patch is too long in coming.

              I actually do prefer that option, but there is the arguement that a company will never feel quite the sense of urgency as they would when an overview of the issue hits the media. And it follows that then the patch will take longer and someone less than altruistic could also find the same issue in the mean time and release an exploit.

              I don't have a real strong preference between the options of notify the software developers first and wait a reasonable amount of time, or notify and release high level overview at the same time. I'd actually probably have a slight preference for the former, but it does seem the later is the more popular. Probably for the reasons you give, that they want to be sure they are given the credit (and attention) of the find ;-)
      • Re:Oh my (Score:3, Insightful)

        by MikeBabcock ( 65886 ) <mtb-slashdot@mikebabcock.ca> on Thursday August 16, 2007 @09:09AM (#20248105) Homepage Journal
        You don't need to provide a working example to explain the details. They could be saying something like:

        if you've installed vulnerable 3rd party url handlers, clicking malformed urls could lead to exploits
        in which case I don't care at all.

        I'm sure there are people who install 3rd party URL handlers as willy nilly as they install free screensavers and weather applets, but I don't, and neither should they, so again, I don't care.

        If on the other hand they're saying there's a URI parsing error in major browsers that is itself exploitable, that's different. Details are important. You could yell "fire" in a crowded theatre because you saw someone light a lighter, and you wouldn't be lying, but you left out a few good details.
    • Re:Oh my (Score:4, Interesting)

      by Opportunist ( 166417 ) on Thursday August 16, 2007 @06:32AM (#20247083)
      I have a working example here on my desk. The problem is it's so effing trivial that it's not even funny. Unlike buffer overflows or other exploits that at least require some kind of understanding, this requires a trained monkey who can use a keyboard.

      I'm usually all for the spread of information, but this has the potential to be a scriptkiddy's wet dream. And as I've stated before, I don't fear the hacker, I fear the scriptkiddy. Not because he's smart, but because he's many and he drowns you simply with quantity, not quality.
      • by brunes69 ( 86786 ) <slashdot@keir s t e a d.org> on Thursday August 16, 2007 @08:21AM (#20247589)
        Is your "working example" remotely installable?

        I am anxious to see how these guys plan to remotely install a URI handler into the registry without any user intervention, unless they are using some other remote exploit, in which case THAT is the actual bug.

        • by Anonymous Coward on Thursday August 16, 2007 @08:38AM (#20247775)
          For those living under a rock: Many applications, including Firefox, install URI handlers by default. Many applications, including Firefox, have no or insufficient safeguards against dangerous URIs which are passed to them that way. Many applications, which render arbitrary remote data, can activate URI handlers with arbitrary URIs, often with no or trivial user interaction. If you think that is fine, you shouldn't dispense security advice.
        • by Opportunist ( 166417 ) on Thursday August 16, 2007 @12:23PM (#20250673)
          Basically what it does is to make an assumption that a certain application exists on your system. An application that's exploitable through the use of malformed links, or malformed data hitting the application when you follow that link. Certainly, you are perfectly safe if you do not happen to have this application installed.
    • Re:Oh my (Score:4, Informative)

      by Fred_A ( 10934 ) <fred&fredshome,org> on Thursday August 16, 2007 @07:43AM (#20247339) Homepage

      There is not a SINGLE technical detail about the bug in the article.
      Except that this is (yet again) a Windows only problem, a fact which the summary could have pointed out thus saving me the effort of browsing the article (and having to kill that stupid ad iframe I couldn't even close).

      • by SolitaryMan ( 538416 ) on Thursday August 16, 2007 @08:49AM (#20247873) Homepage Journal

        This is the clear indication of problem being a Windows only:

        ...Thor Larholm showed how a browser could be tricked into sending malformed data to Firefox.

        Guess what is this mysterious "browser" thing.

      • by KE1LR ( 206175 ) <ken.hoover@nOSpAm.gmail.com> on Thursday August 16, 2007 @09:54AM (#20248671) Homepage
        Aha, the missing piece!


        1:Find ad popup code that can't be killed easily.
        2:Claim to Slashdot that you've discovered a trivial but really nasty browser exploit that nobody knows about, and provide a link to an article that says the same thing.
        3:Watch your ad views rack up.
        4:Profit!

      • by jdavidb ( 449077 ) * on Thursday August 16, 2007 @10:58AM (#20249529) Homepage Journal

        It'd also help if they'd clarify their terminology:

        a browser could be tricked into sending malformed data to Firefox.

        Firefox is a browser, last I checked. So if I'm not using another browser, no browsers will be sending any data to firefox, and I'll therefore be safe, right? This doesn't make any sense. What are they really trying to say?

      • Re:Oh my (Score:2, Informative)

        by jimbojw ( 1010949 ) <wilson.jim.r@gm[ ].com ['ail' in gap]> on Thursday August 16, 2007 @11:55AM (#20250257) Homepage
        For anyone looking for more information about this problem, here you go: Here are some useful excerpts from the Cert advisory:

        Internet Explorer 7 has changed how Microsoft Windows parses URIs. This has introduced a flaw that can cause Windows to incorrectly determine the appropriate handler for the protocol specified in a URI. This flaw appears to rely on having a "%" character in the URI.

        Publicly available exploit code uses Mozilla Firefox as an attack vector for this vulnerability. For more information, including workarounds, please see VU#783400 [cert.org]

        It seems that the injection mechanism is to use Firefox, but the exploit requires IE 7 to be installed on the victim's computer.

        Interesting excerpts from the secwatch advisory:

        The vulnerability is due to an input validation error handling system default URIs with registered URI handlers such as "mailto", "news", "nntp", "snews" and "telnet". This can be exploited to execute arbitrary commands when a user e.g. using Firefox visits a malicious website with a specially crafted "mailto" URI containing a "%" character and ends in a certain extension (e.g. ".bat", ".cmd")

        Confirmed on a fully patched Windows XP SP2 and Windows Server 2003 SP2 system using Firefox version 2.0.0.5 and Netscape Navigator version 9.0b2. Other versions and browsers may also be affected.
        In the comments to this article [betanews.com] a user by the name of kruador points out:

        This is utter rubbish. ShellExecuteEx wasn't updated with IE 7.0. It is a core OS feature - on Windows XP SP2 systems the most recent update was in the MS07-006 security update.

        All this function does is look up the URL protocol handler in the registry - for example, http: is at HKEY_CLASSES_ROOT\http - and look for the shell\open key. If a ddeexec key is found under that key, it uses DDE to send the URL to the registered program. If not, it runs the command under the command key, replacing the %1 in the command line with the URL to be processed.

        IE uses ShellExecuteEx whenever it encounters a URL protocol it does not handle internally - basically only http [slashdot.org]:, https: and ftp [slashdot.org]:. The Windows Explorer 'Run' dialog calls ShellExecuteEx when you enter a URL into the dialog (in fact, when you enter *anything* into the dialog). It's how Explorer locates a program when you double-click a document file.

        The question here is a difference of opinion over whether certain characters should be escaped in the command line or not. The behaviour of ShellExecute[Ex] has not changed. Microsoft are simply saying that Firefox has to cope with whatever it's presented with; Mozilla are saying it would be nice if certain characters were escaped.

        [UPDATE:] I have since discovered that Internet Explorer decodes URL-encoded (%-encoded) characters and passes the decoded version to ShellExecuteEx. This allows an attacker to inject " characters into the command line, terminating the URL argument, and allowing further command line options to be specified.
        And most importantly, he concludes with:

        The simplest workaround is to place a special command line option in first position (included in the command line in the registry, before "%1") that indicates that the rest of the command line came from a URL protocol handler and should be treated with caution.
        Sounds like some registry hacking could solve the problem.
    • by twitter ( 104583 ) on Thursday August 16, 2007 @10:00AM (#20248767) Homepage Journal

      Important details have been obscured on purpose to FUD Mozilla. I'm surprised they bothered to point out it's Windoze only in the first paragraph, but here's the glaring part of the FUD:

      Microsoft is working to educate users and developers about these security issues, but there's only so much that it can do, said Mark Griesi, a security program manager with Microsoft. "Security is an industry responsibility and this is certainly a case of that [principle]," he said. "It's not Microsoft's position to be the gatekeeper of all third-party applications."

      Yet, we know that this problem was created by IE7 [slashdot.org] and does not show up on Mac or gnu/linux. Par for the course, create a problem and then blame the victim. Where have we seen this kind of M$ attack before? All over, and court proved in the anti-trust case and also in the DRDOS case [slashdot.org].

      • by Macthorpe ( 960048 ) on Thursday August 16, 2007 @11:14AM (#20249739) Journal
        And yet this problem would be solved if Firefox didn't register a URI at all. Or it actually vetted data that was passed to that URI.

        Surprisingly it's not a problem if Firefox isn't installed.
        • by twitter ( 104583 ) on Thursday August 16, 2007 @12:05PM (#20250389) Homepage Journal

          M$ Defender, Macthorpe claims what M$ won't directly:

          Surprisingly it's not a problem if Firefox isn't installed.

          Not even this highly spun article goes that far.

          Thor Larholm showed how a browser could be tricked into sending malformed data to Firefox using this technology. This bug allowed an attacker to run unauthorized software on a victim's PC. Later, other researchers, including Rios and McFetters, showed how other browsers and applications could be misused to achieve similar goals.

          So IE, mentioned as "a browser", sends the crap to Firefox and will do the trick on it's own. Also, as we have seen before, this was not a problem before IE7 [slashdot.org].

      • twitter, I'm sure anyone who reads Slashdot would be keenly interested in any specific information you have to share about this, so please specify exactly how Microsoft is sabotaging Firefox here.
  • FTA: (Score:5, Insightful)

    by tygerstripes ( 832644 ) on Thursday August 16, 2007 @05:14AM (#20246765)

    By using these custom URI protocol names, software developers are trying to make lives easier for their customers.
    The article also states that this is a "hacker's dream and a programmer's nightmare".

    When a similar problem kicked off with the firefox:// protocol in IE all anyone could say was "Why the hell would anyone use this?" The answer seemed to be along the lines of "Nobody does - it was a stupid thing to include in the first place."

    Sounds like the same problem to me - and unnecessary and unsuitable solution to a non-existent problem causing far worse problems. As the proverb goes: if it ain't broke, don't start shoe-horning new and unsecured protocol-handling into the registry.

    • Re:FTA: (Score:3, Interesting)

      by a.d.trick ( 894813 ) on Thursday August 16, 2007 @10:00AM (#20248765) Homepage

      Nobody does - it was a stupid thing to include in the first place

      First off, it was called firefoxurl://. Second, it is used - by Windows. This is part of what is required when registering a browser on that OS. It's pretty important if you want to set Firefox as the default browser.

      • This is part of what is required when registering a browser on that OS. It's pretty important if you want to set Firefox as the default browser.

        IE, this is a "shell" URI that should not be visible to non-trusted content *at all*.

        There need to be separate registries for this.

        OS X has the same problem, though at least there it doesn't include any equivalent to ActiveX, and the KHTML-based API makes it easier to implement a fix.

        http://www.scarydevil.com/~peter/io/apple.html [scarydevil.com]

        • by a.d.trick ( 894813 ) on Thursday August 16, 2007 @03:22PM (#20253015) Homepage

          How else is firefox supposed to handle protocols liek mailto on a Windows system? The problem is that the URI's shouldn't have been trusted in the first place. The fact that they can execute arbitrary commands is appalling!

          The fact that browsers have a protocol attached to them is bad taste, but it's also a red herring. The real problem is that URIs can execute arbitrary commands. Firefox has as much to do with this as a potato has to do with an airliner.

          • How else is firefox supposed to handle protocols liek mailto on a Windows system?

            Using the URI bindings provided for *untrusted* objects. Just like it would use the MIME type bindings for untrusted objects.

            The problem is that the URI's shouldn't have been trusted in the first place.

            Certainly not the ones that browsers use.

            The problem is not limited to URIs. There are also plugins, file-type mappings, MIME-type mappings, and so on. Most of these, no matter what type of binding they are, have nothing to do with browsers. The mistake that Microsoft and Apple made was saying "these types of mappings are used by browsers, and these types aren't". Microsoft draws the line at plugins... browsers can execute any ActiveX plugin in the system, and quite a few more, unless they explicitly exclude them. Apple draws the line at file type mappings for downloaded files... browsers will by default open "safe" files, regardless of what the bindings for them are.

            You're just drawing another line along the same axis. The problem is, that's the wrong axis.

            Files, binding types (URi vs plugin vs MIME type), URI types, and so on, are not "safe" or "unsafe".

            It's the *handlers* that are safe (they either implement a sandbox or do not have mechanisms to do dangerous things) or unsafe (they have the ability to do dangerous things). The syntax (URI, path, COM API, what have you) is an implementation detail... if the application is designed securely and uses the API for that binding type securely... it doesn't matter which way the binding was implemented. If the application isn't designed securely or is sloppy about the binding, you're owned no matter how it gets invoked. There will always be applications you can safely open from the shell to view or operate on files that you must never expose to a browser.

            And MOST applications fall into that category.

            MOST applications are not sandboxed or secure. Not only is that hard to do for non-trivial apps, but MANY of them can not be, because it's their job to do dangerous things. It's up to the application to register as a shell application (to be used by applications for references that the use or application is in control of), or a browser application (to be used for untrusted objects). When the OS has no way to distinguish between the two, you lose.
    • by twitter ( 104583 ) on Thursday August 16, 2007 @10:06AM (#20248843) Homepage Journal

      if it ain't broke, don't start shoe-horning new and unsecured protocol-handling into the registry.

      Because we all know what a tight machine M$ gave us without help from firefox [slashdot.org]. Wake me up when this is more than a Windoze problem.

  • News? (Score:5, Interesting)

    by Opportunist ( 166417 ) on Thursday August 16, 2007 @05:17AM (#20246779)
    "It's a hacker's dream and programmer's nightmare," said Eric Schultze, chief security architect with Shavlik Technologies LLC. "I think over the next six to nine months, hackers are going to find lots of ways to exploit standard applications to do non-standard functions."

    That's not news. That's old. Actually it's nothing but a change in the ancient URL/URI trick where you trick the user into believing a link sends him somewhere else (akin to something like this: http://www.microsoft.com [gentoo.org]).

    The new part is that the URL/URI contains malformed links. Links, that don't just take you somewhere or offer you a torrent, but links that exploit a bug in your application. But it will hit the same group of people: Clickmonkeys who don't know what they're doing in the first place.
    • Re:News? (Score:5, Funny)

      by ozmanjusri ( 601766 ) <aussie_bob.hotmail@com> on Thursday August 16, 2007 @05:50AM (#20246927) Journal
      Actually it's nothing but a change in the ancient URL/URI trick where you trick the user into believing a link sends him somewhere else (akin to something like this: www.microsoft.com.

      Thanks dude!

      I installed that update to XP, and now my computer runs like a dream. Microsoft finally got it right!

    • by walt-sjc ( 145127 ) on Thursday August 16, 2007 @05:55AM (#20246943)
      When you hover over your example link, it shows where you are really going.

      When you use Evil JavaScript(tm) you can REALLY fuck with the user, who will have NO idea where the link goes, which is why tools like NoScript are so important. Don't surf naked - use NoScript [noscript.net]. Don't get me wrong, javascript can be useful, but so many sites use it gratuitously. They use it for things like roll-over highlighting, when CSS does it cleaner with less code. Most sites I visit seem to use javascript now. Less than half actually need it as NoScript has proven.
      • by Opportunist ( 166417 ) on Thursday August 16, 2007 @06:28AM (#20247069)
        JS is mostly used as a gadget to "enhance" a site (read: Make it so flashy that nobody notices the lack of content). Like so many other technologies that clutter our pages today.

        Take Flash. Yes, it can actually be put to good use. Pages have used it to really increase the usability and accessability of the content. But most just use it to create a flashy show to hide the lack of content or meaning.

        And yes, noscript and other security tools are important. But until this gets through to the clickmonkeys, it will be a very good way to get malware spread. It's just like mail. Mail is currently still the main delivery route for malware, but this starts to decline. More and more people get aware that their "invoice.pdf" is actually an "invoice.pdf.exe" and that it's probably not a good idea to open any kind of content sent to you. I can see it very well in the amount of malware and its source that runs past my desk. Until about 6 months, a good 80% of malware came actually out of mails. We're down to about 50 by now. In a year, mail might only play a minor role in malware distribution, simply because finally everyone realized that clicking on those attachments is a bad idea.

        So new spreading routines surface. Mail was just chosen because it's such a simple way. All you needed was a botnet (or renting one) and you could sensibly assume some good penetration. Malware creators do check the "success" of their spreading methods, and they realized a decline. So new roads have to be found. Spreading through webpages and links is harder, but also currently more rewarding. Few people use noscript. Few people even know that a link can be a threat (compared to the amount of people that know in the meantime that an attachment can be a threat, virtually nobody knows about the link threat). So it's a very rewarding way of spreading.

        What can be done? The usual. Reconfigure your honeypots, start creating site harvesting tools, inform the users.
  • by JosefAssad ( 1138611 ) on Thursday August 16, 2007 @05:18AM (#20246783) Homepage
    Some of the discussion around this issue revolves around URI validation. Given that third parties can assign their own handlers, I don't think it's the browser's job to validate URIs, but it can provide the facilities to do so.

    It would probably just be simpler to disable this functionality by default; I suspect not many people are really using their browser to launch other applications or do much beyond straightforward browsing (you konqueror people are something completely different!), or at least not to any meaningful extent. Where they are, some form of URI whitelist could do the job.

    I don't think browsers are going to stop being capable of launching applications overnight; I fully acknowledge that a lot of enterprise systems rely on this. But it can certainly be done more responsibly.

    • by Opportunist ( 166417 ) on Thursday August 16, 2007 @06:40AM (#20247105)
      I don't think browsers are going to stop being capable of launching applications overnight

      Then how about letting me, the user, decide? Instead of simply activating everything, ask me whether I want a certain application to launch? I think I remember seeing something like this in a browser, forgot which one it was... FF, I think.
    • by betterunixthanunix ( 980855 ) on Thursday August 16, 2007 @08:58AM (#20247977)
      Really? Because I use Konqueror's URI handlers for all of this: sftp, zip, tar, http, https, and ftp, and they are all useful. The problem with the Windows URI bug is that it allows an attacker to launch arbitrary programs, even programs without registered URI handlers, by passing arguments to certain registered programs (at least that is how I understand this vulnerability). It would be like using one of my KDE URI handlers to open a terminal; a malicious website could use that to start executing random commands on my system.

      The difference is that most Windows users are running as administrator, so an attacker could use this vulnerability to install something bad like a keystroke logger or some sort of worm, whereas they could only corrupt my home directory. This is just another example of why you shouldn't run as a superuser on a system connected to a public network...or any system at all.

      • by archen ( 447353 ) on Thursday August 16, 2007 @09:45AM (#20248571)
        Agreed, this is an extremely handy feature - especially when you consider the implications for integration with other applications. I created a database to track things on our network which worked pretty well. But then doing support remotely got to be a bit tedious since I would have to look up the info, cut and paste the computer name into $program, and so on. Now I can add handlers in firefox like rdesktop:// and vnc:// that allow it to fully integrate into a simple system.

        Better protections would be good, but I'd hate to see this functionality simply removed.
    • by TheNicestGuy ( 1035854 ) on Thursday August 16, 2007 @01:45PM (#20251765)
      What I find interesting is that Internet Explorer has, from the very beginning, had a little tab on its settings window to choose your preferred programs for the more common URI protocols like mail and news. So we've known for a long time that it is useful for browsers to be able to hand off non-http protocols to external programs, and that it's the sort of thing that a user might want to configure and customize themselves. How come these days it seems like all the management of that (in Windows at least) happens silently behind the scenes, and the user can't touch it without hacking the registry? Why hasn't the Programs tab of the Internet Options control panel evolved to a completely customizable list of protocol handlers, just the same as the one for file extensions? I haven't used Vista; does its infamous "allow or cancel" watchdog notify you of changes to your registered protocol handlers? It seems to me that the first step in dealing with these "browser flaws" is to bring this piece of the OS into the light and give the user control over it.
  • Whew... (Score:5, Funny)

    by Spy der Mann ( 805235 ) <spydermann...slashdot@@@gmail...com> on Thursday August 16, 2007 @06:15AM (#20247015) Homepage Journal
    Good thing I use Firefox and not that "URI browser". I feel safe.
  • Yeah, yeah (Score:2, Flamebait)

    by nagora ( 177841 ) on Thursday August 16, 2007 @06:22AM (#20247047)
    It'll be a cold day in hell before I take security advice from a bunch of crooks like Ernst & Young. Presumably there's some obscure way they can make money out of this announcement.
  • by billcopc ( 196330 ) <vrillco@yahoo.com> on Thursday August 16, 2007 @07:59AM (#20247413) Homepage
    This is just an expansion (or rehash) of the exploit using custom "protocol" prefixes (the http:/// [http] part). Now I must be on different intertubes than the rest of y'all, because I hardly ever (read: never) see anything but http, ftp and mailto in the links I use, and I build both public (as in gimmicky) web sites and business apps for a living. Anything else should be handled by a browser PLUGIN, not some creaky registry hack that can spawn any random process. The difference should be obvious: you can have a thousand executables on a PC, but probably less than a dozen browser plugins, making it a lot easier to spot suspicious bits.

    Why do we need so many bizarre launchers anyway ? Do people really click funky URIs in IE7 to launch the copy of Firefox that's already installed on their system ? How about a desktop icon, you stupid shits!
  • by bl8n8r ( 649187 ) on Thursday August 16, 2007 @08:00AM (#20247423)
    > Microsoft is working to educate users and developers about these security issues

    Yep. We know all about Microsoft's education*:

    In no event shall microsoft or its suppliers be liable for any special, incidental, punitive, indirect, or consequential damages whatsoever (including, but not limited to, damages for loss of profits or confidential or other information, for business interruption, for personal injury, for loss of privacy, for failure to meet any duty including of good faith or of reasonable care, for negligence, and for any other pecuniary or other loss whatsoever)

    [*] - http://www.microsoft.com/windowsxp/home/eula.mspx [microsoft.com]

  • Damn! (Score:2, Funny)

    by rdrd ( 1142449 ) on Thursday August 16, 2007 @08:07AM (#20247469)
    I just pressed on that "slashdot://it.slashdot.org" link !!!
  • by realmike ( 1143439 ) on Thursday August 16, 2007 @09:07AM (#20248083)
    Development of great software must include a process to review and cut down on feature on each release. Otherwise it becomes a feature bloat [wikipedia.org] and becomes ugly and dangerous.

    Mike | Optimalprint [optimalprint.com]
  • by Anonymous Coward on Thursday August 16, 2007 @10:06AM (#20248845)
    Goto about:config and

    set network.protocol-handler.expose-all to false,
    network.protocol-handler.expose.http to true,
    network.protocol-handler.expose.javascript to true,
    network.protocol-handler.expose.mailto to true and
    remove all other network.protocol-handler.expose.*entries (or set them to false).

    Set network.protocol-handler.external-default to false,
    network.protocol-handler.external.mailto to true and
    remove all other network.protocol-handler.external.* entries (of set them to false).

    To be sure set network.protocol-handler.warn-external.file to true and
    remove all network.protocol-handler.warn-external.* entries (or set them to true).

    For more info start at http://kb.mozillazine.org/Network.protocol-handler .expose-all [mozillazine.org]
    Beware, on windows things are different. See http://kb.mozillazine.org/Register_protocol [mozillazine.org]
  • by a.d.trick ( 894813 ) on Thursday August 16, 2007 @10:09AM (#20248885) Homepage
    Yes, but does it run on Linux :)
  • I've been talking about this kind of problem in Windows and the HTML control since the late '90s, and in OSX and LaunchServices since 2004. It's worse in Windows, because you have the same stupid lack of security design in ActiveX which is a much harder nut to crack...

    http://www.scarydevil.com/~peter/io/apple.html [scarydevil.com] and later posts in http://www.scarydevil.com/~peter/io/ [scarydevil.com] ...
    • by argent ( 18001 ) <peterNO@SPAMslashdot.2006.taronga.com> on Thursday August 16, 2007 @10:28AM (#20249149) Homepage Journal
      The articles on my site are primarily about Apple, mostly because Microsoft has similar vulnerabilities discovered at far too great a rate for me to keep up. There was a patch for another one (an ActiveX component used by other programs not being explicitly blocked by the HTML control) on Tuesday.
    • Griesi said that he does not see any of these URI issues as something that needs to be fixed in Windows or Internet Explorer. That's up to the individual software developers whose programs may be misused. "Security is an industry responsibility and this is certainly a case of that [principle]," he said. "It's not Microsoft's position to be the gatekeeper of all third-party applications."

      100% wrong. Microsoft doesn't provide a mechanism for applications to create both secure URI handlers for browsers as well as shell URIs for internal use. If they did, if they had a way to register components (URI handlers, file type handlers, Plugins, ActiveX controls, and so on) for use by shells (eg, Windows Explorer) only, or for use by browsers only, then we would have seen significantly fewer exploits on Windows over the past decade.

      This is harder for Microsoft to fix than for Apple to fix, because in Windows the HTML control is the gatekeeper... not the application. Apple hasn't integrated Webcore as far as IE, and since Webcore is based on KHTML it's using the inherently secure IO Slave model rather than leaving it up to the HTML display engine to try and guess what plugins should be allowed.

      But it DOES need to be fixed on both platforms.
  • by Animats ( 122034 ) on Thursday August 16, 2007 @11:18AM (#20249799) Homepage

    Write 100 times on the whiteboard:

    I will not launch applications from the browser.
    I will not launch applications from the browser.
    I will not launch applications from the browser.
    I will not launch applications from the browser.
    I will not launch applications from the browser.
    I will not launch applications from the browser.

  • by porneL ( 674499 ) on Thursday August 16, 2007 @08:30PM (#20255967) Homepage
    Opera protects against it by asking each time a new unapproved URI scheme is used. It's not perfect, because it requires user to think, and approved apps may be exploitable as well, but at least it narrows attack surface and gives some warning.

    It might be further improved to distinguish between clicked links and automatically triggered opens (like pop-up blocker does).

Trap full -- please empty.

Working...