Bug 2278574 (CVE-2024-5742)

Summary: CVE-2024-5742 nano: running `chmod` and `chown` on the filename allows malicious user to replace the emergency file with a malicious symlink to a root-owned file
Product: [Other] Security Response Reporter: TEJ RATHI <trathi>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: hkataria, kaycoth, kshier
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: nano 8.0 Doc Type: If docs needed, set a value
Doc Text:
A vulnerability was found in GNU Nano that allows a possible privilege escalation through an insecure temporary file. If Nano is killed while editing, a file it saves to an emergency file with the permissions of the running user provides a window of opportunity for attackers to escalate privileges through a malicious symlink.
 Story Points: ---
Clone Of: Environment:
Last Closed: 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: 2290866, 2290867    
Bug Blocks: 2278576    

Description TEJ RATHI 2024-05-02 06:13:29 UTC 
When nano is killed while it has a modified buffer, it saves this buffer to an emergency .save file and then chmods and chowns this file to the permissions and owner of the original file. This means that when nano is run as root and edits a user-owned file in a directory that is writable by that user, it gives a malicious user a window of opportunity to replace the .save file with a malicious symlink to a root-owned file. To be exploitable, it requires that the malicious user is able to kill the nano run by root. The original reporters of the problem said this:

We think it will mostly have an impact on multi-user systems. Where an admin might open a user's file -- for example to fix a broken config file. This could be in a user directory, requiring the admin to either become the user, or become root. If an admin does the latter, this attack can be performed - as long as the user can kill nano of course. One such example might be when root is logged in over `ssh` to a low-privilege user machine and the user can turn off the wifi on that machine.

https://bugzilla.redhat.com/show_bug.cgi?id=2277586
https://git.savannah.gnu.org/cgit/nano.git/commit/?id=5e7a3c2e7e118c7f12d5dfda9f9140f638976aa2
Comment 3 Pedro Sampaio 2024-06-07 12:25:49 UTC 
Created nano tracking bugs for this issue:

Affects: fedora-39 [bug 2290866]
Affects: fedora-40 [bug 2290867]
Comment 4 Pedro Sampaio 2024-06-07 12:35:51 UTC 
Upstream fix:

https://git.savannah.gnu.org/cgit/nano.git/commit/?id=ce5513b009a4c639d3a0b057fa0de94cd82e14e4
Comment 5 errata-xmlrpc 2024-09-24 01:20:49 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2024:6986 https://access.redhat.com/errata/RHSA-2024:6986
Comment 6 errata-xmlrpc 2024-11-12 11:03:58 UTC 
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 9

Via RHSA-2024:9430 https://access.redhat.com/errata/RHSA-2024:9430