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
Created nano tracking bugs for this issue: Affects: fedora-39 [bug 2290866] Affects: fedora-40 [bug 2290867]
Upstream fix: https://git.savannah.gnu.org/cgit/nano.git/commit/?id=ce5513b009a4c639d3a0b057fa0de94cd82e14e4