vsftpd: Configuring pam to prompt for a password on bad us..

Mark Hobley · External Since: Jan 14, 2009 Posts: 28

By default, vsftpd contains a security flaw, which causes the system to skip
asking for a password if the username is invalid.

http://securitytracker.com/id?1008628

Apparently a workaround for this is to configure pam to prompt for a password,
even though the username is invalid.

Does anyone actually know how to do this? What configuration changes to I need
to make to pam to cause the password to be asked for even when the provided
username is invalid?

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

Nathan Keel · External Since: May 04, 2009 Posts: 12

Mark Hobley wrote:

> By default, vsftpd contains a security flaw, which causes the system
> to skip asking for a password if the username is invalid.
>
> http://securitytracker.com/id?1008628
>
> Apparently a workaround for this is to configure pam to prompt for a
> password, even though the username is invalid.
>
> Does anyone actually know how to do this? What configuration changes
> to I need to make to pam to cause the password to be asked for even
> when the provided username is invalid?
>
> Mark.
>

That is just the default behavior of some varsions as far as I know, and
can be changed. PAM is fine, but geez, I've seen more security notices
about PAM over the years comparing the two. Personally, I use
pure-ftpd (or proftpd before I used that), so it's been a while since
I've bothered with vsftp.

Allen Kistler · External Since: Jun 26, 2004 Posts: 367

Mark Hobley wrote:
> By default, vsftpd contains a security flaw, which causes the system to skip
> asking for a password if the username is invalid.
>
> http://securitytracker.com/id?1008628
>
> Apparently a workaround for this is to configure pam to prompt for a password,
> even though the username is invalid.
>
> Does anyone actually know how to do this? What configuration changes to I need
> to make to pam to cause the password to be asked for even when the provided
> username is invalid?

This behavior does not occur in RHEL 5 (vsftpd-2.0) or Fedora 11
(vsftpd-2.1). I'm not certain it's the pam configuration, though.

Anyway, here's the auth portion of the default F11 config for vsftpd.

in vsftpd.conf:
pam_service_name=vsftpd

in /etc/pam.d/vsftpd (watch for line wrap):
auth required pam_listfile.so item=user sense=deny
file=/etc/vsftpd/ftpusers onerr=succeed
auth required pam_shells.so
auth include system-auth

in /etc/pam.d/system-auth:
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth required pam_deny.so

Grant · External Since: Feb 26, 2009 Posts: 22

On Wed, 05 Aug 2009 23:08:02 GMT, markhobley.RemoveThis@hotpop.donottypethisbit.com (Mark Hobley) wrote:

>By default, vsftpd contains a security flaw, which causes the system to skip
>asking for a password if the username is invalid.
>
>http://securitytracker.com/id?1008628

That's a very old report, does vsftpd 2.x still has the problem?

Grant.
--
http://bugsplatter.id.au

marrgol · External Since: Mar 19, 2009 Posts: 4

On 2009-08-06 01:08, Mark Hobley wrote:
> By default, vsftpd contains a security flaw, which causes the system to skip
> asking for a password if the username is invalid.
>
> http://securitytracker.com/id?1008628
>
> Apparently a workaround for this is to configure pam to prompt for a password,
> even though the username is invalid.
>
> Does anyone actually know how to do this? What configuration changes to I need
> to make to pam to cause the password to be asked for even when the provided
> username is invalid?

First you have to set "userlist_enable=NO" in vsftpd.conf. If you don't
need to use a list of users who are to be denied or allowed ftp access
then that's it.

If you do need such lists, then pam_listfile is the module to be
employed.

--
mrg

marrgol · External Since: Mar 19, 2009 Posts: 4

On 2009-08-06 02:59, Grant wrote:
> On Wed, 05 Aug 2009 23:08:02 GMT, markhobley RemoveThis @hotpop.donottypethisbit.com (Mark Hobley) wrote:
>
>> By default, vsftpd contains a security flaw, which causes the system to skip
>> asking for a password if the username is invalid.
>>
>> http://securitytracker.com/id?1008628
>
> That's a very old report, does vsftpd 2.x still has the problem?

Actually it behaves so by design when a specific option is set
(and by default it is not).

--
mrg

Mark Hobley · External Since: Jan 14, 2009 Posts: 28

In comp.os.linux.misc Grant <g_r_a_n_t_.RemoveThis@bugsplatter.id.au> wrote:
> That's a very old report, does vsftpd 2.x still has the problem?

Yes, it still applies. I have spoken to the developer about this, but he does
not want to fix this because he considers username mining less of a security
risk than plain password transmission, however the system works the opposite
way if usename whitelisting is not used, (ie all usernames, and plain password
transmission) which is contrary to his argument.

However, he does say that modifying the pam configuration will fix this, but
neither he nor anyone else so far seems to know how to do this.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

Mark Hobley · External Since: Jan 14, 2009 Posts: 28

In comp.os.linux.misc Allen Kistler <ackistler.RemoveThis@oohay.moc> wrote:
> This behavior does not occur in RHEL 5 (vsftpd-2.0) or Fedora 11
> (vsftpd-2.1). I'm not certain it's the pam configuration, though.

It only occurs if you are using username whitelisting, ie
userlist_enable = YES

> Anyway, here's the auth portion of the default F11 config for vsftpd.
>
> in vsftpd.conf:
> pam_service_name=vsftpd
>
> in /etc/pam.d/vsftpd (watch for line wrap):
> auth required pam_listfile.so item=user sense=deny
> file=/etc/vsftpd/ftpusers onerr=succeed
> auth required pam_shells.so
> auth include system-auth
>
> in /etc/pam.d/system-auth:
> auth required pam_env.so
> auth sufficient pam_unix.so nullok try_first_pass
> auth requisite pam_succeed_if.so uid >= 500 quiet
> auth required pam_deny.so

Ok, I modified the configuration to match the above, and restarted the vsftpd
service.

From a host on the lan:

ftp neptune
Connected to neptune.markhobley.yi.org.
220 Welcome to Mark Hobley's File Transfer Protocol Server.
Name (neptune:test): test
530 Permission denied. <--- It should ask for a password here
Login failed.
ftp>

Nope. It still did not ask for a password, so that did not work.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

Grant · External Since: Feb 26, 2009 Posts: 22

On Thu, 06 Aug 2009 07:08:02 GMT, markhobley.DeleteThis@hotpop.donottypethisbit.com (Mark Hobley) wrote:

>In comp.os.linux.misc Grant <g_r_a_n_t_.DeleteThis@bugsplatter.id.au> wrote:
>> That's a very old report, does vsftpd 2.x still has the problem?
>
>Yes, it still applies. I have spoken to the developer about this, but he does
>not want to fix this because he considers username mining less of a security
>risk than plain password transmission, however the system works the opposite
>way if usename whitelisting is not used, (ie all usernames, and plain password
>transmission) which is contrary to his argument.

I use vsftpd, but only for anonymous access, so I never looked to solve
this issue.
>
>However, he does say that modifying the pam configuration will fix this, but
>neither he nor anyone else so far seems to know how to do this.

Sorry, I don't use PAM here.

Grant.
--
http://bugsplatter.id.au

Mark Hobley · External Since: Jan 14, 2009 Posts: 28

In comp.os.linux.networking Nathan Keel <nat.k.TakeThisOut@gm.ml> wrote:

> I've seen more security notices
> about PAM over the years comparing the two. Personally, I use
> pure-ftpd (or proftpd before I used that), so it's been a while since
> I've bothered with vsftp.

Why did you switch from vsftpd?

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

Allen Kistler · External Since: Jun 26, 2004 Posts: 367

Mark Hobley wrote:
> Allen Kistler wrote:
>> This behavior does not occur in RHEL 5 (vsftpd-2.0) or Fedora 11
>> (vsftpd-2.1). I'm not certain it's the pam configuration, though.
>
> It only occurs if you are using username whitelisting, ie
> userlist_enable = YES
>
>> Anyway, here's the auth portion of the default F11 config for vsftpd.
>>
>> [snip]
>>
>> in /etc/pam.d/vsftpd (watch for line wrap):
>> auth required pam_listfile.so item=user sense=deny
>> file=/etc/vsftpd/ftpusers onerr=succeed
>>
>> [snip]
>
> Ok, I modified the configuration to match the above, and restarted the vsftpd
> service.
>
> From a host on the lan:
>
> ftp neptune
> Connected to neptune.markhobley.yi.org.
> 220 Welcome to Mark Hobley's File Transfer Protocol Server.
> Name (neptune:test): test
> 530 Permission denied. <--- It should ask for a password here
> Login failed.
> ftp>
>
> Nope. It still did not ask for a password, so that did not work.

The default RH/Fedora config uses pam for blacklisting. If you want to
whitelist, how about setting "userlist_enable = NO" in vsftpd.conf and
then in pam ...

auth required pam_listfile.so item=user sense=allow
file=/etc/vsftpd/user_list onerr=fail

.... instead of the previous listfile line? That changes pam to allow
only the people in user_list (the default for userlist_file, I believe,
but you can use whatever file name you want). It fails if user_list
doesn't exist or has garbage in it.

BTW, the default in RH/Fedora is also
userlist_enable = YES
userlist_deny = YES

i.e., blacklist, so admins have a choice of using ftpusers or user_list
for blacklisting. Did you change to "userlist_deny = NO" and that's
when the bug happens? (Hmm. Maybe I'll play a bit and see if I can
make it happen....)

Allen Kistler · External Since: Jun 26, 2004 Posts: 367

Allen Kistler wrote:
> Mark Hobley wrote:
>> Allen Kistler wrote:
>>> This behavior does not occur in RHEL 5 (vsftpd-2.0) or Fedora 11
>>> (vsftpd-2.1). I'm not certain it's the pam configuration, though.
>>
>> It only occurs if you are using username whitelisting, ie
>> userlist_enable = YES
>>
>> [snip]
>
> [snip]
>
> BTW, the default in RH/Fedora is also
> userlist_enable = YES
> userlist_deny = YES
>
> i.e., blacklist, so admins have a choice of using ftpusers or user_list
> for blacklisting. Did you change to "userlist_deny = NO" and that's
> when the bug happens? (Hmm. Maybe I'll play a bit and see if I can
> make it happen....)

So I *can* see the bug in RH/Fedora if I use the vsftpd userlist. I
just didn't touch it the right way before. In any case, disabling the
vsftpd userlist and using the pam one exclusively does seem the assured fix.

Nathan Keel · External Since: May 04, 2009 Posts: 12

Mark Hobley wrote:

> In comp.os.linux.networking Nathan Keel <nat.k.RemoveThis@gm.ml> wrote:
>
>> I've seen more security notices
>> about PAM over the years comparing the two. Personally, I use
>> pure-ftpd (or proftpd before I used that), so it's been a while since
>> I've bothered with vsftp.
>
> Why did you switch from vsftpd?
>
> Mark.
>

I don't recall, to be honest. It might have been a stability, security
or feature reason. I've never bothered to look back. I really could
use any of the 3 and be happy enough.

Mark Hobley · External Since: Jan 14, 2009 Posts: 28

In comp.os.linux.misc Allen Kistler <ackistler DeleteThis @oohay.moc> wrote:

> The default RH/Fedora config uses pam for blacklisting. If you want to
> whitelist, how about setting "userlist_enable = NO" in vsftpd.conf and
> then in pam ...

I am not sure whether I am entirely happy with that as a solution, although it
may work. I would rather not have to disable the username whitelisting
facility within the application. Ideally we need someone to create a patched
fork here, so that the whitelisting/blacking facilities does not affect whether
or not a password is asked for, which should be an entirely separate option.
It seems crazy that whitelisting means no password and blacklisting means
password: with blacklisting, there are a greater number of usernames to be
mined.

I might just switch ftp server to another package. How do other ftp server
packages compare to vsftpd? Are they as secure in other aspects besides this
bug?

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

Mark Hobley · External Since: Jan 14, 2009 Posts: 28

In comp.os.linux.networking Mark Hobley <markhobley DeleteThis @hotpop.donottypethisbit.com> wrote:
> Ideally we need someone to create a patched fork here, so that the
> whitelisting/blacking facilities does not affect whether
> or not a password is asked for, which should be an entirely separate option.
> It seems crazy that whitelisting means no password and blacklisting means
> password

I wonder if it is practical to kludge the code to fix this, possibly by
reversing the polarity of a flag, or removing the conditional branch that
causes the password to skip. Unfortunately I am not very experienced in C
programming (My background is with BASIC and Assembly Language).

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

Allen Kistler · External Since: Jun 26, 2004 Posts: 367

Mark Hobley wrote:
> Mark Hobley wrote:
>> Ideally we need someone to create a patched fork here, so that the
>> whitelisting/blacking facilities does not affect whether
>> or not a password is asked for, which should be an entirely separate option.
>> It seems crazy that whitelisting means no password and blacklisting means
>> password
>
> I wonder if it is practical to kludge the code to fix this, possibly by
> reversing the polarity of a flag, or removing the conditional branch that
> causes the password to skip. Unfortunately I am not very experienced in C
> programming (My background is with BASIC and Assembly Language).

So you are willing to kludge the vsftpd code, but unwilling to use pam?
What's the resistance to pam?
It not only works. It appears to be recommended.

Mark Hobley · External Since: Jan 14, 2009 Posts: 28

In comp.os.linux.misc Allen Kistler <ackistler RemoveThis @oohay.moc> wrote:
> So you are willing to kludge the vsftpd code, but unwilling to use pam?
> What's the resistance to pam?

I don't mind using pam, but I just don't like the idea of switching off the
applications userlist filtering. It just somehow feels like a compromise.
I think maybe that the concern is really if pam goes wrong during some future
debian update, I will have switched off the ftp whitelisting, enabling all
users access to the ftp service. I would feel much happier if the code was
fixed, to enable me to still keep userlist filtering active. (The solution
seems more of a kludge than a code fix).

If I cannot fix the code, I will probably end up switching packages. I
didn't really want to have to learn to setup the ftp server all over again.
Never mind.

Maybe it is possible to keep the application userlist filtering, but somehow
configure pam to prompt for the password after an invalid username is entered?
Can pam do this?

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

Allen Kistler · External Since: Jun 26, 2004 Posts: 367

Mark Hobley wrote:
> Allen Kistler wrote:
>> So you are willing to kludge the vsftpd code, but unwilling to use pam?
>> What's the resistance to pam?
>
> I don't mind using pam, but I just don't like the idea of switching off the
> applications userlist filtering. It just somehow feels like a compromise.
> I think maybe that the concern is really if pam goes wrong during some future
> debian update, I will have switched off the ftp whitelisting, enabling all
> users access to the ftp service. I would feel much happier if the code was
> fixed, to enable me to still keep userlist filtering active. (The solution
> seems more of a kludge than a code fix).

Well, pam is pretty much all about authentication. If anything, I'd
expect a future version of vsftpd to remove the in-application userlist
code completely in favor of pam.

In terms of both software architecture and infrastructure architecture,
a common authentication and authorization engine is much more preferable
to every-application-for-itself home-brewed security.

> If I cannot fix the code, I will probably end up switching packages. I
> didn't really want to have to learn to setup the ftp server all over again.
> Never mind.

And if the other ftpd package uses only pam from the beginning ...?

> Maybe it is possible to keep the application userlist filtering, but somehow
> configure pam to prompt for the password after an invalid username is entered?
> Can pam do this?

I haven't looked at the code, but I expect it goes something like:

1. vsftpd prompts for username
2. if enabled, vsftpd checks if username is anonymous, done if success
3. if enabled, vsftpd checks the userlist, error if success (blacklist)
or error if fail (whitelist)
4. if compiled, vsftpd calls pam with username, pam returns result
otherwise vsftpd prompts for password and checks user/pass
5. vsftpd errors if fail

vsftpd-blacklisted users and vsftpd-not-whitelisted users never get
passed to pam, so all the pam configuration in the world won't do
anything until you disable the vsftpd userlist.

Bill Marcum · External Since: Dec 18, 2006 Posts: 293

["Followup-To:" header set to comp.os.linux.misc.]
On 2009-08-07, Mark Hobley <markhobley.RemoveThis@hotpop.donottypethisbit.com> wrote:
> In comp.os.linux.misc Allen Kistler <ackistler.RemoveThis@oohay.moc> wrote:
>> So you are willing to kludge the vsftpd code, but unwilling to use pam?
>> What's the resistance to pam?
>
> I don't mind using pam, but I just don't like the idea of switching off the
> applications userlist filtering. It just somehow feels like a compromise.

Does vsftpd do like some other ftp servers, checking whether a user's
shell is listed in /etc/shells?