CLD-120 Details

Other IDs this deficiency may be known by:

Basic Information:

Version Specific Information:

Details:

Originally reported on Openwall's oss-security list at:
http://www.openwall.com/lists/oss-security/2017/10/31/1

I have explained how this attack will be mitigated against on Cucumber Linux in
my reply to that mailing list, which is included below:

Hello All. I'd just like to add my two sense to this conversation.

I have reproduced this on Centos 6 and Cucumber Linux 1.0. It appears
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. This is still a problem though, as configuration files in
/var/www are usually readable by the httpd user, so the Vim .swp will
also be readable by the httpd user and consequentially anyone connecting
to the webserver.

Storing the swap files in /tmp is a bad idea for all the reasons
previously discussed; /tmp gets wiped on reboot on most (but not all)
Linux distributions and storing the swap files in a location that is
readable by every user on the system has is own security problems. For
instance, what if root goes to edit /etc/shadow and the swap file is
placed in /tmp?

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 is 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.

I will be adding this to the default '/etc/vimrc' on Cucumber Linux in
the next few hours. I thought it may be helpful for other distro
maintainers to know as well.

    - Scott

======================= EDIT Thu Nov  2 22:52:10 EDT 2017 ======================

This has also been discussed on the Vim development mailing list at
https://groups.google.com/forum/#!msg/vim_dev/sRT9BtjLWMk/MZyVYhshBwAJ;context-place=forum/vim_dev

It was also found that the potential impact of this vulnerability is greater
than what was originally reported, as I explained on the Vim mailing list. The
explination has been included below:

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.

======================= EDIT Tue Nov  7 09:37:11 EST 2017 ======================

The change to the /etc/vimrc file has been refined since this report was
originally published with the help of Christian Brabandt (cb@256bit.org). The
final modification to /etc/vimrc which ultimately prevents this attack is as
follows:

" 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//