Multiple symlink attacks

[Dan Rosenberg]

Binary package hint: nano

Nano is vulnerable to several attacks when being run as root to edit an untrusted user's files. For example, if this untrusted user replaces a file being edited with a symbolic link to a root-owned file while root is editing, on saving changes the root-owned file will be overwritten without any warning to root.

Other attacks are possible - for example, the creation of backup files (enabled by including "set backup" in a nanorc file) is vulnerable to several race conditions. If root uses nano to edit an untrusted user's file, that user can exploit this race condition to chown arbitrary files on disk to that user's ID (triggered when root saves the file and a backup is created). Several other attacks, including overwriting arbitrary files and changing permissions on arbitrary files are also possible.

I hesitated to file a bug report for these issues, because I am not sure that they qualify as legitimate security risks. These issues raise the broader question of whether or not tools like nano should be expected to be secure when run as root in a hostile environment. For many programs, untrusted users can replace files mid-operation, tricking the root user into performing unintended actions. However, I would think that text editors should provide some guarantees that the files they are operating on aren't changed during the course of editing.

On the other hand, the actual threat posed by these types of attacks is extremely limited. While it's a bit unsettling to think that an unprivileged user can essentially booby-trap their files and hope that they are edited by root using nano (with privilege escalation as a consequence), this seems somewhat unlikely to happen in real life. In fact, I'm not sure that the work required to fix these issues is even worth the effort, given the limited attack scenario. That being said, I decided to file this bug report to put that decision in the right hands and to get a second opinion on these issues. If the security team or nano developers think these issues are worth addressing, I'd be willing to help, but if not, then that's fine by me.

[Marc Deslauriers (mdeslaur)]

Thanks for reporting this issue Dan.

I have consulted my security team colleagues, and we're in agreement that this isn't serious enough to warrant a CVE or a security update.

I do suggest you open a bug with the upstream nano project though, so they can improve this in newer versions.

I'll leave this bug marked as "private" for now. Feel free to change it to "public" at your discretion.

[Jamie Strandboge (jdstrand)]

What is the status of this bug? Was it reported upstream?

[Jamie Strandboge (jdstrand)]

Public commit is here:
http://svn.savannah.gnu.org/viewvc?view=rev&root=nano&revision=4496

This was fixed in 2.2.4-1.