|
Message-ID: <CANO=Ty3-SjDC5=Dq3s19GxY4fwjJEah2-fbNAEp4bpGDUXOGfg@mail.gmail.com> Date: Tue, 31 Oct 2017 12:48:33 -0600 From: Kurt Seifried <kseifried@...hat.com> To: oss-security <oss-security@...ts.openwall.com> Subject: Re: Fw: Security risk of vim swap files On Tue, Oct 31, 2017 at 6:23 AM, Hanno Böck <hanno@...eck.de> wrote: > I just sent this to the vim dev list, but I guess it's interesting for > oss-security, too. > > Begin forwarded message: > > Date: Tue, 31 Oct 2017 11:30:50 +0100 > Subject: Security risk of vim swap files > > > Hi, > > 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). > The challenge is that the filename MUST be deterministic otherwise how do you find it post reboot/crash/etc. There is a flaw here, it appears on some distros that vim (and emacs) will ignore a user's umask and go with less restrictive file permissions (ideally you think vi would use the files existing perms, plus any umask limitations as expected), for example vim failing: [kseifrie@...alhost vi]$ umask 0007 [kseifrie@...alhost vi]$ touch foo [kseifrie@...alhost vi]$ ls -la total 8 drwxrwxr-x. 2 kseifrie kseifrie 4096 Oct 31 10:50 . drwx--x---. 27 kseifrie kseifrie 4096 Oct 31 10:42 .. -rw-rw----. 1 kseifrie kseifrie 0 Oct 31 10:50 foo [kseifrie@...alhost vi]$ chmod o+r foo [kseifrie@...alhost vi]$ ls -la total 8 drwxrwxr-x. 2 kseifrie kseifrie 4096 Oct 31 10:50 . drwx--x---. 27 kseifrie kseifrie 4096 Oct 31 10:42 .. -rw-rw-r--. 1 kseifrie kseifrie 0 Oct 31 10:50 foo [kseifrie@...alhost vi]$ vi foo in another terminal: [kseifrie@...alhost vi]$ ls -la total 12 drwxrwxr-x. 2 kseifrie kseifrie 4096 Oct 31 10:50 . drwx--x---. 27 kseifrie kseifrie 4096 Oct 31 10:42 .. -rw-rw-r--. 1 kseifrie kseifrie 0 Oct 31 10:50 foo -rw-r--r--. 1 kseifrie kseifrie 4096 Oct 31 10:50 .foo.swp So vim ignores the umask of the user =(. For example cat (and cpo and tar) work as expected: [kseifrie@...alhost vi]$ umask 0007 [kseifrie@...alhost vi]$ rm -rf * [kseifrie@...alhost vi]$ touch foo [kseifrie@...alhost vi]$ ls -la total 8 drwxrwxr-x. 2 kseifrie kseifrie 4096 Oct 31 10:49 . drwx--x---. 27 kseifrie kseifrie 4096 Oct 31 10:42 .. -rw-rw----. 1 kseifrie kseifrie 0 Oct 31 10:49 foo [kseifrie@...alhost vi]$ chmod o+r foo [kseifrie@...alhost vi]$ ls -la total 8 drwxrwxr-x. 2 kseifrie kseifrie 4096 Oct 31 10:49 . drwx--x---. 27 kseifrie kseifrie 4096 Oct 31 10:42 .. -rw-rw-r--. 1 kseifrie kseifrie 0 Oct 31 10:49 foo [kseifrie@...alhost vi]$ cat foo > bar [kseifrie@...alhost vi]$ ls -la total 8 drwxrwxr-x. 2 kseifrie kseifrie 4096 Oct 31 10:49 . drwx--x---. 27 kseifrie kseifrie 4096 Oct 31 10:42 .. -rw-rw----. 1 kseifrie kseifrie 0 Oct 31 10:49 bar -rw-rw-r--. 1 kseifrie kseifrie 0 Oct 31 10:49 foo So from a CVE perspective we have a situation where a user has explicitly set a umask (of say 0007) which is to say they've made a security assertion of "any file I create I want the rwx permissions for "other" removed" which vim and emacs (and possibly others) are violating when they create swap files/backups/whatever. To add insult to injury most other utilities that create a file (e.g. cp, cat, dd) seem to respect umask. Please use CVE-2017-1000382 for VIM version 8.0.1187 (and other versions most likely) ignores umask when creating a swap file (\"[ORIGINAL_FILENAME].swp\") resulting in files that may be world readable or otherwise accessible in ways not intended by the user running the vi binary. Please use CVE-2017-1000383 for GNU Emacs version 25.3.1 (and other versions most likely) ignores umask when creating a backup save file (\"[ORIGINAL_FILENAME]~\") resulting in files that may be world readable or otherwise accessible in ways not intended by the user running the emacs binary. -- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 Red Hat Product Security contact: secalert@...hat.com
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.