On Tue, 1 May 2007 19:42:02 +1000, "John Beckett"
<[EMAIL PROTECTED]> 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
