Bugzilla – Bug 1060031
VUL-0: CVE-2017-14604: nautilus: Insufficient validation of trust of .desktop files with execute permission
Last modified: 2024-07-25 13:27:11 UTC
rh#1490872 GNOME Nautilus before 3.23.90 allows attackers to spoof a file type by using the .desktop file extension, as demonstrated by an attack in which a .desktop file's Name field ends in .pdf but this file's Exec field launches a malicious "sh -c" command. In other words, Nautilus provides no UI indication that a file actually has the potentially unsafe .desktop extension; instead, the UI only shows the .pdf extension. One (slightly) mitigating factor is that an attack requires the .desktop file to have execute permission. The solution is to ask the user to confirm that the file is supposed to be treated as a .desktop file, and then remember the user's answer in the metadata::trusted field. References: https://bugzilla.redhat.com/show_bug.cgi?id=1490872 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-14604 http://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-14604.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860268 https://github.com/freedomofpress/securedrop/issues/2238 https://bugzilla.gnome.org/show_bug.cgi?id=777991 https://micahflee.com/2017/04/breaking-the-security-model-of-subgraph-os/ https://github.com/GNOME/nautilus/commit/bc919205bf774f6af3fa7154506c46039af5a69b https://github.com/GNOME/nautilus/commit/1630f53481f445ada0a455e9979236d31a8d3bb0
QA REPRODUCER: see first comment of https://bugzilla.gnome.org/show_bug.cgi?id=777991
Hi Zheng Qiang, Would you add this to your CVE working queue please, thank you!
Please check the following case because I think its a regression issue. In a few words, although the update fixes the security issue, nautilus now does not behave as the user might expect, considering the fact that trusting a file is no longer taken in account. BEFORE ~~~~~~ INITIAL CREATION OF THE FILE -rw-r--r-- 1 root root 146 May 23 15:35 malware.desktop Running the malware.desktop file for the first time it asks if I want to LAUNCH "OR" TRUST. "LAUNCH ANYWAY" CASE -rw-r--r-- 1 root root 146 May 23 15:35 malware.desktop -rw-r--r-- 1 root root 0 May 23 15:36 MALWARE_WAS_HERE MARK AS TRUSTED CASE -rwxr-xr-x 1 root root 170 May 23 15:38 malware.desktop* --> The file permissions have been changed. Executable has been added for everyone. Is this expected ? Also in nautilus the file is indeed renamed to CV.PDF but on the terminal it is still malware.desktop. So there is a mismatch between the names in nautilus and terminal as the reproducer says. RUNNING AS TRUSTED Double clicking in nautilus on CV.pdf it creates the MALWARE_WAS_HERE file without prompting, because the file is now marked as trusted -rwxr-xr-x 1 root root 170 May 23 15:38 malware.desktop* -rw-r--r-- 1 root root 0 May 23 15:44 MALWARE_WAS_HERE --> BUG REPRODUCED AFTER ~~~~~ INITIAL CREATION OF THE FILE Running the malware.desktop file for the first time it asks if I want to LAUNCH "OR" TRUST. -rw-r--r-- 1 root root 146 May 23 15:54 malware.desktop After double-clicking the file on nautilus I get the following message : Untrusted application launcher The application launcher "malware.desktop" has not been marked as trusted. If you do not know the source of this file, launching it may be unsafe. The two options given now that are different than before the update are CANCEL and TRUST AND LAUNCH. TRUST AND LAUNCH -rwxr-xr-x 1 root root 146 May 23 15:54 malware.desktop* -rw-r--r-- 1 root root 0 May 23 15:57 MALWARE_WAS_HERE The MALWARE_WAS_HERE is created after double click and the permissions of the malware.desktop file are changed as before. Nautilus displays the name of the file as malware.desktop and not as CV.pdf --> FIXED However, double clicking again the file, I get the same exact message and again the same TRUST AND LAUNCH option. The file is not considered as trusted, so my choice from before is not remembered, which is a problem. No matter how many times I double click , I get prompted to trust the file. It seems like the update sets the trusted option but prevents nautilus from taking it into account. Although the "renaming" security issue is indeed fixed, we have this new "not trusted" prompt that always appears. I consider this a regression. Curiously, downgrading the packages and opening nautilus the malware.desktop appears as CV.pdf and is already trusted, if I double click it, it runs immediately.
Any statement on this=?
Run the bug reproducer again today. They issue is indeed fixed now and the behavior mentioned on comment #9 occurred because of the fact that I did not know that the whole host must be rebooted after the update and not only Nautilus. So after the update, reboot the host, and the issue on comment #9 does not appear, plus the issue is fixed.
SUSE-SU-2018:1694-1: An update that fixes one vulnerability is now available. Category: security (low) Bug References: 1060031 CVE References: CVE-2017-14604 Sources used: SUSE Linux Enterprise Software Development Kit 11-SP4 (src): nautilus-2.28.4-1.16.21.3.1 SUSE Linux Enterprise Server 11-SP4 (src): nautilus-2.28.4-1.16.21.3.1 SUSE Linux Enterprise Debuginfo 11-SP4 (src): nautilus-2.28.4-1.16.21.3.1
SUSE-SU-2018:2058-1: An update that fixes one vulnerability is now available. Category: security (low) Bug References: 1060031 CVE References: CVE-2017-14604 Sources used: SUSE Linux Enterprise Workstation Extension 12-SP3 (src): nautilus-3.20.3-23.3.14 SUSE Linux Enterprise Software Development Kit 12-SP3 (src): nautilus-3.20.3-23.3.14 SUSE Linux Enterprise Server 12-SP3 (src): nautilus-3.20.3-23.3.14 SUSE Linux Enterprise Desktop 12-SP3 (src): nautilus-3.20.3-23.3.14
openSUSE-SU-2018:2210-1: An update that fixes one vulnerability is now available. Category: security (low) Bug References: 1060031 CVE References: CVE-2017-14604 Sources used: openSUSE Leap 42.3 (src): nautilus-3.20.3-8.3.1
Hi Chingkai, When you have free hands, would you help to take over the backport of SLE-10-SP3 part? Please let me know if you need help. Thank you!
The fix for SUSE:SLE-10-SP3 (nautilus 2.12.2) requires at least two commits: 1. +2007-10-19 Alexander Larsson <alexl@redhat.com> + + * libnautilus-private/nautilus-file.c: + (nautilus_file_set_display_name): + Don't crash on NULL display name which is contained by a huge commit: - https://github.com/GNOME/nautilus/commit/469047a 2. https://github.com/GNOME/nautilus/commit/7632a3e I will evaluate if they can be backported to SLE10.