vsftpd connections fail on amd64: "500 OOPS: child died"

[James Page]

[Impact]

vsftpd is broken by default. seccomp sandboxing is turned on by default, and it doesn't work because it blocks itself from gettimeofday() calls for logging. The workaround is to disable seccomp sandboxing, which removes one layer of protection. vsftpd is security sensitive, so this is far from ideal.

[Development Fix]

Patched the seccomp sandbox to permit gettimeofday() calls. Patch sent upstream; no response received yet (24 hours, so a little early to expect a response).

dep8 test added to detect this in the future.

[Stable Fix]

Same as development fix.

[Test Case]

The included dep8 test automatically verifies the fix for this bug. Manual steps:

apt-get install vsftpd
ftp localhost
Press enter (to accept the default user)

Expected result: password prompt
Actual result: 500 oops

[Regression Potential]

seccomp sandboxing does not appear to work at all (in the default configuration, at least), and the patch only alters seccomp sandboxing. Thus those not using seccomp sandboxing should not be affected. This is a security sensitive patch, but the gettimeofday() call that is now permitted can only receive the time and cannot do anything to the system.

It is possible that adding an extra call to the whitelist could overflow something and break seccomp sandboxing in some drastic and insecure way, but the code involved is relatively small and appears to have appropriate bounds checking.

[Workaround]

Adding seccomp_sandbox=NO to /etc/vsftpd.conf works around this issue but turns off the nice sandboxing feature.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: vsftpd 3.0.2-1ubuntu2
ProcVersionSignature: User Name 3.10.0-6.17-generic 3.10.3
Uname: Linux 3.10.0-6-generic x86_64
ApportVersion: 2.12.1-0ubuntu3
Architecture: amd64
Date: Mon Sep 2 14:20:38 2013
Ec2AMI: ami-0000008b
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: aki-00000002
Ec2Ramdisk: ari-00000002
MarkForUpload: True
ProcEnviron:
 TERM=screen
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: vsftpd
UpgradeStatus: No upgrade log present (probably fresh install)
vsftpd.log: Error: [Errno 13] Permission denied: '/var/log/vsftpd.log'

[James Page (james-page)]

I get the following errors:

500 OOPS: priv_sock_get_cmd

and then on subsequent connections:

500 OOPS: child died

[James Page (james-page)]

I also appear to only see this issue in virtualized servers; running on hardware appears to be OK.

[James Page (james-page)]

Sep 2 14:25:51 vsftpd-debug kernel: [ 15.517149] type=1326 audit(1378131951.002:12): auid=4294967295 uid=65534 gid=65534 ses=4294967295 pid=1402 comm="vsftpd" sig=31 syscall=96 compat=0 ip=0x7fffacf79dff code=0x0

[James Page (james-page)]

This is also the cause of the DEP-8 test failures for squid3 on amd64.

Marking 'Confirmed' as re-produced independently in testing.

[Robie Basak (racb)]

Hi Chris,

I couldn't find any other details on how to submit contributions to
vsftpd, nor a public VCS or bugtracker or anything. Is emailing you
directly appropriate?

In Ubuntu, it seems that seccomp support never worked since vsftpd 3.0.2
landed in 13.10, and now in 14.04 LTS also. I tracked this down to
gettimeofday() not being permitted, which is used in the logging code.

Our bug is https://launchpad.net/bugs/1219857.

This trivial patch fixes the issue:

--- a/seccompsandbox.c
+++ b/seccompsandbox.c
@@ -300,6 +300,7 @@
   reject_nr(__NR_mremap, ENOSYS);

   /* Misc simple low-risk calls. */
+ allow_nr(__NR_gettimeofday); /* Used by logging */
   allow_nr(__NR_rt_sigreturn); /* Used to handle SIGPIPE. */
   allow_nr(__NR_restart_syscall);
   allow_nr(__NR_close);

Is there any reason that I shouldn't apply this to Ubuntu straight away?
It seems to me that this is a harmless call that shouldn't be a problem
to enable in the seccomp sandbox?

I also noticed that if syslog is enabled (syslog_enable=YES), then
seccomp also fails on a socket() call. Socket communication is perhaps
something that should not be permitted in the sandbox, so I've not gone
further on this, especially as it's non-default on Ubuntu anyway.

Would you consider these two bugs in vsftpd 3.0.2?

On a related note, various distributions (at least Debian, Ubuntu and
SUSE) are carrying another patch:
http://sources.debian.net/src/vsftpd/3.0.2-14/debian/patches/0015-disable-clone-newpid.patch.
I'm not sure if you are aware of this. All of Debian's patches are here
if you're interested:
http://sources.debian.net/src/vsftpd/3.0.2-14/debian/patches

Thanks,

Robie

[Robie Basak (racb)]

Here's a debdiff to fix this bug in Utopic, but I'll work on and upload a merge instead.

[Robie Basak (racb)]

The Utopic fix is in utopic-proposed, awaiting dep8 testing. I've uploaded the Trusty fix to trusty-proposed.

[Launchpad Janitor (janitor)]

This bug was fixed in the package vsftpd - 3.0.2-14ubuntu1

---------------
vsftpd (3.0.2-14ubuntu1) utopic; urgency=medium

  * Merge from Debian testing. Remaining changes:
    - d/vsftpd.upstart: migrate vsftpd to upstart.
      + d/vsftpd.init: remove.
    - d/{control,rules,vsftpd.apport}: add apport hook.
    - Add debian/watch file.
    - d/p/ubuntu-disable-anonymous.patch: disable anonymous login by default.
  * Drop changes (adopted in Debian):
    - d/p/12-ubuntu-use-snakeoil-ssl.patch
    - d/p/13-disable-clone-newpid.patch
  * d/p/ubuntu-seccomp-gettimeofday.patch: permit gettimeofday() for logging calls
    (LP: #1219857).
  * Add dep8 test.
 -- Robie Basak <email address hidden> Tue, 29 Apr 2014 14:03:51 +0000

[Brian Murray (brian-murray)]

Hello James, or anyone else affected,

Accepted vsftpd into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/vsftpd/3.0.2-1ubuntu2.14.04.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[timpambor (timpambor)]

3.0.2-1ubuntu2.14.04.1 fixed the bug for me. Tested on amd64 with Linux 3.13.0-24-generic.

[Launchpad Janitor (janitor)]

This bug was fixed in the package vsftpd - 3.0.2-1ubuntu2.14.04.1

---------------
vsftpd (3.0.2-1ubuntu2.14.04.1) trusty; urgency=medium

  * d/p/ubuntu-seccomp-gettimeofday.patch: permit gettimeofday() for logging
    calls (LP: #1219857).
  * Add dep8 smoke test.
 -- Robie Basak <email address hidden> Tue, 29 Apr 2014 15:33:07 +0000

[Adam Conrad (adconrad)]

The verification of the Stable Release Update for vsftpd has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.