On Thursday, November 2, 2017 at 9:09:49 AM UTC-4, Bram Moolenaar wrote: > Ken Takata wrote: > > > 2017/11/1 Wed 6:20:27 UTC+9 Bram Moolenaar wrote: > > > Hanno Böck wrote: > > > > > > > I wanted to point out an issue here with vim swap files that make them > > > > a security problem. > > > > > > > > By default vim creates a file with the name .filename.swp in the same > > > > directory while editing. They contain the full content of the edited > > > > file. This usually gets deleted upon exit, but not if vim crashes or > > > > gets killed (e.g. due to a reboot). > > > > > > > > On web servers this can be a severe security risk. One can e.g. scan > > > > for web hosts that have swap files of PHP configuration files and thus > > > > expose settings like database passwords. (e.g. wget > > > > http://example.com/.wp-config.php.swp ) > > > > > > Why would a web server expose and serve such a file? That clearly is > > > the problem, not that Vim happens to create swap files (and undo and > > > backup files, depending on your configuration). > > > > > > You probably also create new files and copies of files that should not > > > be served. If you care about security, the web server must always use > > > whitelisting, only serve files that were intentionally made public. > > > > > > > In a scan of the alexa top 1 million I found ~750 instances of such > > > > files. I tried to inform affected people as best as I could. I also > > > > discovered such scans in my own web server logs, so I assume black hats > > > > are already aware of this and it's actively exploitet. > > > > > > > > I was wondering how to best avoid this on my own servers and I first > > > > thought about saving the swap files to tmp ( with "set directory"). > > > > However on multiuser systems this creates another security problem. > > > > These files are world readable, thus instead of leaking information to > > > > the world it's now leaking information to other users on the same > > > > system. Thus even if one is aware of the issue it's nontrivial to get > > > > secure settings (I've now worked around this by having per-user tmp > > > > dirs with secure permissions.) > > > > > > > > I think vim should change the behavior of swap files: > > > > 1. they should be stored in /tmp by default > > > > > > No, on Linux this is wiped clean on reboot. You lose your work on a > > > system crash. > > > > > > > 2. they should have secure permissions (tmp file security is > > > > a tricky thing and needs careful consideration to avoid symlink attacks > > > > and the like, but there are dedicated functions for this like mkstemp). > > > > > > The permissions are the same as the original file, and that is exactly > > > how it should be. > > > > > > > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > > > > they shouldn't be called /tmp/.test.txt.swp, but more something > > > > like /tmp/.vim_swap.123782173) > > > > > > Infeasible, Vim can't find that file when trying to recover the original > > > file. > > > > An issue related to this (not the same) is filed as CVE-2017-1000382: > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000382 > > https://security-tracker.debian.org/tracker/CVE-2017-1000382 > > > > It seems that the problem is that Vim ignores umask: > > http://www.openwall.com/lists/oss-security/2017/10/31/15 > > > > (Similar one for Emacs: > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000383 ) > > This is working as intended, Vim does not use umask this way. > Umask is only used by simple commands such as cp, not by long running > processes that deal with many files. > > Problem is with the user expectations. > > -- > Permission is granted to read this message out aloud on Kings Cross Road, > London, under the condition that the orator is properly dressed. > > /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org ///
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. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
