A Gentoo user discovered [1] a vulnerability in xdg-open which allows for arbitrary command injection. I was able to confirm it by running the following command, and it worked with both our packaged version of xdg-utils (1.1.0_rc1 plus some patches) and current git master: DE="generic" XDG_CURRENT_DESKTOP="" xdg-open 'http://127.0.0.1/$(xterm)' START /usr/bin/chromium-browser "http://127.0.0.1/$(xterm)" That command should open an xterm terminal instead of chromium. Further details available at our bug. [1] https://bugs.gentoo.org/show_bug.cgi?id=472888
This looks kind of similar to CVE-2008-0386 [1], though I don't believe shell metacharacters are the issue here. Different causes, similar impact.
Reminded of this today, will take a closer look over the weekend.
Posted to full-disclosure security mailing list yesterday: http://seclists.org/fulldisclosure/2014/Nov/36
I'm starting to wonder if this is specific to xdg-utils at all. Skipping xdg-open and running browsers directly: /usr/bin/google-chrome-stable "http://127.0.0.1/$(xterm)" /usr/bin/firefox "http://127.0.0.1/$(xterm)" etc... does exactly the same thing.
Ah, but using ' instead of " quotes, leads to something that avoids shell expansion, maybe we can simply go with that.
Related here is bug #30453 and commit: http://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=a616912e48b7ff1d908852739d16525df79471b9 Got some apparent extraneous quoting going on
Created attachment 109536 [details] [review] Fix argument quoting to avoid evaluation First try to address argument quoting issues. Seems to fix test-case ok, trying other use-cases to verify no regressions. Please test.
Any feedback here or alternative patches?
The proposed changes cause a regression. See http://bugs.debian.org/773085.
Created attachment 111778 [details] [review] Fix argument quoting to avoid execution second try, please test.
There is still a regression. File names with spaces won't work.
OK, rats, back to the drawing board, I'll have to work harder to find a way to make it work while avoiding any 'eval'
Created attachment 111873 [details] [review] nuke some extra quoting first step to proper fix
Created attachment 111874 [details] [review] Fix argument quoting to avoid execution try wrapping vars in "' ... '"
Haven't heard any complaints, so... Committed the latest approach, http://cgit.freedesktop.org/xdg/xdg-utils/commit/?id=ab071beaabb62ceda3028dd5efa85e8057c29006
I'm confused. How exactly can I verify the patch is fixing the arbitrary command injection vulnerability ? I have installed xdg-utils-1.1.0-0.35.rc3.fc20, which should carry the patch. However the test command DE="generic" XDG_CURRENT_DESKTOP="" xdg-open 'http://127.0.0.1/$(xterm)' START /usr/bin/chromium-browser "http://127.0.0.1/$(xterm)" opens en xterm both before I installed the test package and after. I would have thought that the new package was supposed open my default browser (being firefox). The package that was installed before the update was xdg-utils.noarch 0:1.1.0-0.31.rc2.fc20
I cannot reproduce it anymore. What shell are you using?
fWiw, I get: $ DE="generic" XDG_CURRENT_DESKTOP="" xdg-open 'http://127.0.0.1/$(xterm) START /usr/bin/google-chrome-stable http://127.0.0.1/$(xterm) With a browser window with url: http://127.0.0.1/$(xterm)
this test case, however, launches an xterm: DE="generic" XDG_CURRENT_DESKTOP="" xdg-open "http://127.0.0.1/$(xterm)" (note the difference here is the argument is double quotes, note single quote) I'll have to double-check if this is valid or not
(In reply to Rex Dieter from comment #19) > this test case, however, launches an xterm: > > DE="generic" XDG_CURRENT_DESKTOP="" xdg-open "http://127.0.0.1/$(xterm)" > > > (note the difference here is the argument is double quotes, note single > quote) > > I'll have to double-check if this is valid or not This test case is not valid because the user's shell starts xterm before even calling xdg-open. There is nothing xdg-open can do against this.
Thanks, I came to the same conclusion
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.