Apache httpd local DOS when serving pipes due to TOCTOU

[halfdog]

There seems to be a low priority local denial of service when apache is serving files from a user-modificable location. When the user is quickly replacing a file by a pipe with the same name, httpd will open the pipe causing the process to block.

Basically, the problem is the same as in http://www.halfdog.net/Security/2011/ApacheNoFollowSymlinkTimerace/ (issue number coming soon). To reproduce, you can use the same tool from the site.

cd /var/www
dd if=/dev/zero bs=4k count=1 of=file
mknod pipe p
./RenameLoop file empty pipe

Retrieve /file from remote until apache gets stuck.

Ubuntu security was informed 20110715, no reply so far. Issue could be combined with other buffer-overflow/timerace issue (issue number coming soon)

# lsb_release -rd
Description: Ubuntu oneiric (development branch)
Release: 11.10

# apt-cache policy apache2-mpm-worker
apache2-mpm-worker:
  Installed: 2.2.19-1ubuntu1
  Candidate: 2.2.19-1ubuntu1
  Version table:
 *** 2.2.19-1ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ oneiric/main i386 Packages
        100 /var/lib/dpkg/status

[halfdog (halfdog)]

Refs:
* Buffer overflow + timerace, hard to exploit without timing control: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/811422
* Symlink issue to get memory maps: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/811428

[halfdog (halfdog)]

On oneric, halt can be also triggered via vsftpd:

(echo $'USER test\nPASS my-secret\nCWD /home/test/www/pipetest'; while true; do echo $'RNFR file\nRNTO space\nRNFR pipe\nRNTO file\nRNFR space\nRNTO pipe'; done) | nc -v ubuntu-oneiric-test 21

It must be a task scheduling/io timing peculiarity, that this method has a higher trigger efficiency than the rename loop.

It seems, that it is not possible to create the pipe via vsftpd, so question remains, how to get a pipe to the server in a ftp-only environment. Perhaps other open-source or commercial servers support remote mknod? Could the symlink timerace be used to link to an pipe already existing on server?

==== TESTING CAVEAT =====

On hardy apache, no timerace is needed to bring apache to halt, so trivial pipe issue must have been solved between 2.2.8 and 2.2.19

# apt-cache policy apache2-mpm-worker
apache2-mpm-worker:
  Installed: 2.2.8-1ubuntu0.19
  Candidate: 2.2.8-1ubuntu0.19
  Version table:
 *** 2.2.8-1ubuntu0.19 0
        500 http://archive.ubuntu.com hardy-security/main Packages
        500 http://archive.ubuntu.com hardy-updates/main Packages
        100 /var/lib/dpkg/status
     2.2.8-1 0
        500 http://archive.ubuntu.com hardy/main Packages

[Marc Deslauriers (mdeslaur)]

Thanks for reporting this issue.

Could you please report this issue to the Apache Security Team, and possibly link the resulting bug report here.

Thanks.

[Marc Deslauriers (mdeslaur)]

See here for information on reporting this issue:
http://www.apache.org/security/

[Jamie Strandboge (jdstrand)]

What was the response from upstream?

[halfdog (halfdog)]

Upstream made a more general comment (see https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/811428), saying, that apache was never designed to have race-free symlink handling.

For me that means, that it is OK for it to follow, even when FollowSymlinks is off and even if the symlink points to /proc/self/maps - good against ASLR, see 811422 -- or a pipe -- when someone can create symlinks on the server, then he could also create an ultralarge sparse file and let the server deliver it, also blocking one server thread.

[halfdog (halfdog)]

Also reply from <email address hidden><email address hidden>:

On Fri, Jul 15, 2011 at 12:45:35AM +0000, halfdog wrote:
> cd /var/www
> dd if=/dev/zero bs=4k count=1 of=file
> mknod pipe p
> ./RenameLoop file empty pipe
>
> Retrieve /file from remote until apache gets stuck.
Hi Roman. "So what?" would be my short answer.

If a local user trusted to author content wishes to deny service to the
HTTP server, he has any number of ways to do it. Creating a multi-GB
sparse file and running ab against it would be a far more effective way
to deny service to remote users than blocking a single child/thread.

If you don't trust local users to DoS your server, don't give them shell
access, give them DAV or (restricted) FTP access to upload content. Or
have a very restrictive SELinux policy, or whatever.

Regards, Joe

[Launchpad Janitor (janitor)]

[Expired for apache2 (Ubuntu) because there has been no activity for 60 days.]