-
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
