Re: Nautilus should ignore the +x bit

[Mike Hearn <mike navi cx>]

On IRC we seemed to converge on a consensus that it'd be OK with some kind
of mechanism in place to ensure you can't accidentally run a downloaded
progam (but that isn't Yet Another Confirmation Dialog).

Dave wanted an analysis of why this won't lead to the sorts of exploits
we've seen on Windows in the past few years. 

I'll ignore the .desktop problem for now because I already proposed a
solution for that on xdg-list months ago (prevent Type=Application
launchers from using mimetype icons).

Here's a list of common desktop-level exploits from Windows and MacOS X,
how they worked and why we're not vulnerable to them.

* Programs masquerading as data to the user

  In this exploit a file is called, for instance, "foo.jpg.vbs". Explorer
  sometimes hides the file extension by simply chopping off the last part,
  which makes that file look like a JPG file. Alternatively, add lots of 
  whitespace between the fake extension and the real one.
  
* Programs masquerading as data to one part of the system but not to
  another

  One popular exploit was to give an EXE file an audio/wave mime type and
  then set it as the background sound in IE, which looked at the mime type
  and said "Ah ha! It's an audio file! I shall play it", passed it to the
  OS via generic routine which then said "Ah ha! It's a program! I shall
  run it!".

  These two exploits work because what the user/app perceives the file
  type to be is different to what it actually is.

  Linux/GNOME is still vulnerable to this sort of exploit (see the
  .desktop problems) but the risk is much reduced:

    - ELF binaries and scripts cannot choose their own icons. Therefore
      you can't make a program that has the same icon as a data file.
      By default icons are chosen by file extension, so the file would
      not have an image extension. 
 
      A possible improvement would be to give all executable files the
      same icon, so users can instantly recognise the "program" icon.
      Right now ELF binaries get the foot, and shell scripts get a
      document+diamond+cogs motif.

    - AFAIK there is no ShellExecute equivalent (this API runs a program
      OR opens a document so there's ample opportunity for mixing them up)

    - Nautilus checks the type as given by the file extension against
      the type as given by the MIME sniffers, and if they don't match,
      opens up a security warning. This warning has a few issues:

         - Too much text
         - Tells the user to rename the file, but doesn't say what
           extension is expected
         - Sometimes misfires (though I think most of the false positives
           have been fixed these days)

      ... but in general it goes a long way towards fixing this problem
      because a file is always acted on according to the sniffed MIME type.
      That's not foolproof but it's a lot harder to fake than a file
      extension.

      Of course you can still use the whitespace/double extension trick.
      There is no "hide extension" pref in Nautilus so it may be less
      effective, but there should probably still be some warning that
      you are about to run a program as most of the time, you'll run them
      from the menus.

* Automagic integration on MacOS X

  This lovely collection of bugs arises from the way appfolders was
  implemented on the Mac. The Finder is constantly searching for new
  app bundles to link URL handlers and file associations with. No 
  user interaction is required: once viewed in the Finder, or if placed
  in /Applications, the integration is completed.

  This was used to great effect by exploiting Safaris habit of
  automatically downloading and mounting "internet enabled" DMGs.
  They were placed in a location that the Finder automagically
  integrated with. Result? Instant code execution by using URL handlers.

  GNOME is not vulnerable to this kind of exploit because it does not
  reconfigure the system for code execution based on default download
  locations.

* Social engineering aka "I have attached a greetingz card!!!!"
  
  This is where you exploit the fuzzyness of the code/data distinction
  in users minds. Is a greetingz card a program or data? Is it harmful if
  you open it?

  For bonus marks, make it look like the contents of the email itself
  is attached to an executable file.

  Evolution - last time I tried - refuses to run programs attached to
  emails so they can't be opened directly from the email client. As 
  Nautilus running shell scripts takes place at a level *above* the APIs,
  it wouldn't affect Evolutions policy in this regard.

  That said, I'm not at all convinced that "security through obscurity"
  helps. If the user has been socially engineered into running a program,
  it doesn't really matter how many warnings are displayed or how many 
  hoops they have to jump through: they'll do it unless the computer can
  provide some compelling and credible information to suggest they
  shouldn't run it. That kind of monitoring/blacklisting is outside the
  scope of this email though.

* Privilege separation leaks
  
  These don't really affect the file manager. Normally they manifest
  themselves as cross-zone scripting attacks: where code is able to "leak"
  from an untrusted zone into a trusted zone. For instance, HTML viewed
  by Explorer in Windows has full privs, but HTML viewed by Internet
  Explorer does not. If you can make the leap between the two, you have
  local privilege escalation.

  Windows hackers found all kinds of variants on this problem, for
  instance by exploiting the help system. FWIW I already tried the same
  sort of tricks on GNOME, whilst there is a ghelp:// URI I couldn't see
  any way to make it misbehave from looking at the code and experimenting
  with it. 

  Making prompt/warn-by-default for shell scripts isn't impacted by this.
  If you have a malicious script on your desktop then by definition 
  the leakage has already occurred and there are no real security barriers
  left. I don't know of any way (short of social engineering again)
  you can write scripts to the users home directory.

* Modality exploits

  The theory here is simple: if you can trigger an endless loop containing
  a modal security dialog the only way out for the user is to click "OK".
  Windows XP SP2 fixed this problem for ActiveX by having a non-modal 
  yellow bar at the top of Internet Explorer.

  For a web browser this is a problem because web pages can trigger
  infinite loops. If there was a way for an unprivileged program or script
  to remotely trigger an "open" of a file on the users system via Nautilus,
  that could lead to an exploit.

  I don't see a way to do this even if Nautilus prompted for shell scripts.
  It'd not be done at the API level so there's no way (unless Nautilus
  exposes a remote control interface) for something to trigger it.

That's all I can think of right now. Firefox has an interesting take on
the "confirm dialog fatigue" problem: it has a very short, simple message
for URL handlers that invoke external programs and the acceptance button
is disabled for a few seconds to prevent people instantly hitting it.

I think a similar scheme would strike a good balance between security
and usability for Nautilus.

thanks -mike