Home page logo
/

bugtraq logo Bugtraq 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();

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault