Loading ...
Sorry, an error occurred while loading the content.

46713Re: feedkeys() allowed in sandbox

Expand Messages
  • Matthew Winn
    May 3, 2007
    • 0 Attachment
      On Tue, 1 May 2007 19:42:02 +1000, "John Beckett"
      <winterwaffle@...> wrote:

      > Matthew Winn wrote:
      > > If there was a security problem in Vim do you really think it
      > > couldn't be exploited in 100 characters? That's a pretty shaky
      > > foundation on which to build your security.
      >
      > I am quite surprised at the lack of appreciation for the merits
      > of "defense in depth" here. I am not claiming that a length
      > limit would preclude damage, just that a modeline should be
      > sanity checked before execution, and a reasonable length would
      > be the first check.

      What constitutes a "reasonable length"? Vim has to load the entire
      document including its modeline into memory anyway, so there's no
      denial-of-service implications in allowing unlimited modelines.
      Your suggestion amounts to "I won't use a modeline longer than X,
      so nobody will use a modeline longer than X".

      My objection to your idea is that it won't improve security by even
      the tiniest bit. It's not defence in depth at all. It's a worthless
      measure that can't achieve anything useful and can only get in the
      way of legitimate uses. Any modeline long enough to be useful for a
      legitimate purpose must also be long enough to be useful for a hostile
      one.

      > It's sensational that Vim can process files with very long
      > lines, for the occasions we need that. But it would be absurd
      > for Vim to process a multi-megabyte modeline.

      Where do you draw the line between absurd and reasonable? When I write
      options I spell out the names in full so they're easier to understand
      for someone who doesn't know Vim well. That means that my modelines
      are quite long. But someone who wanted to save space could use the
      abbreviated form of an option. That means that if a modeline can be
      long enough to satisfy me it would give an attacker the ability to use
      several times as many options to craft their exploit as are needed for
      general use.

      > By all means abuse me for my cheeky suggestion to limit
      > modelines to 100 bytes, but while doing that you might agree
      > that some limit under 1MB should be enforced.

      Why?

      In some places there are good reasons for limiting sizes. For example,
      RFC2822 places a limit of 998 characters on the length of a line. The
      reason for this is so that RFC2822-conforming applications don't have
      to deal with data of arbitrary length and allocate unlimited buffers
      to handle it. They can allocate a buffer 1001 characters long and
      discard anything that won't fit in the buffer, thereby preventing the
      possibility of denial-of-service attacks from someone sending a line
      several hundred megabytes long.

      Vim doesn't have that issue because it must load the entire file into
      memory anyway. Vim already knows how to deal with long lines, so
      there's no extra penalty incurred by a multi-megabyte modeline.

      > > A web browser should be able to handle anything thrown at it
      > > in a way that doesn't compromise security. _Every_ application
      > > should be able to handle anything thrown at it in a way that
      > > doesn't compromise security.
      >
      > Even if a program is perfect now, a later change can introduce a
      > bug. Any program which can automatically execute untrusted code
      > should sanity-check the input as a separate step from
      > sandboxing. That is standard Security 101 stuff - not my idea.

      I've been working with computer security for over two decades. I know
      about standard security stuff. I also know that security that doesn't
      work is worse than no security at all, because it creates an illusion
      of protection where none exists.

      > > Perl and Vim have exactly the same requirements: the need to
      > > safely handle code taken from an untrustworthy source. It
      > > makes no difference whether it comes directly from a network
      > > or from a disk. (If, like me, you use Vim as your source
      > > viewer for web pages, the need for the same level of security
      > > is obvious.)
      >
      > It doesn't matter, but for the record, Perl's tainting system is
      > not related to the scenario you describe. Perl wants to make
      > sure that untrusted input is not later used as the basis for
      > some expression that could do harm, such as executing SQL code.

      That's what I meant, and that's exactly what Vim needs as well. Both
      applications read data from a source that can't be trusted, and both
      need to ensure that untrusted data can't be used in a situation where
      it could be dangerous. In Vim's case it needs to make sure that an
      expression used in an option set from a modeline can't be used later
      in a way that would cause harm, such as executing a command.

      Take a look at the original message. It sets foldmethod to something
      that triggers the execution of an external command after the modeline
      has been processed. Imagine you have a web page that contains the
      following (with the real command removed so it can't cause problems,
      just in case someone does view this in Vim; think of "rm -rf /"):

      <!--
      vim: fdm=expr fde=feedkeys("\\:!dangerous-command-here\\<cr>")
      -->

      Now imagine that someone uses Vim as their browser's "view source"
      application. That's _exactly_ the thing Perl's tainting mechanism is
      designed to prevent, and that's exactly what Vim must prevent too.

      --
      Matthew Winn
    • Show all 25 messages in this topic