Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Feb 2015 07:29:15 -0800
From: Chris Evans <scarybeasts@...il.com>
To: Moritz Muehlenhoff <jmm@...ian.org>
Cc: oss-security <oss-security@...ts.openwall.com>
Subject: Re: vsftpd problem in deny_hosts

On Tue, Feb 3, 2015 at 6:56 AM, Moritz Muehlenhoff <jmm@...ian.org> wrote:

> On Tue, Feb 03, 2015 at 12:45:24PM +0300, Solar Designer wrote:
> > On Tue, Feb 03, 2015 at 09:28:36AM +0100, Marcus Meissner wrote:
> > > IBM reported to us a problem in vsftpd deny_hosts problem.
> > >
> > > CVE-2015-1419
> > >
> > > https://bugzilla.novell.com/show_bug.cgi?id=915522
> > >
> > > Description;
> > >  Set the option "deny_file" in /etc/vsftpd.conf on a top-directory
> (for example "deny_file=/home/*")
> > >  Then log in with ftp and try to cd to "/home/" first, which will
> fail, then try to cd to "/./home/" which will succeed!
> > >  The latter case shouldn't be possible as well!
> >
> > What does upstream say about this?  (CC'ing.)
>
> At least the man page states the deny_file is not a full-blown security
> measure:
>
> | This option is very simple, and should not be used for serious
> | access control - the filesystem's permissions should be used in
> preference.
>

Yeah, this option is very half-assed. I should probably have known better
than to implement it.

Other quotes from the man page:
---
In
              particular aware that if a filename is accessible by  a
 variety
              of  names  (perhaps  due  to symbolic links or hard links),
then
              care must be taken to deny access to all the names.
---
Because  of  this,  you will need to
              carefully and exhaustively test any application of this
 option.
              And  you  are  recommended to use filesystem permissions for
any
              important security policies due to  their  greater
 reliability.
---

The "variety of names" clause above is for situations like /home vs.
/./home/ vs. /../home vs. /.././../home etc.

This option is just a regex-like match against the raw FTP argument. So,
I'm not sure it's possible to use deny_file=/home/*. Even if that were
tweaked to deny_file=*/home/*, it would only work if the initial directory
were set _outside_ /home -- if it wasn't, RETR some/relative/path would
work because /home/ does not appear in the string.

Perhaps the wording in the man page is not strong enough, or not detailed
enough about implications, or I should just remove it? Suggestions welcome.


Cheers
Chris


>
> Cheers,
>         Moritz
>

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.