mailing list archives
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure
From: coderaptor <coderaptor () gmail com>
Date: Mon, 12 Aug 2013 16:45:10 -0700
On Mon, Aug 12, 2013 at 4:06 PM, Reindl Harald <h.reindl () thelounge net> wrote:
Am 13.08.2013 00:51, schrieb coderaptor:
On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald <h.reindl () 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();
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
* 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.