Date: Thu, 9 Nov 2017 16:56:59 +0000 From: Simon McVittie <smcv@...ian.org> To: oss-security@...ts.openwall.com Subject: Re: [CVE-2017-14604] .desktop vulnerability again On Thu, 09 Nov 2017 at 07:12:21 -0500, Robert Watson wrote: > Why would a PDF, which is a specially formatted data file, be made executable? Because it isn't really a PDF, but actually a Desktop Entry with a confusing name (e.g. an arbitrarily named .desktop file with Name=Bank_Statement.pdf), which an attacker is trying to induce you to double-click on in the expectation that it will load in a PDF viewer, so that your file manager will instead carry out the expected action for launching a Desktop Entry (executing the program/arguments named in the Exec field, which could be malicious). This works because the Name field of a .desktop file is conventionally shown instead of its actual filename by graphical file managers, similar to how Windows hides the .lnk extension of shortcuts (.lnk files), and for essentially the same reason - if it was displayed, then these files couldn't be used to create a shortcut whose displayed name is entirely under the user's control. .desktop files are basically the open source answer to Windows .lnk shortcuts, with the same uses. Before anyone says "but we have symbolic links so we don't need those", .lnk shortcuts are not the same as symbolic links - they contain metadata like the icon and command-line arguments, not just the name of the target - so to satisfy the same use cases, an equivalent was needed, and .desktop files were it. Regardless of whether we personally think it's a good idea for file managers to have this special case for displaying Desktop Entry files, it's a use case that people want (or at least one that they wanted in the past), it was implemented a long time ago, and breaking it now would be a compatibility break. When that attack was discovered, authors of file managers and similar software mitigated it by (ab)using the u+x bit as a way to prevent the attack for files downloaded from web pages. The idea was that a web browser saving Bank_Statement.pdf.desktop from some malicious web page won't make it executable, so setting it to be executable can be used as an act of trust that can only be done by the user. However, extracting files from archives (zip/tar/etc. files) often does preserve the u+x bit, making that approach ineffective. I wonder how Windows mitigates the equivalent attack in which a malicious .lnk file is extracted from an archive? > I fear there may be one or more misunderstandings at play here of how > Unix/Linux works. I think you're misunderstanding how .desktop files are (intended to be) used. Their intended use is to be launched by an application that understands the Desktop Entry specification (e.g. Nautilus, the GNOME file manager) in response to some user action (e.g. when a Nautilus user double-clicks on a .desktop file). Again, the rule of thumb is "these are exactly like Windows .lnk". You can't "run" a .lnk file in Windows cmd.exe, and neither can you run a .desktop file in a Unix shell - that is not what they're for. The use of the u+x bit was just a hack to mitigate an earlier vulnerability without needing to invent new filesystem metadata - most of the time nobody actually passes these files to execve(). > (2) Is .desktop file executable when made executable? > > [root@...3:/] /usr/share/applications/minimal.desktop > /usr/share/applications/minimal.desktop: line 1: [Desktop: command not found Consider what your shell and kernel are doing here. minimal.desktop isn't an ELF executable, and it doesn't start with the #! that declares a script interpreter, so your kernel refuses to execute the file. For historical reasons, most (all?) shells fall back on treating minimal.desktop as a Bourne/POSIX shell script. This works remarkably poorly, for the simple reason that it is not a shell script. You would get similarly undefined behaviour if you chmod'd a HTML file +x and tried to execute that. But that doesn't matter, because the attacker is not trying to get the user to type the .desktop file's name into their shell - if an attacker can induce the user to type arbitrary commands into their shell then the defender has already lost. Instead, the attacker is trying to get the user to carry out an apparently-benign, apparently-safe action (double-clicking on something that appears to be a PDF file in their shell), and make it execute attacker-controlled code instead of doing what the user expects. > (5) The text following "Exec=" in a .desktop file is "exec'd". That > is, it replaces whatever program is processing the .desktop file. Then > the OUTPUT of the exec'd command is executed. That's not what I > expected. You are taking a "program" written in one "language" (a Desktop Entry) and causing it to be run by an interpreter for an entirely different language (Bourne/POSIX shell script), so of course the behaviour is undefined. You can't draw any conclusions from this about what happens when a Desktop Entry is activated as-intended, by a file manager or similar, any more than you could draw conclusions about the behaviour of C code or HTML by chmod'ing a file containing that +x and having your POSIX shell try to interpret it. Regards, smcv  strictly speaking it's a little more complicated than that, and several fields are considered, to provide for localization and graphical environments' differing requirements for displaying "branded" names like Nautilus vs. "unbranded" names like Files  as far as I know  "well actually" it is possible to put something like #!/usr/bin/env xdg-open in the first line of a .desktop file, in which case executing it will launch it, by passing it as a parameter to the xdg-open utility; but that's an afterthought, and the intended use is about graphical environments launching menu entries and other vaguely-Windows-like shortcuts
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ