[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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[0] 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[1],
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[2] 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
[0] 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
[1] as far as I know
[2] "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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
