Command injection was reported [1] in xdg-utils running with dash. Suggested patch: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=xdg-open.diff;att=1;bug=777722 Upstream bug report: https://bugs.freedesktop.org/show_bug.cgi?id=89129 This issue only affects systems with "dash" shell set as default system shell. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777722
Created xdg-utils tracking bugs for this issue: Affects: fedora-all [bug 1194209]
Analysis: xdg-open is used to open a file or URL in users preferred application. During the process of finding the correct app to run, it recursively searches Desktop file in function search_desktop_file(). This function uses local variable $file to store the path to the searched Desktop file and runs function get_key() on the $file. get_key() searched for [Desktop Entry] Exec=... in the $file and content of Exec= is later executed. The problem is that variable name $file is also used earlier in function open_generic() and stores path to the file being opened. Now assuming that system`s shell *does not* reset the content of $file when it is declared as local variable *again*, then the file being opened will be searched as Desktop file. If it contains expected [Desktop Entry] along with Exec=, it leads to arbitrary command execution. The assumption about reset of local variable contents hold for dash, but not bash: $ cat testme testme() { x=backfromthedead local x echo $x } testme $ dash testme backfromthedead $ bash testme Also, this does not work if the local variable is initialized: $ cat testme testme() { x=backfromthedead local x="" echo $x } testme $ dash testme $ bash testme xdg-open as shipped in Fedora and RHEL-7 does initialize $file variable, and uses bash as default /bin/sh.
Statement: This issue did not affect the versions of xdg-utils as shipped with Red Hat Enterprise Linux 6 and 7.