Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
unsubscribe On Aug 13, 2013, at 8:34 AM, Chris Meisinger wrote: > unsubscribe > > On Aug 13, 2013, at 6:37 AM, terry white 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
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
> 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
"Reindl Harald" 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
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
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
unsubscribe On Aug 13, 2013, at 6:37 AM, terry white 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
On 08/12/2013 07:45 PM, coderaptor wrote: 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), Or, one which has a very rich featureset which doesn't require folks to reinvent the wheel every time they want to read in a bitmap. That said, PHP sucks for other reasons, most notably the inability to force variable predeclaration (ie perl's "use strict")*, but I wanted to specifically address your criticism of a language having "too many functions". * Assuming this is still true. It was back in 2008 when I quit my web job and went back into firmware, and I haven't been doing much with PHP since, instead focusing on C and D on ARM and PPC, so this may have been remedied. 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 don't see why you need to demonstrate that PHP sucks to justify this position. Compartmentalization is generally a good idea - feel free to practice more of it, as long as you can live with the limitations of doing so. There are also lightweight kernel-level virtualization approaches (linux containers (lxc), Solaris containers, and BSD jails (not to be confused with chroot jails)), which provide even better segregation than a mere chroot. -- Matthew Caron, Software Build Engineer Sixnet, a Red Lion business | www.sixnet.com +1 (518) 877-5173 x138 office
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Aug 13, 2013, at 3:55 AM, Reindl Harald wrote: > 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 Precisely. This entire thread is filled with people who not only do not know how Apache works, but how Bugtraq works either. That said, this issue is of course not a bug, but a feature-- a feature which if used, opens a mild to moderate vulnerability which can be corrected on the substrate in any number of ways. So y'all need to sit down. James.
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: 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
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 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: [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 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 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 > wrote:
>
> Heh
>
> disable_functions and open_basedir is bad example. It's not an apache
> part - it's PHP, so forget about it -
> . 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 > wrote:
>
> disable_functions
signature.asc
Description: OpenPGP digital signature
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Mon, Aug 12, 2013 at 4:06 PM, Reindl Harald wrote:
>
> Am 13.08.2013 00:51, schrieb coderaptor:
>> On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald
>> 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
On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald 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 > > wrote:
>>
>> Heh
>>
>> disable_functions and open_basedir is bad example. It's not an apache
>> part - it's PHP, so forget about it -
>> . 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 > > wrote:
>>
>> disable_functions
>
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 >> wrote: >>> Am 11.08.2013 23:56, schrieb Stefan Kanthak: "Reindl Harald" wrote: > again: > symlinks are to not poision always and everywhere > they become where untrusted customer code is running > blame the admin which doe snot know his job and not > the language offering a lot of functions where some > can be misused Again: symlinks are well-known as attack vector fo
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Mon, Aug 12, 2013 at 11:11 AM, Reindl Harald 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 wrote: > >> Am 11.08.2013 23:56, schrieb Stefan Kanthak: > >>> "Reindl Harald" wrote: > again: > symlinks are to not poision always and everywhere > they become where untrusted customer code is running > blame the admin which doe snot know his job and not > the language offering a lot of functions where some > can be misused > >>> > >>> Again: symlinks are well-known as attack vector for years! > >> > >> and that's why any admin which is not clueless > >> disables the symlink function - but there exists > >> code which *is* secure, runs in a crontrolled > >> environment and make use of it for good reasons > >> > >>> It's not the user/administrator who develops or ships insecure code! > >> > >> but it's the administrator which has the wrong job if > >> create symlinks is possible from any random script > >> running on his servers > >> > >> anyways, i am done with this thread > >> > >> the topic is *not* "Apache suEXEC privilege elevation" it > >> is "admins not secure their servers" - period >
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Mon, Aug 12, 2013 at 1:28 PM, Coderaptor wrote: > I have been a silent spectator to this drama, and could not resist adding a > few thoughts of my own: > > 1. All software, especially webservers, should ship with secure defaults. > Period. It is a fundamental mistake to assume all admins who roll out web > apps and maintain servers RTFM before rolling out. The key idea here is "time > to market", and there is huge amount of data to prove this. > +1. All software should be shipped "secure out of the box". Its amazing so many folks keep making the same mistakes from the 1980s and 1990s. > ... > Huge amount of software today is turd polishing, open source no exception > (though it is supposed to have better track record). The blame lies squarely > on everyone. > The "more eyes the better" theory is hogwash. I cringe when I hear anyone discussing the security of crowd sourcing. There's two problems with their arguments: first is Cognitive Biases, and second is the Bystander Effect. The biases are being demonstrated by NB and RH, and its results are typical (no offense NB and RH). The Bystander Effect ensures that the more people see a bug, the less likely they are going to do anything about it because they believe someone else has already done something. They are well known problems in Security Engineering. See Peter Gutmann's Engineering Security (www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf) or Ross Anderson's Security Engineering (http://www.cl.cam.ac.uk/~rja14/book.html). Jeff > On Aug 11, 2013, at 3:30 PM, Reindl Harald wrote: > >> Am 11.08.2013 23:56, schrieb Stefan Kanthak: >>> "Reindl Harald" wrote: again: symlinks are to not poision always and everywhere they become where untrusted customer code is running blame the admin which doe snot know his job and not the language offering a lot of functions where some can be misused >>> >>> Again: symlinks are well-known as attack vector for years! >> >> and that's why any admin which is not clueless >> disables the symlink function - but there exists >> code which *is* secure, runs in a crontrolled >> environment and make use of it for good reasons >> >>> It's not the user/administrator who develops or ships insecure code! >> >> but it's the administrator which has the wrong job if >> create symlinks is possible from any random script >> running on his servers >> >> anyways, i am done with this thread >> >> the topic is *not* "Apache suEXEC privilege elevation" it >> is "admins not secure their servers" - period >> >>
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 - . 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 wrote: > > disable_functions Best regards, George Machitidze
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 wrote: >> Am 11.08.2013 23:56, schrieb Stefan Kanthak: >>> "Reindl Harald" wrote: again: symlinks are to not poision always and everywhere they become where untrusted customer code is running blame the admin which doe snot know his job and not the language offering a lot of functions where some can be misused >>> >>> Again: symlinks are well-known as attack vector for years! >> >> and that's why any admin which is not clueless >> disables the symlink function - but there exists >> code which *is* secure, runs in a crontrolled >> environment and make use of it for good reasons >> >>> It's not the user/administrator who develops or ships insecure code! >> >> but it's the administrator which has the wrong job if >> create symlinks is possible from any random script >> running on his servers >> >> anyways, i am done with this thread >> >> the topic is *not* "Apache suEXEC privilege elevation" it >> is "admins not secure their servers" - period signature.asc Description: OpenPGP digital signature
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 wrote: > > > Am 11.08.2013 23:56, schrieb Stefan Kanthak: >> "Reindl Harald" wrote: >>> again: >>> symlinks are to not poision always and everywhere they become where >>> untrusted customer code is running blame the admin which doe snot >>> know his job and not the language offering a lot of functions where >>> some can be misused >> >> Again: symlinks are well-known as attack vector for years! > > and that's why any admin which is not clueless disables the symlink > function - but there exists code which *is* secure, runs in a > crontrolled environment and make use of it for good reasons > >> It's not the user/administrator who develops or ships insecure code! > > but it's the administrator which has the wrong job if create symlinks > is possible from any random script running on his servers > > anyways, i am done with this thread > > the topic is *not* "Apache suEXEC privilege elevation" it is "admins > not secure their servers" - period > >
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 wrote: > > > Am 11.08.2013 23:56, schrieb Stefan Kanthak: >> "Reindl Harald" wrote: >>> again: >>> symlinks are to not poision always and everywhere >>> they become where untrusted customer code is running >>> blame the admin which doe snot know his job and not >>> the language offering a lot of functions where some >>> can be misused >> >> Again: symlinks are well-known as attack vector for years! > > and that's why any admin which is not clueless > disables the symlink function - but there exists > code which *is* secure, runs in a crontrolled > environment and make use of it for good reasons > >> It's not the user/administrator who develops or ships insecure code! > > but it's the administrator which has the wrong job if > create symlinks is possible from any random script > running on his servers > > anyways, i am done with this thread > > the topic is *not* "Apache suEXEC privilege elevation" it > is "admins not secure their servers" - period > >
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 11.08.2013 23:56, schrieb Stefan Kanthak: > "Reindl Harald" wrote: >> again: >> symlinks are to not poision always and everywhere >> they become where untrusted customer code is running >> blame the admin which doe snot know his job and not >> the language offering a lot of functions where some >> can be misused > > Again: symlinks are well-known as attack vector for years! and that's why any admin which is not clueless disables the symlink function - but there exists code which *is* secure, runs in a crontrolled environment and make use of it for good reasons > It's not the user/administrator who develops or ships insecure code! but it's the administrator which has the wrong job if create symlinks is possible from any random script running on his servers anyways, i am done with this thread the topic is *not* "Apache suEXEC privilege elevation" it is "admins not secure their servers" - period signature.asc Description: OpenPGP digital signature
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
Am 11.08.2013 22:15, schrieb Stefan Kanthak: > "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"? > > 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
"Reindl Harald" wrote: > Am 11.08.2013 22:15, schrieb Stefan Kanthak: >> "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"? >> >> 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
"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"? 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
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
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
> 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
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
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
... 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
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
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: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
On Sat, Aug 10, 2013 at 6:10 AM, Gichuki John Chuksjonia wrote: > One thing u gotta remember most of the Admins who handle webservers in > a network are also developers since most of the organizations will > always need to cut on expenses, and as we know, most of the developers > will just look into finishing work and making it work. So if something > doesn't run due to httpd.conf, you will find these guys loosening > server security, therefore opening holes to the infrastructure. Cognitive Bias and Dissonance are well known problems in security engineering. NB's comments are a testament to the disconnect between the creators of the system and the users of the system. (No offense to NB). See, for example, Peter Gutmann's Engineering Security (www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf) or Ross Anderson's Security Engineering (http://www.cl.cam.ac.uk/~rja14/book.html). Jeff
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
One thing u gotta remember most of the Admins who handle webservers in
a network are also developers since most of the organizations will
always need to cut on expenses, and as we know, most of the developers
will just look into finishing work and making it work. So if something
doesn't run due to httpd.conf, you will find these guys loosening
server security, therefore opening holes to the infrastructure.
Just my two cents
./Chucks
On 8/10/13, Kingcope wrote:
> Uhh Hit em with a little Ghetto Gospel
>
> So am i less holy Because i Puff a blunt and Drink a Beer with my homies?
>
> Theres no Need for you to fear me if you Take your Time and Hear me Maybe
> you can learn to cheer me.
> It aint about Black and white cause we Human !!!
> Lord can you Hear me speaaak!!
> http://rapgenius.com/2pac-ghetto-gospel-lyrics
>
> Am 09.08.2013 um 16:33 schrieb Kingcope
> :
>
>> So the blackhat that Sits on ur Site and the site of ur company Since half
>> a year will stop at the point Where its "technically incorrect" and wont
>> escalate to root because "it doesnt have to do Anything with suexec". Its
>> an Old vuln so let it stay , better for us and soon our Data on your
>> boxes.
>>
>> Time to Write a Real Root exploit and dont waste the Time with sysadmins
>> that know how to set a flag in httpd.conf , apache devs included.
>>
>> Am 09.08.2013 um 14:29 schrieb Kingcope
>> :
>>
>>> So what your Emails Tell me is better ignore this vulnerability. I dont
>>> Claim its a High severity Bug but if you Tell People to ignore it Because
>>> it isnt a vulnerability you are very much aiding the Chaos of insecurity
>>> in the Internet today. You Maybe have a Secure Setting but theres only
>>> you on the Planet. Attackers Look specifically for such Bugs to Open
>>> Servers. No Wonder we have compromises in a High Scale every Day due to
>>> this ignorance. My rant on that One.
>>>
>>> Am 07.08.2013 um 21:49 schrieb king cope
>>> :
>>>
Apache suEXEC privilege elevation / information disclosure
Discovered by Kingcope/Aug 2013
The suEXEC feature provides Apache users the ability to run CGI and SSI
programs
under user IDs different from the user ID of the calling web server.
Normally,
when a CGI or SSI program executes, it runs as the same user who is
running the
web server.
Used properly, this feature can reduce considerably the security risks
involved
with allowing users to develop and run private CGI or SSI programs.
With this bug an attacker who is able to run php or cgi code inside a
web
hosting environment and the environment is configured to use suEXEC as
a
protection mechanism, he/she is able to read any file and directory on
the file-
system of the UNIX/Linux system with the user and group id of the
apache web server.
Normally php and cgi scripts are not allowed to read files with the
apache user-
id inside a suEXEC configured environment.
Take for example this apache owned file and the php script that
follows.
$ ls -la /etc/testapache
-rw--- 1 www-data www-data 36 Aug 7 16:28 /etc/testapache
only user www-data should be able to read this file.
$ cat test.php
>>> system("id; cat /etc/testapache");
?>
When calling the php file using a webbrowser it will show...
uid=1002(example) gid=1002(example) groups=1002(example)
because the php script is run trough suEXEC.
The script will not output the file requested because of a permissions
error.
Now if we create a .htaccess file with the content...
Options Indexes FollowSymLinks
and a php script with the content...
>>> system("ln -sf / test99.php");
symlink("/", "test99.php"); // try builtin function in case when
//system() is blocked
?>
in the same folder
..we can access the root filesystem with the apache uid,gid by
requesting test99.php.
The above php script will simply create a symbolic link to '/'.
A request to test99.php/etc/testapache done with a web browser shows..
voila! read with the apache uid/gid
The reason we can now read out any files and traverse directories owned
by the
apache user is because apache httpd displays symlinks and directory
listings
without querying suEXEC.
It is not possible to write to files in this case.
Version notes. Assumed is that all Apache versions are affected by this
bug.
apache2 -V
Server version: Apache/2.2.22 (Debian)
Server built: Mar 4 2013 21:32:32
Server's Module Magic Number: 20051115:30
Server loaded: APR 1.4.6, APR-Util 1.4.1
Compiled using: APR 1.4.6, APR-Util 1.4.1
Architecture: 32-bit
Server MPM: Worker
threaded: yes (fixed thread count)
Re: 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
