On Sun, 29 Apr 2007 19:10:55 +1000, "John Beckett" <[EMAIL PROTECTED]> wrote:
> Matthew Winn wrote: > > I don't like the idea of preventing modelines over 100 bytes. > > I imagine (haven't looked) that a modeline has no hard limit to > its length. So multi-megabyte modelines are probably handled by > Vim. That's potentially offering attackers extraordinary power. It doesn't matter how many bytes are accepted. Security that depends on the assumption that an exploit can't be written in less than an arbitrarily chosen number of bytes is no security at all. Take a look at some of the coding golf competitions that take place online, where the object is to perform some complex task in the minimum number of characters. 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. > Would someone who wants a modeline longer than 100 bytes please > show us an example. How about a 200-byte limit? Oh, so nobody will need a long modeline? Just like they will never need more than [insert your favourite inaccurate prediction about the maximum amount of computing power anyone would ever need here]. > Modelines are enabled by default, and are very useful for things > like setting tabs. So most people, and all new installs, will > have modelines enabled. It's very poor security practice to > offer a rich auto-execution environment with a single line of > defence (the sandbox). > > This discussion reminds me of the days of the Code Red > vulnerability in IIS (Microsoft web server), and of the > years of repeated vulnerabilities in Internet Explorer. > > The IIS and IE developers just couldn't bring themselves to > build in limits to what their wonderful software could do. > "But a web site might need a 100KB URL with hundreds of '../' > paths!". 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. What you're suggesting isn't much different from security through obscurity. You're relying on the hope that nobody would ever be able to craft an exploit in under 100 bytes. Security doesn't work like that. Security needs to be something people can rely on to work every time, not something that depends on "Well, let's hope nobody thinks of this". If Vim's modeline security is written correctly and securely then the length of modeline it can handle safely would depend only on the amount of memory it wants to allocate to hold it. If it isn't able to do that then there's no security at all. > > Furthermore, what am I supposed to do if I want a long, > > complicated but legitimate modeline? > > I would like a default "high security" setting for handling > modelines. If people want modelines that do complex stuff, I > would recommend setting a new "anything goes" option. ABSOLUTELY NOT! Are you honestly suggesting that to enter a long modeline you have to disable security? I wouldn't touch an editor like that. > > I like Perl's approach to untrustworthy data. It's flagged as > > tainted at the point it is read, and anything derived from it > > is also flagged as tainted. > > Perl has to have that system because part of its intended usage > is to handle data entered into web pages. It's pretty complex > and has taken years to get right. > > Vim is a text editor - it should not automatically execute code > in any old file that I might accidentally open. 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.) -- Matthew Winn
