Slashdot Mirror


Microsoft Flip-Flops On URI Protocol Handing Flaw

a-twitter writes "After months of insisting there is nothing to patch, Microsoft has done a complete 180 on the URI protocol handling vulnerability, announcing in a security advisory that a Windows update will be released to revise URI handling code within ShellExecute() to be more strict. The MSRC blog explains the background and offers more details on this issue."

10 of 126 comments (clear)

  1. Re:Good. by dedazo · · Score: 3, Informative

    No, it's not. Never was. They're fixing other applications (Firefox in this case), the way they hack their entire userspace to deal with application quirks and stupid use of undocumented structures and APIs that are not supported. But that's the price they ultimately have to pay for backwards compatibility - the reason they also still own 96% of the desktop.

    --
    Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
  2. Pay attention by Anonymous Coward · · Score: 5, Informative

    You're not paying attention. There were two flaws: One in Firefox, one in ShellExecute. Microsoft cannot and did not fix the flaw in Firefox (incorrect interpretation of command line). Microsoft did fix the bug in ShellExecute, which was by the failure to abort if URLMON returned an error code indicating that a given string was not a legal URI.

  3. Re:Firefox? by Anonymous Coward · · Score: 1, Informative

    Firefox installed the URL handler that was vulnerable. The fact that IE6 and IE7 treat URLs in different ways caused it not to be vulnerable under IE6.

    But it was still Firefox that installed the vulnerability. Without Firefox, NOTHING was vulnerable.

    So, yes, they're fixing Firefox's bug.

  4. Re:Firefox? by Kalriath · · Score: 4, Informative

    Well, actually, there are two issues being mentioned here. One, where Windows itself mishandles the URI. This is the one where a % symbol is included in the URI and ShellExecute stupidly tries to fix it (demons know how it manages to mangle it into an actual working executable path). The other, which Microsoft correctly attributes to third party vendors, is where when a protocol handler is called, no escaping of quotes is done - often causing apps like Firefox, or Trillian, or whatever, to actually accept half the URI as command line parameters.

    The mistake made by the GP (and potentially yourself, as you refer to the "blame cast" with the Firefox team which from memory only occurred with the issue in June with a malicious URIs terminating the quoted string and including Chrome parameters) is that they assume the second option is the one which is being fixed. It is not. This will potentially still be a problem if applications don't continue to validate their URIs appropriately, as Windows doesn't know exactly what your application does to escape quotes.

    One of these is a vulnerability. The other is third party applications violating a basic tenet of development (no input is trusted).

    --
    For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
  5. Re:Firefox? by ozmanjusri · · Score: 3, Informative
    Without Firefox, NOTHING was vulnerable.

    Rubbish.

    There's a whole shopping list of apps, including IE7 itself that were exposed to this vulnerability. Firefox was just the first to be accused.

    Microsoft's only changed it's tune because Adobe's on the case with the Acrobat vulnerability. It's one thing to force a FOSS competitor to unnecessarily patch, but they'll have no luck with trying to force Adobe to fix every PDF reader out there.

    --
    "I've got more toys than Teruhisa Kitahara."
  6. Re:Firefox? by Anonymous Coward · · Score: 2, Informative

    The other, which Microsoft correctly attributes to third party vendors, is where when a protocol handler is called, no escaping of quotes is done

    OK, let's break down the steps to executing a program here. Now, I know Microsoft has their way of doing it, but really, it's exactly the same fucking thing with the same fucking array of arguments as parameters to the main function.

    1) program A decides it wants to run program B with some arguments
    2) program A assembles the argument list, and selects a member of the exec*() family to call
    3) program A executes program B with the arguments that A prepared.

    It's not the receiving program's responsibility to try and reassemble its arguments to figure out what the calling program actually meant to pass in, well unless your program runs on Windows, I guess. "Escaping of quotes" is supposed to have already been taken care of by the time the first line of code in main(argc,argv) executes and wants to see what it got in argv[1]. But hey, I'm sure you have a really good reason why the OS is capable of dealing with quoted arguments correctly when I type "C:\Program Files\Somewhere" but can't be bothered to handle it correctly specifically when parsing a URL that explains exactly how it is not the URL parser that is broken?

  7. Did the submitter read the links they included? by Keeper · · Score: 4, Informative

    There are two "bugs" being talked about.

    1) an exploit in firefox URI protocol handler
    2) an exploit related to how explorer handles rejected URIs from IE7 on XP/Win2k3

    Apparently the submitter isn't able to differentiate #2 from #1.

    The advisory is for item #2. Item #2 is going to get fixed. The advisory does not cover item #1. Item #1 will need to be fixed in the protocol handler itself.

    1. Re:Did the submitter read the links they included? by Random832 · · Score: 2, Informative

      And while we're here, can anyone explain why the firefoxurl handler exists at all? Though these are url handler keys instead of programs, imagine that firefoxurl is the real binary, and firefox sets up http, ftp, and so on, as symlinks to it. It can't put the real handler at 'http', since that could be overwritten by IE if someone opens IE and checks "make this my default web browser".
      --
      We've secretly replaced Slashdot with new Folgers Crystals - let's see if it notices.
  8. Only a problem if you omit the http: by giafly · · Score: 2, Informative

    Create a shortcut on your desktop called 'www.slashdot.org' which points to 'www.bbc.co.uk'.
    Now visit www.slashdot.org in IE.
    Visiting www.slashdot.org is broken
    Visiting http://www.slashdot.org/ works fine

    IE seems to store the http: in favorites etc., so it's not much of a problem.
    Also it doesn't affect Firefox so almost nobody will notice.
    --
    Reduce, reuse, cycle
    1. Re:Only a problem if you omit the http: by mrRay720 · · Score: 2, Informative

      Actually this sounds like expected behaviour. www.slashdot.org isn't a valid address, people are just used to the user-friendly auto-appending of http://./

      www.slashdot.org is the name of a file in a location that IE searches for named shortcuts.

      What IE is doing in this case is preferring an exact match over an autoguess.

      The only arguement here is if IE should be searching the desktop for URL shortcuts, and considering how many people use their desktop in lieu of the favourites menu, I don't think that it's an unreasonable feature.

      If you want to go to http://www.slashdot.org/ - type that in. Leave room for the software to guess, and well, it will guess.