BugTraq
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 12 2013 11:45PM
coderaptor (coderaptor gmail com) (2 replies)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 13 2013 12:29PM
Matthew Caron (Matt Caron redlion net)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 13 2013 07:55AM
Reindl Harald (h reindl thelounge net) (3 replies)
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.reindl (at) thelounge (dot) net [email concealed]> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIJ5mMACgkQhmBjz394AnkqMQCeI3sFmG8U9aG7pfJDxmWgoCkS
ABcAn1fFDd2/NhjpL/LEX/rikBclH0rY
=LSwX
-----END PGP SIGNATURE-----

[ reply ]
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 13 2013 12:11PM
James Birk (jamesbirk gmail com)


 

Privacy Statement
Copyright 2010, SecurityFocus