Bug 1508788 (CVE-2017-1000383)
| Summary: | CVE-2017-1000383 emacs: Ignores umask when creating a swap file | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Andrej Nemec <anemec> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | jkeating, jonathan.underwood, jsynacek, lnykryn, msekleta, phracek, rgm+rh |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-01-03 16:19:57 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1508789, 1910521 | ||
| Bug Blocks: | 1508803 | ||
Created emacs tracking bugs for this issue: Affects: fedora-all [bug 1508789] It would be nice to have a reproducer in this bugzilla. Also, why is a vim discussion linked as a reference? $ 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~ 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. 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. (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. 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. 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/. |
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