Re: feedkeys() allowed in sandbox
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
Re: wish: show search progress on slow searches
On 4/29/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: On 4/29/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > Yakov Lerner wrote: > > > Wish: when search is slow, show the progress line number > > every second on the bottom line (like, 12345 of 9). > > What is slow? To my taste, when something takes longer than 1-2 sec, I'd prefer some visual feedback on the progress. > Checking if the second passed will make the search even slower. > Checking time is quite slow on some systems (the check for CTRL-C > suffers from this). Checking for time every several hundred (N) lines will probably not slow the search perceptibly. N can be configurable, a parameter. Some value between 10 and 1000 will probaby be reasonable. Yakov I think it's possibe to check for time, which searching, not too often and not too seldom, even without user-defined parameter. Adaptive algorithm with two counters will find the right rate or time-checking: - as we start search, we check time every 50 lines (N=50 is initial value of N). We maintain counter M. M is how many times we called time() between the seconds changed. M is checked and reset every second. M is checked as folllows: - If M is too high (M>10), then we adjust N by increasing it. If M is too low(M<10), then we adjust N by decreasing it. Ideally, we want to check time() ~10 times per second. (overhead of 10 calls to time() per second cannot he high, right ?) - if search progresses for several seconds, then N quickly converges to the "ideal" value (~10 checks/sec). - we start every search with same value of N (say, 50). If search is slow, then N will quickly converge to the "ideal" value for this regex, the value in which where time() is checked ~10 times per second. Yakov
Re: feedkeys() allowed in sandbox
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
Re: A secure, configurable alternative to modelines
Ciaran McCreesh wrote: I've written a script that reimplements a restricted form of modelines as .vim code rather than internals: http://www.vim.org/scripts/script.php?script_id=1876 Very interesting script - thanks. A quick overview for anyone interested: - Include 'set nomodeline' in your vimrc. - Use Ciaran's plugin which will set modeline options. The plugin scans the first 5 and the last 5 lines of each buffer (in BufRead). It parses any modeline, and executes code to set options which you have allowed. But it is only capable of doing certain very restricted things, and so is very safe. For example, it can set textwidth or tabstop etc. Any other setting is ignored (or shows a warning in verbose mode). Your script is very helpful and I will try it. However, as you would be painfully aware, it doesn't cover awkward cases like using Vim on another computer, or making a mistake and executing a Vim without your normal vimrc. John
Re: arabic
Babiker Osman wrote: Hi السلام I wonder who is the most arabic -vim -tex expert to consult him babiker osman It depends what you want to do. - If it's so high-fired secret that you won't give us any hint of what you might be doing, just dig into the help. Start at ":help arabic.txt" if you want to edit Arabic text, for instance. - The Arabic module was written by Nadim Shaikli. He certainly has a good knowledge of how to use Vim for Arabic. I have no idea what his knowledge of TeX might be. - In general, you may ask your questions on one of the Vim mailing lists, and see if anyone replies: [EMAIL PROTECTED] for general support questions vim-dev@vim.org with questions about compiling Vim or about writing new interfaces [EMAIL PROTECTED] for questions about encodings and (human) languages It helps if the Subject of your mail is explicit and if its body is clear. A useful reference about asking questions about anything on any forums, mailing lists or newsgroups is "How To Ask Questions The Smart Way" http://www.catb.org/~esr/faqs/smart-questions.html Best regards, Tony. -- I disapprove of the F-word, not because it's dirty, but because we use it as a substitute for thoughtful insults, and it frequently leads to violence. What we ought to do, when we anger each other, say, in traffic, is exchange phone numbers, so that later on, when we've had time to think of witty and learned insults or look them up in the library, we could call each other up: You: Hello? Bob? Bob: Yes? You: This is Ed. Remember? The person whose parking space you took last Thursday? Outside of Sears? Bob: Oh yes! Sure! How are you, Ed? You: Fine, thanks. Listen, Bob, the reason I'm calling is: "Madam, you may be drunk, but I am ugly, and ..." No, wait. I mean: "you may be ugly, but I am Winston Churchill and ..." No, wait. (Sound of reference book thudding onto the floor.) S-word. Excuse me. Look, Bob, I'm going to have to get back to you. Bob: Fine. -- Dave Barry, "$#$%#^%!^%&@[EMAIL PROTECTED]"
