CLD-166 Details

Other IDs this deficiency may be known by:

Basic Information:

Version Specific Information:

Details:

=================================== Overview ===================================

Information disclosure in Vim (Vi IMproved) prior to 8.0.1263 allows for a local
user to view the contents of a file he does not have read permissions for if a
second user who does have read permissions on that file opens the file in Vim
and the first user is a member of the second user's primary group. This occurs
due to the fact that Vim prior to 8.0.1263 does not set the permission correctly
on .swp files.

================================ Initial Report ================================

From vim_dev (https://groups.google.com/d/msg/vim_dev/sRT9BtjLWMk/BRtSXNU4BwAJ):

Hi, I'd like to add my two cents to this. 

I have reproduced this on Centos 6 and Cucumber Linux 1.0. We have established
that the umask plays no role in the permissions on swap files; Vim creates its
swap files with the same permissions as the file being edited. 

However, there is another problem with the swap file permissions that has not
yet been discussed: when Vim creates swap files, the .swp file is created with
the owner and group set to the user who is editing the file (hereafter referred
to as the "editor") and the editor's primary group respectively. The permission
bits on the swap file are the same as the original file. 

This is a problem, as the editor's primary group may be different from the group
of the file being edited. Take /etc/shadow for example. That file is supposed to
have the permissions 640 with owner: root, group: shadow as a quick `ls -l`
shows: 

-rw-r----- 1 root shadow 1195 Sep 16 20:09 /etc/shadow 

However, shadow is not the root user's primary group; on this system it happens
to be 'users', which every other user on the system is also a member of. Now if
root goes to edit the file, a swap file is created in /etc/.shadow.swp with the
following permissions: 

-rw-r----- 1 root users 4096 Nov  2 13:52 /etc/.shadow.swp 

This swap file is now readable by every user on the system. Keep in mind the
/etc/shadow file contains hashes of every user's password, so now the password
for every single user on the system may have been compromised. 

--- Solution --- 

I have found this problem can be mitigated by changing the swap directory with
the 'set directory' directive as Hanno originally suggested. I have added the
following lines to my '/etc/vimrc': 

" Move the swap file location to protect against CVE-2017-1000382 
silent !install -d -m 700 ~/.vim/swap/ 2>&1 > /dev/null 
set directory=~/.vim/swap/ 

This safely sets the swap file directory to a directory that should not cause
any security problems. For added security, the directory is created so that only
the owner has access to it, regardless of how the system's umask or .swp file
permissions are set. 

Additionally, the swap file collision (if you edit both ~/foo/file and
~/bar/file at the same time) is not a major issue; Vim detects this and gives
the second swap file a different file extension. When you go to restore from the
swap file, you get a prompt asking which swap file you want to use (if there are
two swap files with the same basename), which doesn't strike me as being
terribly problematic. While this approach may have some minor issues/quirks,
for me it seems far preferable to being vulnerable to this vulnerability. 

I have already applied this fix on Cucumber Linux and thought you may want to
consider applying a similar fix upstream. 

============================ Additional Information ============================

This vulnerability was discussed extensively on the vim_dev mailing list at
https://groups.google.com/forum/#!topic/vim_dev/sRT9BtjLWMk.

It has also been extensively discussed on OpenWall on the
http://www.openwall.com/lists/oss-security/2017/10/31/1 thread.

================================= Our Analysis =================================

----- Affected Products -----
Vim versions prior to 8.0.1263 that have not had this patch 
(https://github.com/vim/vim/commit/5a73e0ca54c77e067c3b12ea6f35e3e8681e8cf8.patch)
applied and store .swp files in the default directory (which is the current
working directory) are vulnerable to this vulnerability.

In other words, if you are using a version of Vim prior to 8.0.1263 with all the
default configurations and no patches, you are vulnerable to this.

This was originally the case for both Cucumber Linux 1.0 and 1.1, meaning that
both Cucumber Linux 1.0 and 1.1 were originally vulnerable to this
vulnerability.

----- Scope and Impact of this Vulnerability -----
If a user opens a file that has the group ownership set to a group besides that
user's primary group, the contents of the file will be readable to everyone in
that user's primary group.

As was mentioned in the original report, this can result in unintended
information disclosure. If this scenario happens on the wrong file, it could
also result in privilege escalation.

----- Fix for this Vulnerability -----
This vulnerability can be fixed in one of three ways:

1) Upgrade to Vim version 8.0.1263 or later.

2) Apply the patch from
https://github.com/vim/vim/commit/5a73e0ca54c77e067c3b12ea6f35e3e8681e8cf8.patch.

3) Edit your vimrc to store the .swp files in a directory that only the user
running vim has access to (such as ~/.vim/swap). This can be done by adding
something similar to this to your /etc/vimrc file:

" Begin /etc/vimrc

" Move the swap file location to protect against CVE-2017-1000382
" More information at http://security.cucumberlinux.com/security/details.php?id=120
" A big thanks goes to Christian Brabandt (cb@256bit.org)
" for helping with this fix.
if ! isdirectory("~/.vim/swap/")
        call system('install -d -m 700 ~/.vim/swap')
endif
set directory=~/.vim/swap//

" End /etc/vimrc

================================= Our Solution =================================

We have opted to use the third solution on Cucumber Linux. We believe that this
is the most fool proof way to address this vulnerability, and it also protects
against several other potential vulnerabilities, such as CVE-2017-1000382
(http://security.cucumberlinux.com/security/details.php?id=120), which the other
two fixes do not.