On Mon, Aug 12, 2013 at 11:11 AM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote: > > 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 Oh, a practical context can very well be established. We aren't talking about formal methods are we? > > 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 Agree. However, the vast amount of data shows otherwise. Its easy to have reasonable secure defaults than expect knowledgeable admins, IMO. > > 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 My bad. PHP it is. Well, PHP design is broken then. > > do you expect an admin to be a unix expert or know what each parameter in there means? > > *yes* *yes* and *yes* again *cough* *cough*. Ideally, yes. Practically, no. > > 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 That's a sad fact. And it is compounded by poorly written framework, and software. I am depressed, we are doomed. Now, where is my coffee? -coderaptor > > > On Aug 11, 2013, at 3:30 PM, Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote: > >> Am 11.08.2013 23:56, schrieb Stefan Kanthak: > >>> "Reindl Harald" <h.reindl@xxxxxxxxxxxxx> 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 >
