Bug 1508788 (CVE-2017-1000383) - CVE-2017-1000383 emacs: Ignores umask when creating a swap file
Summary: CVE-2017-1000383 emacs: Ignores umask when creating a swap file
Keywords:
Status: CLOSED WONTFIX
Alias: CVE-2017-1000383
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1508789 1910521
Blocks: 1508803
TreeView+ depends on / blocked
 
Reported: 2017-11-02 08:55 UTC by Andrej Nemec
Modified: 2021-02-17 01:18 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
It was found that emacs applies the opened file read permissions to the swap file, overriding the process' umask. An attacker might search for vim swap files, that were not deleted properly, in order to retrieve sensible data.
Clone Of:
Environment:
Last Closed: 2018-01-03 16:19:57 UTC
Embargoed:


Attachments (Terms of Use)

Description Andrej Nemec 2017-11-02 08:55:40 UTC
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.

References:

http://seclists.org/oss-sec/2017/q4/145

Comment 1 Andrej Nemec 2017-11-02 08:56:09 UTC
Created emacs tracking bugs for this issue:

Affects: fedora-all [bug 1508789]

Comment 2 Jan Synacek 2017-11-07 13:10:57 UTC
It would be nice to have a reproducer in this bugzilla. Also, why is a vim discussion linked as a reference?

Comment 3 Jan Synacek 2017-11-07 13:14:53 UTC
$ rpm -q emacs
emacs-25.3-3.fc26.x86_64

$ umask 077

$ echo hello > foo

$ ls -l foo* 
-rw------- 1 jsynacek jsynacek 6 Nov  7 14:12 foo

$ emacs -Q foo &
[1] 2705

<edit foo and save it>

$ ls -l foo*
-rw------- 1 jsynacek jsynacek 11 Nov  7 14:12 foo
-rw------- 1 jsynacek jsynacek  6 Nov  7 14:12 foo~

Comment 4 Glenn Morris 2017-11-07 18:10:00 UTC
For an example of what I think the bug report is about, see upstream report at
https://debbugs.gnu.org/29182#6

umask 002
touch foo
ls -l foo    # -> -rw-rw-r--
umask 007
emacs-25.3 -Q foo
 make some changes and save
touch foo2
ls -l foo*
 foo  -rw-rw-r--.
 foo~ -rw-rw-r--.
 foo2 -rw-rw----.

So, Emacs (intentionally) preserves the permissions of the original file when creating a backup (Emacs doesn't have "swap" files). Creating a CVE for this seems a bit of a stretch to me.

Comment 5 Glenn Morris 2017-11-07 19:18:37 UTC
gedit, for example, seems to behave exactly the same way as Emacs, but doesn't create backups by default, whereas Emacs does. After a very brief and incomplete search, it seems like newer applications prefer to create backups in a central location (eg in HOME) rather than alongside the original file. This is available in Emacs by setting backup-directory-alist.

Comment 6 Jan Synacek 2017-11-08 05:47:16 UTC
(In reply to Glenn Morris from comment #4)
> For an example of what I think the bug report is about, see upstream report
> at
> https://debbugs.gnu.org/29182#6

Thanks! I have also found https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=231bfd6818890c0c22181ad253f09c8f2399461d, which looked like it fixed this, but it didn't.

> So, Emacs (intentionally) preserves the permissions of the original file
> when creating a backup (Emacs doesn't have "swap" files). Creating a CVE for
> this seems a bit of a stretch to me.

I agree. Also, I like the ~/.emacs.d/backup solution, I used something similar as well. I'm not sure how editing remote files would work, though, but I guess that can be solved easily too.

Comment 7 Glenn Morris 2017-11-08 18:29:11 UTC
To date, there's no change in upstream Emacs that "fixes" this. I don't think Emacs has even decided yet if this is something that needs fixing.

Comment 9 Cedric Buissart 2018-01-03 16:22:24 UTC
Statement:

Red Hat Product Security has rated this issue as having Low security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.


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