Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Mon, Aug 12, 2013 at 11:11 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 12.08.2013 19:28, schrieb Coderaptor: I have been a silent spectator to this drama, and could not resist adding a few thoughts of my own: All software, especially webservers, should ship with secure defaults yes, but define secure defaults without a context hint: you can't Oh, a practical context can very well be established. We aren't talking about formal methods are we? It is a fundamental mistake to assume all admins who roll out web apps and maintain servers RTFM before rolling out it is a fundamental mistake not doing so and be admin Agree. However, the vast amount of data shows otherwise. Its easy to have reasonable secure defaults than expect knowledgeable admins, IMO. 2. Apache clearly does not ship with secure defaults in favor of convenience? disable_functions is a example disable_functions has *nothing* to do with Apache because it is a php option apache itself *does not* create symlinks at all My bad. PHP it is. Well, PHP design is broken then. do you expect an admin to be a unix expert or know what each parameter in there means? *yes* *yes* and *yes* again *cough* *cough*. Ideally, yes. Practically, no. Why not enable_functions instead, with everything disabled to begin with? (Oh, that wouldn't help you achieve world dominance and fast!) another example that people with no clue make proposals there you go: http://www.php.net/manual/en/funcref.php come on, list all functions except the one i listed *Again*: Apache does not create any symlink Apache does only *follow* so what should suExec do for you if you are refuse to understand what the different software-layers are supposed to do and why different layers exist at all and finally how to manage all of them? so disable follow symlinks in Apache or disable potential dangerous functions in scripting languages - and since Apache can not control any low level function a scripting language is using and symlinks are not the only dangerous thing you should do *both* or not play admin this thread is a good example that lazy admins are dreaming about rollout a powerful *and* secure service with default configurations and this naive attitude is only possible by beeing completly clueless, if one would understand the underlying tech he would no longer dream of flying horses That's a sad fact. And it is compounded by poorly written framework, and software. I am depressed, we are doomed. Now, where is my coffee? -coderaptor On Aug 11, 2013, at 3:30 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.08.2013 23:56, schrieb Stefan Kanthak: Reindl Harald h.rei...@thelounge.net 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
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
I hate to come late to the party, but following all of this, it is kind of ridiculous. I have to agree with those before in saying software should ship secure. in my environment whenever we are given a new bit to add to our infrastructure, be it a new server, new version of an OS, or new version of a software, either A) it comes to us from those at our distribution point pre templated to be unusable due to security, or B) we first make it unusable by configuring every possible security setting to be as tight as possible... After which we slowly switch off or pull back settings until it meets the functionality required. It has been repeated throughout the course of this...Discussion? if whats been going on qualifies as a discussion, that the default settings are fine, and that it is only lazy admins who don't take the time to rtfm that are the problems. Why is that acceptable? Should it not be the job of the software to be as secure as possible, with the admins/local developers having to take the time to read through the configs to make it work in the way they need it to? when you buy a house you don't buy it with no doors or windows, and then have them say well, if you want you can add doors, that will make it a little safer, we recommend getting doors with locks, for the best possible security. No, You expect your house to come to you with doors and locks, and these day's, most of the time, security systems, pre installed. This idea that it is OK to ship software insecure not only weakens the security posture of the internet/intranet in general, but actually breeds the lazy admins that others seem to keep pinning the problem on. If every bit of software was shipped as a brick, instead of just working with security flaws, then admins and developers alike would have to own up to their own weaknesses and make things work while understanding what they are doing. Forget the professional high level development or admin level. Lets talk about the basic user that is just trying to stumble their way through getting something setup. There are a lot of them, and if they run ./install or ./setup on a program, and it works afterwards, that is the end of it. Having more of those sites floating around due to ignorant masses does not in anyway help the security posture of the world at large, and it is a narrow mind-set that thinks that it is OK for software developers such as apache to pass the buck onto their users. --- Brandon Graves Am 12.08.2013 19:28, schrieb Coderaptor: I have been a silent spectator to this drama, and could not resist adding a few thoughts of my own: All software, especially webservers, should ship with secure defaults yes, but define secure defaults without a context hint: you can't It is a fundamental mistake to assume all admins who roll out web apps and maintain servers RTFM before rolling out it is a fundamental mistake not doing so and be admin 2. Apache clearly does not ship with secure defaults in favor of convenience? disable_functions is a example disable_functions has *nothing* to do with Apache because it is a php option apache itself *does not* create symlinks at all do you expect an admin to be a unix expert or know what each parameter in there means? *yes* *yes* and *yes* again Why not enable_functions instead, with everything disabled to begin with? (Oh, that wouldn't help you achieve world dominance and fast!) another example that people with no clue make proposals there you go: http://www.php.net/manual/en/funcref.php come on, list all functions except the one i listed *Again*: Apache does not create any symlink Apache does only *follow* so what should suExec do for you if you are refuse to understand what the different software-layers are supposed to do and why different layers exist at all and finally how to manage all of them? so disable follow symlinks in Apache or disable potential dangerous functions in scripting languages - and since Apache can not control any low level function a scripting language is using and symlinks are not the only dangerous thing you should do *both* or not play admin this thread is a good example that lazy admins are dreaming about rollout a powerful *and* secure service with default configurations and this naive attitude is only possible by beeing completly clueless, if one would understand the underlying tech he would no longer dream of flying horses On Aug 11, 2013, at 3:30 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.08.2013 23:56, schrieb Stefan Kanthak: Reindl Harald h.rei...@thelounge.net 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
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 12.08.2013 23:32, schrieb coderaptor:
Why can't enable_functions be pre-populated with known good functions, and
everything else disabled? Again,
sacrificing security convenience is the norm.
if you would only have the slightest clue what you are speaking about
you would not ask that naive
[harry@srv-rhsoft:~]$ php -r print_r(get_defined_functions()); | wc -l
1330
oh, and they depend on the loaded extensions (inlcuding 3rd party extensions)
oh, and they *all* would have to be classified if, how and in which context
they all may or may not have a secuirity impact
ALL software MUST come with SECURE DEFAULTS. PERIOD. Anyone who thinks
otherwise should fly in an aircraft running
his own designed software. Knowledgeable Admins are not an alternative to
secure defaults, rather I'd prefer both.
*define what is secure* and make sure you define it by context
unlink('file_my_script_wrote'); is fine
unlink($_GET['what_ever_input']): is a security hole
so do we now disable unlink();
Why not?
hey in this case you need also to disable fopen(), file_put_contents()
and whatever function can open and overwrite a file - now you could
come and argue but the permissions should not allow - well, your
config should also not allow any random script to create symlinks
on a internal application which is not accesable from the web
symlink() is harmless and may be used for good reasons
so you should realize that security is not black and white
Go ahead and disable all 1330 functions if the need be, and let the
Administrator figure out which ones he should carefully enable. It may
take a month to roll out the web app, but it will be secure and
totally under control. By your definition, an Administrator should
RTFM, be excellent at everything, so there should be no problem for
him/her to enable whatever he/she wants. And its a one time effort,
and worth it since it makes the security much better to begin with.
No, the actual fear most designers face is nobody using their designed
piece of art, which is why functionality trumps everything.
if you nned 100% secure defaults do not allow CGI and script interpreters
and go back to static sites because you have to realize that *any*
scripting lanuguage is a security risk per definition - period
Just for the sake of argument? Which sane framework provides 1330
functions? Security is surely not black and white, but this argument
should not justify poor design choices. Anyways, no matter what one
does, using a framework with 1330 functions is poor security decision
to start with, so no matter you have enable_functions, or
disable_functions, you are doomed.
As I said earlier, I am depressed.
-coderaptor
On Mon, Aug 12, 2013 at 12:10 PM, George Machitidze gio...@gmail.com
mailto:gio...@gmail.com wrote:
Heh
disable_functions and open_basedir is bad example. It's not an apache
part - it's PHP, so forget about it -
it's a feature of PHP. enable_functions is a very bad idea - the list
of allowed ones would be too large for
any business, development or user needs. That's why administrators (I
do) read changelogs before upgrading
software, and why they check all the functions documented and all the
details regarding what these functions
do, this is PHP feature, not httpd feature or httpd bug. The question is
why PHP processes, forks etc running
under apache/cgi/etc are allowed to do anything what apache can do. This
is the issue right? If PHP has
security a bug, which allows to bypass these php.ini-related
security/sandboxing settings, it means we should
sacrifice security needs and trust PHP only? I need them both, where
possible. We can't even control and
isolate subprocesses with selinux, because for cgroups/selinux they
share same group and contexts. BTW, one
reminded me in here - itk mpm has workarounds for this problem.
http://mitka.us/articles/mpm-itk/
It's definitely not a bug, it's an architecture, which must be
redesigned sooner or later.
On Mon, Aug 12, 2013 at 9:28 PM, Coderaptor coderap...@gmail.com
mailto:coderap...@gmail.com wrote:
disable_functions
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Mon, Aug 12, 2013 at 4:06 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 13.08.2013 00:51, schrieb coderaptor:
On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald h.rei...@thelounge.net
wrote:
ALL software MUST come with SECURE DEFAULTS. PERIOD. Anyone who thinks
otherwise should fly in an aircraft running
his own designed software. Knowledgeable Admins are not an alternative to
secure defaults, rather I'd prefer both.
*define what is secure* and make sure you define it by context
unlink('file_my_script_wrote'); is fine
unlink($_GET['what_ever_input']): is a security hole
so do we now disable unlink();
Why not?
because it is plain stupid
You think so. Not everyone shares your opinion.
you even statet that you did not realize that others are talking
about PHP and you not knew the context of 'disable_functions'
and so stop trying to be a smartass in topics you are clueless
Please no personal insults.
hey in this case you need also to disable fopen(), file_put_contents()
and whatever function can open and overwrite a file - now you could
come and argue but the permissions should not allow - well, your
config should also not allow any random script to create symlinks
on a internal application which is not accesable from the web
symlink() is harmless and may be used for good reasons
so you should realize that security is not black and white
Go ahead and disable all 1330 functions if the need be, and let the
Administrator figure out which ones he should carefully enable
please stop making yourself *that* laughable
I don't care.
if you nned 100% secure defaults do not allow CGI and script interpreters
and go back to static sites because you have to realize that *any*
scripting lanuguage is a security risk per definition - period
Just for the sake of argument? Which sane framework provides 1330
functions? Security is surely not black and white, but this argument
should not justify poor design choices. Anyways, no matter what one
does, using a framework with 1330 functions is poor security decision
please be quite and come back after you understood the difference
between a programming language and a framework
hint:
* PHP: programming language
* Ruby:programming language
* Zend Framework, Symfony: Framework
* Ruboy On Rails: Framework
Does it matter if I call at a framework, programming language, or
dancing donkey? It doesn't change the reality.
Just because you have an opinion does not make it more right than
others. PHP sucks with 1300 functions (what programming language
requires 1300 functions? The one that is designed poorly), that's a
fact. And you aren't helping it suck less. I may be clueless about how
the apache + php glue and php work, but I am now very sure that I
won't use PHP. And will probably stick with my OpenBSD implementation
of chrooted apache - apache is fit to be in a jail.
I rest my case.
-coderaptor
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 12.08.2013 23:32, schrieb coderaptor:
Why can't enable_functions be pre-populated with known good functions, and
everything else disabled? Again,
sacrificing security convenience is the norm.
if you would only have the slightest clue what you are speaking about
you would not ask that naive
[harry@srv-rhsoft:~]$ php -r print_r(get_defined_functions()); | wc -l
1330
oh, and they depend on the loaded extensions (inlcuding 3rd party extensions)
oh, and they *all* would have to be classified if, how and in which context
they all may or may not have a secuirity impact
ALL software MUST come with SECURE DEFAULTS. PERIOD. Anyone who thinks
otherwise should fly in an aircraft running
his own designed software. Knowledgeable Admins are not an alternative to
secure defaults, rather I'd prefer both.
*define what is secure* and make sure you define it by context
unlink('file_my_script_wrote'); is fine
unlink($_GET['what_ever_input']): is a security hole
so do we now disable unlink();
hey in this case you need also to disable fopen(), file_put_contents()
and whatever function can open and overwrite a file - now you could
come and argue but the permissions should not allow - well, your
config should also not allow any random script to create symlinks
on a internal application which is not accesable from the web
symlink() is harmless and may be used for good reasons
so you should realize that security is not black and white
if you nned 100% secure defaults do not allow CGI and script interpreters
and go back to static sites because you have to realize that *any*
scripting lanuguage is a security risk per definition - period
On Mon, Aug 12, 2013 at 12:10 PM, George Machitidze gio...@gmail.com
mailto:gio...@gmail.com wrote:
Heh
disable_functions and open_basedir is bad example. It's not an apache
part - it's PHP, so forget about it -
it's a feature of PHP. enable_functions is a very bad idea - the list
of allowed ones would be too large for
any business, development or user needs. That's why administrators (I do)
read changelogs before upgrading
software, and why they check all the functions documented and all the
details regarding what these functions
do, this is PHP feature, not httpd feature or httpd bug. The question is
why PHP processes, forks etc running
under apache/cgi/etc are allowed to do anything what apache can do. This
is the issue right? If PHP has
security a bug, which allows to bypass these php.ini-related
security/sandboxing settings, it means we should
sacrifice security needs and trust PHP only? I need them both, where
possible. We can't even control and
isolate subprocesses with selinux, because for cgroups/selinux they share
same group and contexts. BTW, one
reminded me in here - itk mpm has workarounds for this problem.
http://mitka.us/articles/mpm-itk/
It's definitely not a bug, it's an architecture, which must be redesigned
sooner or later.
On Mon, Aug 12, 2013 at 9:28 PM, Coderaptor coderap...@gmail.com
mailto:coderap...@gmail.com wrote:
disable_functions
signature.asc
Description: OpenPGP digital signature
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 13.08.2013 00:51, schrieb coderaptor:
On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald h.rei...@thelounge.net wrote:
ALL software MUST come with SECURE DEFAULTS. PERIOD. Anyone who thinks
otherwise should fly in an aircraft running
his own designed software. Knowledgeable Admins are not an alternative to
secure defaults, rather I'd prefer both.
*define what is secure* and make sure you define it by context
unlink('file_my_script_wrote'); is fine
unlink($_GET['what_ever_input']): is a security hole
so do we now disable unlink();
Why not?
because it is plain stupid
you even statet that you did not realize that others are talking
about PHP and you not knew the context of 'disable_functions'
and so stop trying to be a smartass in topics you are clueless
hey in this case you need also to disable fopen(), file_put_contents()
and whatever function can open and overwrite a file - now you could
come and argue but the permissions should not allow - well, your
config should also not allow any random script to create symlinks
on a internal application which is not accesable from the web
symlink() is harmless and may be used for good reasons
so you should realize that security is not black and white
Go ahead and disable all 1330 functions if the need be, and let the
Administrator figure out which ones he should carefully enable
please stop making yourself *that* laughable
if you nned 100% secure defaults do not allow CGI and script interpreters
and go back to static sites because you have to realize that *any*
scripting lanuguage is a security risk per definition - period
Just for the sake of argument? Which sane framework provides 1330
functions? Security is surely not black and white, but this argument
should not justify poor design choices. Anyways, no matter what one
does, using a framework with 1330 functions is poor security decision
please be quite and come back after you understood the difference
between a programming language and a framework
hint:
* PHP: programming language
* Ruby:programming language
* Zend Framework, Symfony: Framework
* Ruboy On Rails: Framework
signature.asc
Description: OpenPGP digital signature
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 13.08.2013 00:42, schrieb Brandon M. Graves:
I hate to come late to the party, but following all of this, it is kind of
ridiculous.
I have to agree with those before in saying software should ship secure.
in my environment whenever we are given a new bit to add to our
infrastructure, be it a new server, new version of an OS, or new version
of a software, either A) it comes to us from those at our distribution
point pre templated to be unusable due to security, or B) we first make
it unusable by configuring every possible security setting to be as tight
as possible...
nobody said anything else
but Apache suEXEC privilege elevation is *not* a suEXEC
problem and that's the whole point - people in this thread
mixing a lot of different things partly with no clue
Am 13.08.2013 01:45, schrieb coderaptor:
On Mon, Aug 12, 2013 at 4:06 PM, Reindl Harald h.rei...@thelounge.net wrote:
unlink('file_my_script_wrote'); is fine
unlink($_GET['what_ever_input']): is a security hole
so do we now disable unlink();
Why not?
because it is plain stupid
You think so. Not everyone shares your opinion.
you know the quote from Dirty Harry about opinions?
you even statet that you did not realize that others are talking
about PHP and you not knew the context of 'disable_functions'
and so stop trying to be a smartass in topics you are clueless
Please no personal insults
truth != insult
Go ahead and disable all 1330 functions if the need be, and let the
Administrator figure out which ones he should carefully enable
please stop making yourself *that* laughable
I don't care.
i see
Just for the sake of argument? Which sane framework provides 1330
functions? Security is surely not black and white, but this argument
should not justify poor design choices. Anyways, no matter what one
does, using a framework with 1330 functions is poor security decision
please be quite and come back after you understood the difference
between a programming language and a framework
hint:
* PHP: programming language
* Ruby:programming language
* Zend Framework, Symfony: Framework
* Ruboy On Rails: Framework
Does it matter if I call at a framework, programming language, or
dancing donkey? It doesn't change the reality
yes, if you talk on a professional level you need to know
the basics if you like to be taken serious
signature.asc
Description: OpenPGP digital signature
Re: Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
In my opinion we got two problems about that. In some cases tools are user unfriendly. And a bit cryptic...but surely the sysadmin have to take care of it. the other question is: the human guilt. Let's assume that the problem is not Apache or PHP. If i shoot my foot with my gun...the problem is not the gun. Let's also assume that many people aren't not so smart and didn't like to read about or keep informed. Definetly they aren't sysadmin but...in many cases they work as well in this role. We are talking about security (aren't we?) so the first problem is the human element. ps PHP is a great scripting language, very useful and powerful but isn't used in a creative way at all. PHP only for web develompent? it's a real pity. -- marco floris
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
... ciao: : on 8-13-2013 Reindl Harald writ: : and so stop trying to be a smartass in topics you are clueless : : Please no personal insults : truth != insult it is perhaps just me, but when i see smartass in an otherwise reasoned dialogue, the TRUTH, is seldom if ever, my first thought. what is, is a weakness in position; either with the position taken, or an inability to handle the frustration of holding it. in addition, clueless as a delimiter, is not absolute in discussion. there are times, when expertise blinds its holder to an obvious but counter intuitive point of view. for example, i lay claim to being the icon of clueless when it comes to 'php'. i did however, NOTICE all the security problems showing up in regard to it. AND was able to figure out, it a RISK, no matter which 'webserver' it services. if i'd known more, i too, could have blamed apache ... ... it's not what you see , but in stead , notice ...
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Seems to me we have two positions that aren't that far apart but due to various reasons the conversation has devolved into something less worthy of a public discussion than most of what I see on Bugtraq. FWIW I'm in the camp of ship the software with secure defaults but at the same time I agree that Reindl makes a valid point when he asks what exactly one means by secure (even if I don't agree with his reasoning in this case). That said, the conversation has really taken an ugly turn, and I am humbly and only speaking for myself requesting that all concerned take some time to cool off, go for a walk (down to the pub if that helps), and come back with a focus more on the technical question at hand rather than the emotional response that has been rising to the top. Thanks, Mike
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Reindl Harald h.rei...@thelounge.net wrote:
Am 12.08.2013 23:32, schrieb coderaptor:
Why can't enable_functions be pre-populated with known good functions, and
everything else disabled? Again,
sacrificing security convenience is the norm.
if you would only have the slightest clue what you are speaking about
you would not ask that naive
[harry@srv-rhsoft:~]$ php -r print_r(get_defined_functions()); | wc -l
1330
oh, and they depend on the loaded extensions (inlcuding 3rd party extensions)
oh, and they *all* would have to be classified if, how and in which context
they all may or may not have a secuirity impact
That's one of the duties/tasks of their developer(s): WTFM!
ALL software MUST come with SECURE DEFAULTS. PERIOD. Anyone who thinks
otherwise should fly in an aircraft running
his own designed software. Knowledgeable Admins are not an alternative to
secure defaults, rather I'd prefer both.
*define what is secure* and make sure you define it by context
unlink('file_my_script_wrote'); is fine
No, its UNSAFE!
The standard use case of PHP is preprocessor for HTTP demon.
There is ABSOLUTELY no need to allow the preprocessor to unlink a file.
unlink($_GET['what_ever_input']): is a security hole
No, not necessarily. The user who can run
$ php -r unlink($_GET['what_ever_input']);
can also run
$ rm $SOMEFILE
OTOH: the user who can instruct his web browser to fetch
http://example.org/index.html is not able to unlink $SOMEFILE by
calling rm.
so do we now disable unlink();
Not WE, but the developer.
All functions which are not used in the typical operating
environment of the resp. program (see above) have to be turned
off by default. file handling is NONE of PHPs typical operations!
Stefan Kanthak
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 13.08.2013 21:36, schrieb Stefan Kanthak:
*define what is secure* and make sure you define it by context
unlink('file_my_script_wrote'); is fine
No, its UNSAFE!
The standard use case of PHP is preprocessor for HTTP demon.
There is ABSOLUTELY no need to allow the preprocessor to unlink a file.
come back to reality
the standard usecase of PHP is develop WEB-APPLICATIONS which are
typically deal with file-uploads and such things, you can whine
about it but *that is* the usecase of PHP
unlink($_GET['what_ever_input']): is a security hole
No, not necessarily. The user who can run
$ php -r unlink($_GET['what_ever_input']);
can also run
$ rm $SOMEFILE
if you would have a clue what are you speaking about you
would know what $_GET is - hint: it has nothing to do with a terminal
OTOH: the user who can instruct his web browser to fetch
http://example.org/index.html is not able to unlink $SOMEFILE by
calling rm.
wow - without you explaining the world that statically html pages
are safe we would go down - genius for that you do not need suEXEC,
perl, PHP or whatever at all
so do we now disable unlink();
Not WE, but the developer.
All functions which are not used in the typical operating
environment of the resp. program (see above) have to be turned
off by default. file handling is NONE of PHPs typical operations!
why do people which never wrote a serious web-application
not simply shut up in this thread?
signature.asc
Description: OpenPGP digital signature
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
unsubscribe On Aug 13, 2013, at 8:34 AM, Chris Meisinger chris.meisin...@centro.net wrote: unsubscribe On Aug 13, 2013, at 6:37 AM, terry white twh...@aniota.com wrote: ... ciao: : on 8-13-2013 Reindl Harald writ: : and so stop trying to be a smartass in topics you are clueless : : Please no personal insults : truth != insult it is perhaps just me, but when i see smartass in an otherwise reasoned dialogue, the TRUTH, is seldom if ever, my first thought. what is, is a weakness in position; either with the position taken, or an inability to handle the frustration of holding it. in addition, clueless as a delimiter, is not absolute in discussion. there are times, when expertise blinds its holder to an obvious but counter intuitive point of view. for example, i lay claim to being the icon of clueless when it comes to 'php'. i did however, NOTICE all the security problems showing up in regard to it. AND was able to figure out, it a RISK, no matter which 'webserver' it services. if i'd known more, i too, could have blamed apache ... ... it's not what you see , but in stead , notice ...
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Reindl Harald h.rei...@thelounge.net wrote: Am 10.08.2013 16:52, schrieb Tobias Kreidl: It is for this specific reason that utilities like suPHP can be used as a powerful tool to at least keep the account user from shooting anyone but him/herself in the foot because of any configuration or broken security issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a recipe for disaster. and what makes you believe that a developer can not be a seasoned, responsible admin? Because developers write functions like system, symlink and suexec which can create havoc (and are WELL-KNOWN for creating havoc since years) and allow everybody to call them in the default configuration of their software. bullshit, many of the seasoned, responsible admins which are only admins are unable to really understand the implications of whatever config they rollout It was the developer who created and published this vulnerable software or the vulnerable default configuration in the first place. If a user/administrator who installs software has to turn insecure features OFF its the developer who is to blame, and of course the testers, the QA and the management too. Stefan Kanthak
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Reindl Harald h.rei...@thelounge.net wrote: Am 11.08.2013 22:15, schrieb Stefan Kanthak: Reindl Harald h.rei...@thelounge.net wrote: Am 10.08.2013 16:52, schrieb Tobias Kreidl: It is for this specific reason that utilities like suPHP can be used as a powerful tool to at least keep the account user from shooting anyone but him/herself in the foot because of any configuration or broken security issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a recipe for disaster. and what makes you believe that a developer can not be a seasoned, responsible admin? Because developers write functions like system, symlink and suexec which can create havoc (and are WELL-KNOWN for creating havoc since years) and allow everybody to call them in the default configuration of their software. a so because some stupid developers all are faulty? If you say so: OK. Read again what I wrote, carefully! bullshit, many of the seasoned, responsible admins which are only admins are unable to really understand the implications of whatever config they rollout It was the developer who created and published this vulnerable software or the vulnerable default configuration in the first place. it was the admin who did not RTFM and rolled out default settings in environents with untrustable code JFTR: untrustable vulnerable! Read again what I wrote, carefully. If you'd have a clue you may have heard of concepts like fail safe or safe default configuration. ANY software with an insecure default configuration is DEFECTIVE! JFTR: why should gazillions of users/administrators fix the fault(s) of a single/few developer(s)? If a user/administrator who installs software has to turn insecure features OFF its the developer who is to blame, and of course the testers, the QA and the management too not entirely untrue, but anybody who thinks he can install whatever server-software with defaults, not RTFM and call hiself a serious admin is a fool Why not: I expect every developer to exercise all due diligence, test the code, and ship it with a SECURE default configuration. Software with an insecure default configuration is DEFECTIVE! 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! It's not the user/administrator who develops or ships insecure code! Stefan
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 11.08.2013 22:15, schrieb Stefan Kanthak: Reindl Harald h.rei...@thelounge.net wrote: Am 10.08.2013 16:52, schrieb Tobias Kreidl: It is for this specific reason that utilities like suPHP can be used as a powerful tool to at least keep the account user from shooting anyone but him/herself in the foot because of any configuration or broken security issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a recipe for disaster. and what makes you believe that a developer can not be a seasoned, responsible admin? Because developers write functions like system, symlink and suexec which can create havoc (and are WELL-KNOWN for creating havoc since years) and allow everybody to call them in the default configuration of their software. a so because some stupid developers all are faulty? bullshit, many of the seasoned, responsible admins which are only admins are unable to really understand the implications of whatever config they rollout It was the developer who created and published this vulnerable software or the vulnerable default configuration in the first place. it was the admin who did not RTFM and rolled out default settings in environents with untrustable code If a user/administrator who installs software has to turn insecure features OFF its the developer who is to blame, and of course the testers, the QA and the management too not entirely untrue, but anybody who thinks he can install whatever server-software with defaults, not RTFM and call hiself a serious admin is a fool 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 signature.asc Description: OpenPGP digital signature
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 11.08.2013 23:56, schrieb Stefan Kanthak: Reindl Harald h.rei...@thelounge.net 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 signature.asc Description: OpenPGP digital signature
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
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. 2. Apache clearly does not ship with secure defaults in favor of convenience? disable_functions is a example - do you expect an admin to be a unix expert or know what each parameter in there means? Also indicates this was added in reactively, and not accounted for in the core design. Why not enable_functions instead, with everything disabled to begin with? (Oh, that wouldn't help you achieve world dominance and fast!) 3. Secure by design, implementation, and deployment isn't utopia, it's very much an achievable target. But then it wouldn't feed bugtraq anymore or the billion dollar industry called as security industry would it? 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. -coderaptor -- sent via 100% recycled electrons from my mobile command center. On Aug 11, 2013, at 3:30 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.08.2013 23:56, schrieb Stefan Kanthak: Reindl Harald h.rei...@thelounge.net 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
RE: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
+1 PETER H GREGORY, C|CISO, CISA, CISSP, CRISC, PCI-ISA | Data Security Manager 428 Westlake Avenue North, Suite 388 | Seattle, WA 98109 peter.greg...@tommybahama.com | Skype peterhgregory | D: 206.905.5773 F: 206.905.5675 MAKE LIFE one LONG WEEKEND(tm) | TOMMYBAHAMA.COM -Original Message- From: Coderaptor [mailto:coderap...@gmail.com] Sent: Monday, August 12, 2013 10:28 AM To: Reindl Harald Cc: Stefan Kanthak; Tobias Kreidl; bugtraq@securityfocus.com Subject: Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure 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. 2. Apache clearly does not ship with secure defaults in favor of convenience? disable_functions is a example - do you expect an admin to be a unix expert or know what each parameter in there means? Also indicates this was added in reactively, and not accounted for in the core design. Why not enable_functions instead, with everything disabled to begin with? (Oh, that wouldn't help you achieve world dominance and fast!) 3. Secure by design, implementation, and deployment isn't utopia, it's very much an achievable target. But then it wouldn't feed bugtraq anymore or the billion dollar industry called as security industry would it? 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. -coderaptor -- sent via 100% recycled electrons from my mobile command center. On Aug 11, 2013, at 3:30 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.08.2013 23:56, schrieb Stefan Kanthak: Reindl Harald h.rei...@thelounge.net 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
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 12.08.2013 19:28, schrieb Coderaptor: I have been a silent spectator to this drama, and could not resist adding a few thoughts of my own: All software, especially webservers, should ship with secure defaults yes, but define secure defaults without a context hint: you can't It is a fundamental mistake to assume all admins who roll out web apps and maintain servers RTFM before rolling out it is a fundamental mistake not doing so and be admin 2. Apache clearly does not ship with secure defaults in favor of convenience? disable_functions is a example disable_functions has *nothing* to do with Apache because it is a php option apache itself *does not* create symlinks at all do you expect an admin to be a unix expert or know what each parameter in there means? *yes* *yes* and *yes* again Why not enable_functions instead, with everything disabled to begin with? (Oh, that wouldn't help you achieve world dominance and fast!) another example that people with no clue make proposals there you go: http://www.php.net/manual/en/funcref.php come on, list all functions except the one i listed *Again*: Apache does not create any symlink Apache does only *follow* so what should suExec do for you if you are refuse to understand what the different software-layers are supposed to do and why different layers exist at all and finally how to manage all of them? so disable follow symlinks in Apache or disable potential dangerous functions in scripting languages - and since Apache can not control any low level function a scripting language is using and symlinks are not the only dangerous thing you should do *both* or not play admin this thread is a good example that lazy admins are dreaming about rollout a powerful *and* secure service with default configurations and this naive attitude is only possible by beeing completly clueless, if one would understand the underlying tech he would no longer dream of flying horses On Aug 11, 2013, at 3:30 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.08.2013 23:56, schrieb Stefan Kanthak: Reindl Harald h.rei...@thelounge.net 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 signature.asc Description: OpenPGP digital signature
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Heh disable_functions and open_basedir is bad example. It's not an apache part - it's PHP, so forget about it - it's a feature of PHP. enable_functions is a very bad idea - the list of allowed ones would be too large for any business, development or user needs. That's why administrators (I do) read changelogs before upgrading software, and why they check all the functions documented and all the details regarding what these functions do, this is PHP feature, not httpd feature or httpd bug. The question is why PHP processes, forks etc running under apache/cgi/etc are allowed to do anything what apache can do. This is the issue right? If PHP has security a bug, which allows to bypass these php.ini-related security/sandboxing settings, it means we should sacrifice security needs and trust PHP only? I need them both, where possible. We can't even control and isolate subprocesses with selinux, because for cgroups/selinux they share same group and contexts. BTW, one reminded me in here - itk mpm has workarounds for this problem. http://mitka.us/articles/mpm-itk/ It's definitely not a bug, it's an architecture, which must be redesigned sooner or later. On Mon, Aug 12, 2013 at 9:28 PM, Coderaptor coderap...@gmail.com wrote: disable_functions Best regards, George Machitidze
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Mon, Aug 12, 2013 at 1:28 PM, Coderaptor coderap...@gmail.com 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 h.rei...@thelounge.net wrote: Am 11.08.2013 23:56, schrieb Stefan Kanthak: Reindl Harald h.rei...@thelounge.net 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
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
It is for this specific reason that utilities like suPHP can be used as a powerful tool to at least keep the account user from shooting anyone but him/herself in the foot because of any configuration or broken security issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a recipe for disaster. --Tobias On 8/10/2013 7:25 AM, Reindl Harald wrote: 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
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
... ciao: : on 8-10-2013 Gichuki John Chuksjonia writ: : most of the Admins who handle webservers : in a network are also developers name , just a few : most of the organizations will always need to cut on expenses, history suggests, security breaches, are NOT a profit center. : and as we know i'd prefer, that you not include me in that knowledge base. things like: : most of the developers will just look into finishing work and : making it work AND : So if something doesn't run due to httpd.conf, you will find these : guys loosening server security, therefore opening holes to the : infrastructure AND : From: guess who NotMyDomain @ gmail.com do not typically inspire confidence, or the illusion of a working knowledge about the subject at hand. on a parallel track. i'm a ham, WD0FPC, and every so often a new operator, sets about becoming an expert, offering their two cents worth. i am yet to see a case in which it didn't go one of three ways; (a) left the hobby, (b) became an operator worthy of license class, and (c), didn't. computing, and amateur radio, both the classic 'community', with knowledge as lifeblood, and the willingness to help its life energy. in some schools of thought, both individually, and collectively, a deserved respect inherent. solidified ignorance, flawed assumptions, and faulty logic, able to ignore all that. for a while ... -- ... it's not what you see , but in stead , notice ...
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 10.08.2013 16:52, schrieb Tobias Kreidl: It is for this specific reason that utilities like suPHP can be used as a powerful tool to at least keep the account user from shooting anyone but him/herself in the foot because of any configuration or broken security issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a recipe for disaster. and what makes you believe that a developer can not be a seasoned, responsible admin? bullshit, many of the seasoned, responsible admins which are only admins are unable to really understand the implications of whatever config they rollout On 8/10/2013 7:25 AM, Reindl Harald wrote: 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 -- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / CISO / Software-Development m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On 2013-08-11 Reindl Harald wrote: Am 10.08.2013 16:52, schrieb Tobias Kreidl: It is for this specific reason that utilities like suPHP can be used as a powerful tool to at least keep the account user from shooting anyone but him/herself in the foot because of any configuration or broken security issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a recipe for disaster. and what makes you believe that a developer can not be a seasoned, responsible admin? Most developers I have met would focus on getting new features to work rather than secure/reliable operation of the deployed software. bullshit, many of the seasoned, responsible admins which are only admins are unable to really understand the implications of whatever config they rollout Apparently you still haven't learned your lesson from being banned from the postfix-users mailing list. Regards Ansgar Wiechers -- All vulnerabilities deserve a public fear period prior to patches becoming available. --Jason Coombs on Bugtraq
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
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 11.08.2013 14:50, schrieb Ansgar Wiechers: On 2013-08-11 Reindl Harald wrote: Am 10.08.2013 16:52, schrieb Tobias Kreidl: It is for this specific reason that utilities like suPHP can be used as a powerful tool to at least keep the account user from shooting anyone but him/herself in the foot because of any configuration or broken security issues. Allowing suexec to anyone but a seasoned, responsible admin is IMO a recipe for disaster. and what makes you believe that a developer can not be a seasoned, responsible admin? Most developers I have met would focus on getting new features to work rather than secure/reliable operation of the deployed software maybe you met the wrong ones on the other hand most admins i met did not use disallow_functions a responsilble developer which is at the same time admin has the knowledge not using dangerous functions and disables them one config line and the whole topic would be obsolete by not allowing symlinks from web-applications disable_functions = popen, pclose, 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 bullshit, many of the seasoned, responsible admins which are only admins are unable to really understand the implications of whatever config they rollout Apparently you still haven't learned your lesson from being banned from the postfix-users mailing list oh i forgot, in the enlish speaking world in have to write clould i ask you please could consider to think about signature.asc Description: OpenPGP digital signature
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Agreed. Many sites limit users to at most SymLinksIfOwnerMatch for that very reason, not to mention limits on CGI privileges. AllowSymlinks, IMO, ought to be reserved for the sysadmin on the server and used sparingly. You can, of course, even require .htaccess configurations to be set in the server's configuration files instead of in the user account areas (in conjunction with the AllowOverride None setting). --Tobias On 8/11/2013 7:52 AM, Michal Zalewski wrote: 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
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 isowarez.isowarez.isowa...@googlemail.com wrote: Uhh Hit em with a little Ghetto Gospel So am i less holy Because i Puff a blunt and Drink a Beer with my homies? Theres no Need for you to fear me if you Take your Time and Hear me Maybe you can learn to cheer me. It aint about Black and white cause we Human !!! Lord can you Hear me speaaak!! http://rapgenius.com/2pac-ghetto-gospel-lyrics Am 09.08.2013 um 16:33 schrieb Kingcope isowarez.isowarez.isowa...@googlemail.com: So the blackhat that Sits on ur Site and the site of ur company Since half a year will stop at the point Where its technically incorrect and wont escalate to root because it doesnt have to do Anything with suexec. Its an Old vuln so let it stay , better for us and soon our Data on your boxes. Time to Write a Real Root exploit and dont waste the Time with sysadmins that know how to set a flag in httpd.conf , apache devs included. Am 09.08.2013 um 14:29 schrieb Kingcope isowarez.isowarez.isowa...@googlemail.com: So what your Emails Tell me is better ignore this vulnerability. I dont Claim its a High severity Bug but if you Tell People to ignore it Because it isnt a vulnerability you are very much aiding the Chaos of insecurity in the Internet today. You Maybe have a Secure Setting but theres only you on the Planet. Attackers Look specifically for such Bugs to Open Servers. No Wonder we have compromises in a High Scale every Day due to this ignorance. My rant on that One. Am 07.08.2013 um 21:49 schrieb king cope isowarez.isowarez.isowa...@googlemail.com: Apache suEXEC privilege elevation / information disclosure Discovered by Kingcope/Aug 2013 The suEXEC feature provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server. Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. With this bug an attacker who is able to run php or cgi code inside a web hosting environment and the environment is configured to use suEXEC as a protection mechanism, he/she is able to read any file and directory on the file- system of the UNIX/Linux system with the user and group id of the apache web server. Normally php and cgi scripts are not allowed to read files with the apache user- id inside a suEXEC configured environment. Take for example this apache owned file and the php script that follows. $ ls -la /etc/testapache -rw--- 1 www-data www-data 36 Aug 7 16:28 /etc/testapache only user www-data should be able to read this file. $ cat test.php ?php system(id; cat /etc/testapache); ? When calling the php file using a webbrowser it will show... uid=1002(example) gid=1002(example) groups=1002(example) because the php script is run trough suEXEC. The script will not output the file requested because of a permissions error. Now if we create a .htaccess file with the content... Options Indexes FollowSymLinks and a php script with the content... ?php system(ln -sf / test99.php); symlink(/, test99.php); // try builtin function in case when //system() is blocked ? in the same folder ..we can access the root filesystem with the apache uid,gid by requesting test99.php. The above php script will simply create a symbolic link to '/'. A request to test99.php/etc/testapache done with a web browser shows.. voila! read with the apache uid/gid The reason we can now read out any files and traverse directories owned by the apache user is because apache httpd displays symlinks and directory listings without querying suEXEC. It is not possible to write to files in this case. Version notes. Assumed is that all Apache versions are affected by this bug. apache2 -V Server version: Apache/2.2.22 (Debian) Server built: Mar 4 2013 21:32:32 Server's Module Magic Number: 20051115:30 Server loaded: APR 1.4.6, APR-Util 1.4.1 Compiled using: APR 1.4.6, APR-Util 1.4.1 Architecture: 32-bit Server MPM: Worker threaded: yes (fixed thread count) forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR=server/mpm/worker -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Sat, Aug 10, 2013 at 6:10 AM, Gichuki John Chuksjonia chuksjo...@gmail.com 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
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
Re: Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
This is in no way an exploit. Apache behaviour is as expected. When an user has the ability to activate FollowSymlinks and to create symlinks - than this is the fault of the systems operator. In no way has this anything to do with suEXEC. suEXEC *does not* disallow read access via HTTP requests to files owned by www-data. Everybody should know that only the cgi/php/whatever scripts are run as configured the suexec uid/gid but apache serving static files are read via www-data user. Creating a symlink named 'test99.php' only adds confusion but has nothing to do with the fact that there is no exploit.
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
