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

Re: feedkeys() allowed in sandbox

Expand Messages
  • John Beckett
    ... By default modeline I mean I would like Vim to be changed so that its default behaviour is aggressively safe. If wanted, there could be a new option to
    Message 1 of 25 , Apr 30, 2007
    • 0 Attachment
      A.J.Mechelynck wrote:
      >> Is folding really needed in a default modeline?
      > Folding may be useful in a modeline.
      > (Don't know what you call a "default" modeline.)

      By "default modeline" I mean I would like Vim to be changed so
      that its default behaviour is aggressively safe. If wanted,
      there could be a new option to enable clever features, and a
      user could choose to allow modelines with folding or expression
      evaluation, etc.

      But the only long-term safe procedure is to have Vim *default*
      to work with only very restricted modelines (set tab and other
      options - no way to even get near executing code).

      I am wondering what the lack of comment on this topic indicates.
      Do you understand that another modeline vulnerability could
      allow the next file you open to overwrite all files under your
      home folder? Or it might overwrite all sectors on your disk, if
      you have sufficient privilege.

      How about if you go to another computer that you rarely use.
      Would you be happy using Vim on that computer?
      Network admins in secure environments should be prohibited
      from using Vim.

      If I am overlooking something, or am overly alarmist, please
      tell me. For anyone new to this, enter following in Google:
      vim vulnerability modeline

      I just noticed that the fourth hit features Ciaran McCreesh who
      discovered a vulnerability in January 2005.

      John
    • Bram Moolenaar
      ... This is not true. It just reduces the chance of a mistake being made by an unknown factor. It s still possible to allow an option to be set, thinking
      Message 2 of 25 , Apr 30, 2007
      • 0 Attachment
        John Beckett wrote:

        > A.J.Mechelynck wrote:
        > >> Is folding really needed in a default modeline?
        > > Folding may be useful in a modeline.
        > > (Don't know what you call a "default" modeline.)
        >
        > By "default modeline" I mean I would like Vim to be changed so
        > that its default behaviour is aggressively safe. If wanted,
        > there could be a new option to enable clever features, and a
        > user could choose to allow modelines with folding or expression
        > evaluation, etc.

        This is not true. It just reduces the chance of a mistake being made by
        an unknown factor. It's still possible to allow an option to be set,
        thinking that it is OK, but we later find out that it was not OK. Just
        like carefully removing mistakes and screening the options for mistakes
        does help to make it safer. Thus it doesn't make an essential
        difference. N times as safe still isn't 100% safe.

        In other words: If we have an option "run insecure" nobody would set it.
        Vim must be secure as-is.

        > But the only long-term safe procedure is to have Vim *default*
        > to work with only very restricted modelines (set tab and other
        > options - no way to even get near executing code).

        As they sometimes joke: The best way to protect your computer from
        malicious software is to switch it off. Likewise, the only really safe
        way is to disable modelines. Obviously you pay a price: restricted
        functionality. Options to partly disable modelines make it more
        complicated and don't help much for security.

        > I am wondering what the lack of comment on this topic indicates.
        > Do you understand that another modeline vulnerability could
        > allow the next file you open to overwrite all files under your
        > home folder? Or it might overwrite all sectors on your disk, if
        > you have sufficient privilege.

        Don't forget that this requires someone who intentionally wants this
        evil thing to happen. So far the only examples seen are jokes and proof
        of concept. I have never seen a file with a modeline that intentionally
        causes harm.

        > How about if you go to another computer that you rarely use.
        > Would you be happy using Vim on that computer?
        > Network admins in secure environments should be prohibited
        > from using Vim.

        Modelines are default off when you are root. The mail filetype plugin
        also switches it off.

        > If I am overlooking something, or am overly alarmist, please
        > tell me. For anyone new to this, enter following in Google:
        > vim vulnerability modeline

        Thanks for the advertisement! :-).

        --
        Give a man a computer program and you give him a headache,
        but teach him to program computers and you give him the power
        to create headaches for others for the rest of his life...
        R. B. Forest

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ download, build and distribute -- http://www.A-A-P.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
      • John Beckett
        ... I am not claiming that sanity-checking a modeline before execution would make it 100% safe. But there have been many examples in other software where minor
        Message 3 of 25 , May 1 2:44 AM
        • 0 Attachment
          Bram Moolenaar wrote:
          > N times as safe still isn't 100% safe.

          I am not claiming that sanity-checking a modeline before
          execution would make it 100% safe. But there have been many
          examples in other software where minor bugs have turned into
          security disasters because some simple point that could have
          been checked, wasn't.

          While code is working correctly, a simple check is redundant,
          and indeed is offensive because it lengthens and obscures the
          code. But a few simple checks may prevent disaster at some
          future time, when Vim is further developed.

          The Google test (searching for past instances of trouble with
          Vim's modeline) proves the case that future problems are likely.

          > Modelines are default off when you are root.
          > The mail filetype plugin also switches it off.

          Good grief - I didn't know that. So you *have* got sanity checks
          built in! I'll go and sit in the corner now, but thanks for
          confirming that multiple layers of defence are desirable.

          John
        • A.J.Mechelynck
          Bram Moolenaar wrote: [...] ... [...] Are you sure? In a terminal logged-in as root, using vim 7.0.235: vim -u NONE -N ... modeline modelines=5 Modelines
          Message 4 of 25 , May 1 3:10 AM
          • 0 Attachment
            Bram Moolenaar wrote:
            [...]
            > Modelines are default off when you are root. The mail filetype plugin
            > also switches it off.
            [...]

            Are you sure? In a terminal logged-in as root, using vim 7.0.235:

            vim -u NONE -N
            :set ml? mls?
            modeline
            modelines=5

            Modelines default off when 'compatible' is set, they default on (and 5) when
            'nocompatible' is set. Root login changes nothing to that AFAICT.


            Best regards,
            Tony.
            --
            "You mean there really is an answer?"
            "Yes! But you're not going to like it!"
            "Oh do please tell us!"
            "You're really not going to like it!"
            "but we MUST know - tell us"
            "Alright, the answer is...."
            "yes..."
            "... is ..."
            "yes... come on!"
            "is 42!"
            (Douglas Adams - The Hitchhiker's Guide to the Galaxy)
          • Bram Moolenaar
            ... Sorry, my mistake. There is a recommendation that when working as root you switch modeline off, but it s not done automatically. I do think that it s a
            Message 5 of 25 , May 1 4:32 AM
            • 0 Attachment
              Tony Mechelynck wrote:

              > Bram Moolenaar wrote:
              > [...]
              > > Modelines are default off when you are root. The mail filetype plugin
              > > also switches it off.
              > [...]
              >
              > Are you sure? In a terminal logged-in as root, using vim 7.0.235:
              >
              > vim -u NONE -N
              > :set ml? mls?
              > modeline
              > modelines=5
              >
              > Modelines default off when 'compatible' is set, they default on (and 5) when
              > 'nocompatible' is set. Root login changes nothing to that AFAICT.

              Sorry, my mistake. There is a recommendation that when working as root
              you switch 'modeline' off, but it's not done automatically.

              I do think that it's a good idea to make it automatic.

              --
              He who laughs last, thinks slowest.

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
              \\\ download, build and distribute -- http://www.A-A-P.org ///
              \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
            • Matthew Winn
              On Tue, 1 May 2007 19:42:02 +1000, John Beckett ... What constitutes a reasonable length ? Vim has to load the entire document including its modeline into
              Message 6 of 25 , May 3 2:07 AM
              • 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
              • John Beckett
                ... We ve probably slugged this out enough, but I m glad to have another opportunity to promote the safe modelines message. Bram has made the point that
                Message 7 of 25 , May 3 9:20 PM
                • 0 Attachment
                  Matthew Winn wrote:
                  > 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.

                  We've probably slugged this out enough, but I'm glad to have
                  another opportunity to promote the "safe modelines" message.

                  Bram has made the point that despite repeated modeline
                  vulnerabilities over several years, there are no known cases of
                  a malicious attack. We have only seen PoC and jokes.

                  I see the sense of that position - why put in a bunch of ugly
                  checking which is going to reduce features and upset some users?
                  Why do it if there are no known benefits?

                  My answer is essentially an appeal to a higher moral purpose.
                  There may never be in-the-wild exploits based on modelines, but
                  that would make it all the easier to direct a specific attack
                  against a targeted victim. The attacker would have a list of 10
                  or 20 "slight" security flaws in the victim's network. One of
                  those would be the fact that the victim uses Vim. An attacker
                  may use a Vim modeline as the coup de grace to fully own the
                  victim's network.

                  I find that situation offensive, and believe that modelines
                  should be REALLY fixed.

                  My claim is:
                  1. A modeline can execute untrusted code.
                  2. That is incredibly dangerous.
                  3. Any bugs in modeline handling should be fixed.
                  4. In addition, modelines should be sanity checked.

                  I think we agree on points 1-3.

                  I mentioned that the first step for point 4 should (IMHO) be
                  rejecting any modeline beyond some fairly small maximum size.

                  However, that was just the first part of my hoped-for sanity
                  check. After that, I would like the modeline to be examined to
                  determine whether there are any constructs that "look"
                  dangerous. I would reject any modeline with more than ten
                  backslashes, and would reject anything looking like an
                  expression or 'call'.

                  What I'd really like would be a separate sanity check that
                  verifies that the syntax in the modeline is boringly standard
                  'set' options for a declared whitelist of things that a modeline
                  is allowed to do. Note that this checking should NOT be done
                  only in the code that executes the modeline. The checking should
                  be an independent, prior step. That redundancy is likely to save
                  someone's foot in future years, when extra features are added.

                  > My objection to your idea [to limit modeline length] is that
                  > it won't improve security by even the tiniest bit.

                  You may be right. But if I were to accidentally execute malware,
                  I would prefer that the malware was short, rather than of an
                  essentially unlimited length. I agree that 100 bytes of malware
                  could do more damage than I could bear, but I would still
                  prefer that situation.

                  For example, 100 bytes of malware might be able to erase my
                  files, but perhaps it couldn't do something more sophisticated
                  like launching a hidden infiltration of my network.

                  I don't really know why I want to limit the modeline length.
                  That's the whole point of proper security measures. Just because
                  I can't think of a way that a long modeline might be bad, does
                  not mean that some attacker won't find a way, particularly in
                  five years after a bunch more stuff has been added to Vim.

                  > That means that my modelines are quite long.

                  I'm a reasonable guy<g>. Let's take your longest modeline and
                  double it. That length should be the maximum allowed for a
                  modeline unless some new "anything goes" option is enabled.

                  Re Perl tainting: I think we essentially agree on this, although
                  I don't think Vim needs to mark an executable expression read
                  from a modeline as tainted. Vim should immediately reject any
                  modeline that might execute code (unless some new "anything
                  goes" option is enabled).

                  John
                • Ciaran McCreesh
                  On Fri, 4 May 2007 14:20:22 +1000 ... Most previous exploits have been exploitable with far below the line length that is reasonably used by sensible people.
                  Message 8 of 25 , May 4 7:14 AM
                  • 0 Attachment
                    On Fri, 4 May 2007 14:20:22 +1000
                    "John Beckett" <winterwaffle@...> wrote:
                    > I mentioned that the first step for point 4 should (IMHO) be
                    > rejecting any modeline beyond some fairly small maximum size.

                    Most previous exploits have been exploitable with far below the line
                    length that is reasonably used by sensible people.

                    > What I'd really like would be a separate sanity check that
                    > verifies that the syntax in the modeline is boringly standard
                    > 'set' options for a declared whitelist of things that a modeline
                    > is allowed to do.

                    http://www.vim.org/scripts/script.php?script_id=1876

                    > For example, 100 bytes of malware might be able to erase my
                    > files, but perhaps it couldn't do something more sophisticated
                    > like launching a hidden infiltration of my network.

                    100 bytes is more than enough room to download and execute a file that
                    contains the real malicious code.

                    --
                    Ciaran McCreesh
                  • John Beckett
                    ... I actually agree that it is extremely unlikely that a length check would make modelines more secure, but I m being argumentative because it s irritating to
                    Message 9 of 25 , May 4 7:20 PM
                    • 0 Attachment
                      Ciaran McCreesh wrote:
                      > 100 bytes is more than enough room to download and execute
                      > a file that contains the real malicious code.

                      I actually agree that it is extremely unlikely that a length
                      check would make modelines more secure, but I'm being
                      argumentative because it's irritating to be authoritatively
                      assured that a length check would have no benefit in the future.

                      We just don't know whether some future vulnerability (perhaps
                      using a currently-unknown new feature) might be avoided with a
                      modeline length check.

                      John
                    Your message has been successfully submitted and would be delivered to recipients shortly.