[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 5 Nov 2017 19:03:07 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security <oss-security@...ts.openwall.com>
Subject: Re: Fw: Security risk of vim swap files
Also you're all still ignoring umask =(. Please, when you create a new
file, check the umask and subtract it to make sure you're abiding by the
user's wishes.
On Sun, Nov 5, 2017 at 11:19 AM, Scott Court <z5t1@...1.com> wrote:
> Just want to point out that even if we do set 0600 permissions on all
> .swp files, it still may allow for a form of the attack Hanno originally
> pointed out if vim is ever run as the httpd user. In reality, this is
> far less likely to occur but it's still worth pointing out.
>
> Storing the .swp files in a separate directory prevents this from
> potentially being a problem as well. However, universally setting the
> .swp files to 0600 is probably a better solution than that patch
> (https://github.com/vim/vim/releases/tag/v8.0.1263).
>
>
> On 11/05/2017 12:59 PM, Solar Designer wrote:
> > 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
>
>
>
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@...hat.com
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.
