[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171105175959.GA13011@openwall.com>
Date: Sun, 5 Nov 2017 18:59:59 +0100
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Bram@...lenaar.net
Subject: Re: Fw: Security risk of vim swap files
On Sun, Nov 05, 2017 at 06:17:04PM +0100, Christian Brabandt wrote:
> On Fr, 03 Nov 2017, Jakub Wilk wrote:
>
> > In general, what vim does (copying mode bits) in not enough to ensure that
> > the swapfile is readable only by the users who had access to the original
> > file. It would have to copy also group ownership and ACLs.
>
> I think patch https://github.com/vim/vim/releases/tag/v8.0.1263 fixes
> the group ownership problem.
That's some effort and code complexity for a fix that is not even trying
to address the problem Hanno pointed out. :-( What we really need is
simply forcing the permissions to 0600 no matter what. I do notice that,
non-surprisingly, Bram said:
| Why would a web server expose and serve such a file? That clearly is
| the problem, not that Vim happens to create swap files (and undo and
| backup files, depending on your configuration).
|
| You probably also create new files and copies of files that should not
| be served. If you care about security, the web server must always use
| whitelisting, only serve files that were intentionally made public.
This makes sense, yet Vim can and should also do its part to make things
safer when that does not conflict with its other goals nor introduce
complexity. Simply using mode 0600 is a win-win: addresses the problem
Hanno reported for the common special case of web server running as a
different user than the file owner, does not break any functionality,
and makes Vim's code simpler.
Yes, let's also force 0600 for "undo and backup files", please.
Even without a web server or whatever other external interaction
aspects, copying the original file's permissions and/or obeying umask is
just wrong in this case because those files are created implicitly,
often without the user's intent and knowledge, and because they might
stay around for longer than the original file does.
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
