| Package(s): | vim | CVE #(s): | CAN-2002-1377 | ||||||||||||||||||||||||
| Created: | January 16, 2003 | Updated: | February 10, 2004 | ||||||||||||||||||||||||
| Description: | VIM allows a user to set the modeline differently for each edited text file by placing special comments in the files. Georgi Guninski found that these comments can be carefully crafted in order to call external programs. This could allow an attacker to create a text file such that when it is opened arbitrary commands are executed. | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
vim - modeline vulnerability
Posted Jan 23, 2003 12:54 UTC (Thu) by rwmj (guest, #5474) [Link]
I'm glad to see useful features from Microsoft Word being integrated at last into archaic Unix tools like 'vi'.
vim's got company in emacs
Posted Feb 7, 2003 18:49 UTC (Fri) by Max.Hyre (guest, #1054) [Link]
emacs is the same, if not worse. (See the node
File Variables in the info docs.) You get
not only to set random buffer-local variables, but also to
evaluate arbitrary lisp code. Ouch!
At least the latter, by default, asks your permission, while the former prevents access to a number of variables deemed to be a particular risk.
Unfortunately, auto-setup for a given file is too handy to pass up, so I make it ask me everytime. Great, if I can avoid getting complacent about saying `yes'....
fixed in debian as well
Posted Jan 23, 2003 20:11 UTC (Thu) by erich (guest, #7127) [Link]
I remember seeing this fix in Debian...
vim (6.1.263-1) unstable; urgency=low
[...]
* debian/runtime/vimrc: added 'set nomodeline' to address potential
security issue wherein malicious persons author files with hazardous
modelines, users unwittingly open said files and vim evaluates the
dangerous modelines
[...]
-- Luca Filipozzi <lfilipoz@debian.org> Tue, 26 Nov 2002 09:46:26 -0800
So Debian unstable has modlines disabled by default. I don't enable them for emails i reply to.
vim - modeline vulnerability
Posted Mar 4, 2004 0:44 UTC (Thu) by dw (subscriber, #12017) [Link]
The initial Guninski advisory was so rushed that he failed to notice "libcallnr" as an alternative to "libcall". Upon return of "libcall", vim will attempt to read a char * from the integer returned by the called function. This, in the case of the advisory, should for all intents and purposes lead to a crash.Just worth note. :)
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds