GNU bug report logs - #27986
26.0.50; `rename-file' can rename files without confirmation

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: p.stephani2 <at> gmail.com, 27986 <at> debbugs.gnu.org
Subject: bug#27986: 26.0.50; 'rename-file' can rename files without confirmation
Date: Tue, 15 Aug 2017 12:27:52 -0700

Eli Zaretskii wrote:

> How would they know to create B before Emacs issues any system call
> that uses B?

Because the attackers know how Emacs work and are attempting to exploit its 
security hole.

> And how is this case different from the case that Emacs calls
> (rename-file A B) thinking B doesn't exist (e.g., because some prior
> code tested that)?

The case in question trashes a directory that the attacker lacks permission to. 
The case you're talking about does not: it merely causes rename-file to fail.

> we should be backward compatible as a fallback.

I don't see how this can work, if the fallback method relies on two system calls 
that can fall victim to a race. I tried pretty hard to come up with secure and 
backward-compatible approaches before proposing the change. I could not come up 
with any, and doubt whether anyone else could either.

Another possibility is to implement new functions (say: file-copy, file-rename, 
file-link, file-symlink, and directory-copy) that behave like the existing 
functions except without the security hole, modify callers to use these new 
functions, and then mark the existing functions as deprecated due to security 
concerns. I suspect that this would be more disruptive overall than the proposed 
change, though (albeit disruptive in a different way).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.