BugTraq
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 10 2013 02:52PM
Tobias Kreidl (tobias kreidl nau edu) (1 replies)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 11 2013 10:44AM
Reindl Harald (h reindl thelounge net) (2 replies)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 11 2013 08:15PM
Stefan Kanthak (stefan kanthak nexgo de) (1 replies)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 11 2013 08:53PM
Reindl Harald (h reindl thelounge net) (1 replies)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 11 2013 09:56PM
Stefan Kanthak (stefan kanthak nexgo de) (1 replies)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 11 2013 10:30PM
Reindl Harald (h reindl thelounge net) (1 replies)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 12 2013 05:28PM
Coderaptor (coderaptor gmail com) (3 replies)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 12 2013 07:03PM
Jeffrey Walton (noloader gmail com)
RE: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 12 2013 06:56PM
Peter Gregory (Peter Gregory tommybahama com)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 12 2013 06:11PM
Reindl Harald (h reindl thelounge net) (3 replies)


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 <h.reindl (at) thelounge (dot) net [email concealed]> wrote:
>> Am 11.08.2013 23:56, schrieb Stefan Kanthak:
>>> "Reindl Harald" <h.reindl (at) thelounge (dot) net [email concealed]> 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

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

iEYEARECAAYFAlIJJUoACgkQhmBjz394AnnHxQCeMhhXM91J8TrKjsYA2y4JXFZx
77QAnihclwXSN/+OszEctHMJ05MAor7a
=5Sbw
-----END PGP SIGNATURE-----

[ reply ]
Re: Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 13 2013 10:26AM
Marco Floris (marco floris jaimeria org)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 12 2013 10:42PM
Brandon M. Graves (bgraves slicer-net com)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 12 2013 09:39PM
coderaptor (coderaptor gmail com)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 11 2013 12:50PM
Ansgar Wiechers (bugtraq planetcobalt net) (1 replies)
Re: [Full-disclosure] Apache suEXEC privilege elevation / information disclosure Aug 11 2013 03:39PM
Reindl Harald (h reindl thelounge net)


 

Privacy Statement
Copyright 2010, SecurityFocus