<<< Date Index >>>     <<< Thread Index >>>

Apache Prefork MPM vulnerabilities - Report




-----
Apache Prefork MPM vulnerabilities
----------------------------------


PSNC Security Team

http://security.psnc.pl/files/apache_report.pdf


1. Introduction

This small case study is a result of source code analysis of Apache httpd 
server MPM modules. The main goal of this document is to show, what may be done 
by an attacker who has the possibility of running arbitrary code in the context 
of the worker process (WP).

2. Research scope

Our work has been concentrated on verifying whether (and to which extent) it is 
secure to run an external code in the worker process context. Such code may be 
provided through appropriate functions of script languages attached as a module 
(like dl(), dlopen()) or as a result of running an exploit of one of 
vulnerabilities found in Apache modules (e.g. Integer Overflow in chunk_split() 
function). In order to simulate running an external code in the WP context we 
use dl() function from mod_php module.

3. Prefork MPM

Prefork MPM is the default Apache httpd server process management module for 
*nix systems. A server based upon this architecture runs 1 master process (MP) 
and n worker processes (WP). The MP running with root credentials, controls the 
amount of WPs. WPs acting with nobody user credentials handle the users 
requests.

(...)

4. Additional information useful for vulnerability analysis
a. Running arbitrary code in the worker process

For demonstration purposes we will use mod_php module. This module allows to 
run PHP scripts in the context of WP process. In order to run the code we will 
use dl() function that allows to load a custom PHP module. The dl() function 
loads a library (dlopen) and looks for appropriate symbols in order to check 
whether the library being loaded is a PHP module. Putting arbitrary code in the 
init section of this library causes running that code during loading this 
library by the WP.

b. Finding process_score and worker_score arrays

In our examples we use vulnerabilities associated with modifying process_score 
and worker_score structures arrays. These arrays are located in scoreboard 
array that is put into a shared memory segment.
The first task to do is to find the shared memory segment address. In order to 
find that address we find the /dev/zero (Apache 2.x) or //SYS. (Apache 1.3) 
memory in /proc/self/maps file.

Example 1


(...)


As we know how to run arbitrary code in the WP process context and where the 
two arrays are located, let.s have some fun modifying the arrays.

5. Bugs, weaknesses, features PoC #1: httpd DoS

(..)

In the process_score array we put a random PID > 0 and we set its status in the 
worker_score array as 1. Additionally we send a SIGKILL signal to all other WPs. 
After both arrays are modified, we finish the WP activity.

The MP will no longer create new WPs, because . according to the information 
taken from the worker_score array, there are WPs able to handle incoming 
requests.

PoC #2 DoS  (Apache 1.3.x, 2.x)

As we look at the function responsible for creating new WPs, we can see that it uses for 
that purpose the information taken from the process_score and worker_score structures. The 
procedure of verifying the new processes amount is run after one of the WPs finishes its 
activity (ap_wait_or_timeout(&exitwhy, &status, &pid, pconf);). An exemplary 
code that forces the MP to create an unlimited amount of new WPs looks like shown below:

Example 3
while(1) {
int pid1;
usleep(1000);
for(i=0;i<(wsk_global_score->server_limit);i++)
        {
        if((wsk_process_score+i)->pid && (wsk_process_score+i)->pid!=mypid) 
pid1=(wsk_process_score+i)->pid;
        (wsk_process_score+i)->pid=0;
        (wsk_worker_score+i)->my_access_count=0;
        (wsk_worker_score+i)->access_count=0;
        (wsk_worker_score+i)->status=0;
        }
        if(pid1) kill(pid1,9);
}

The function above clears worker_score and process_score arrays. The MP, after having 
reviewed empty worker_score and process_score arrays finds that there is an insufficient 
amount of free WP processes. However, the function kills some of remaining WPs, because of 
which the MP continues its activity stopped at the ap_wait_or_timeout(&exitwhy, 
&status, &pid, pconf); function and creates another 5 new processes.
The function shown above forces creating an unlimited amount of WP processes by 
the MP process, which in turn causes consuming all server resources.

PoC #3 SIGUSR1 killer #1 (Apache 2.x)

(...)


PoC #4 SIGUSR1 killer #2 (Apache 1.3)

The MP process is able to remove unnecessary processes. If there are too many 
WP processes with IDLE status, the MP sends SIGUSR1 signal to the appropriate 
process taken from the process_score array. During sending the signal the MP 
process does not verify whether the PID put into the process_score array is 
really a PID that belongs to the appropriate WP process. Therefore a specific 
modification of worker_score and process_score arrays allows to send SIGUSR1 
signal to arbitrary process in the system by the MP process.

Example 3

(...)


The function, after it checks that there is too many free WP processes, sends a 
SIGUSR1 signal to one of them.


The weaknesses mentioned below are rather features that result from the server 
architecture, than security vulnerabilities. However, they are worth mentioning 
just to exhaust the subject of Apache security.

PoC #5 Stealing the sensitive data (Apache 1.3.x, 2.x)

The Apache server architecture (1 MP managing the child processes and n WPs 
that respond to client requests) assumes that any WP is able to serve a request 
that is directed to any virtual host. Therefore each of the WPs has got a 
complete information on the whole server configuration.

(...)

PoC #6 Spoofing  (Apache 1.3.x, 2.x)


The Apache Web server architecture makes it possible for the modules to attach 
their own functions to appropriate hooks. The information on hooks is stored in 
an apr_global_hook_pool structure that is located in the heap memory of each 
WP. The pool is configured during the start of the system. The pool contents is 
not verified by the WP during handling consecutive requests from the clients. 
The modification of entries put into hook chains will be visible during every 
further request being handled by the same WP. A specific modification of the 
pool (adding own functions to appropriate hooks) gives the possibility of 
generating arbitrary content for any virtual host configured within the same 
instance of Apache Web server.

The source code of an example that is able to exploit this vulnerability is too 
extensive to be put within this report. An exemplary tool that modifies the 
content of apr_global_hook_pool pool may be downloaded from the PSNC Security 
Team webpage.


6. Summary . A secure installation

The vulnerabilities mentioned above may be exploited in some specific 
situations (e.g. an attacker must be able to run the code in the WP context). 
The analysis shows that the server is secure only if the administrator does not 
allow to run a dangerous code. Therefore the question arises . how to secure a 
hosting system?
An administrator who secures his or her server should follow the guidelines 
below:
.       All content generators (php, perl etc.) must be run by separate 
processes. The languages should be attached to the Web server as cgi/fcgi!
.       Beware of the mod_ssi extension. The extension allows to run external 
applications with daemon/apache credentials <--#exec cmd=.. -->
.       For each virtual host a separate user within the system should be 
created, whose credentials will be used for generating content.
.       Virtual hosts should be created only for trusted domains. For the users 
that do not trust each other, a separate instance of the Web server should be 
rather applied.

(...)



All report is now available online - 
http://security.psnc.pl/files/apache_report.pdf

PSNC Security Team