lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 12 Aug 2013 16:45:10 -0700
From: coderaptor <coderaptor@...il.com>
To: Reindl Harald <h.reindl@...lounge.net>
Cc: "bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure

On Mon, Aug 12, 2013 at 4:06 PM, Reindl Harald <h.reindl@...lounge.net> wrote:
>
> Am 13.08.2013 00:51, schrieb coderaptor:
>> On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald <h.reindl@...lounge.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

Powered by blists - more mailing lists