unsubscribe
On Aug 13, 2013, at 8:34 AM, Chris Meisinger wrote:
> unsubscribe
>
> On Aug 13, 2013, at 6:37 AM, terry white wrote:
>
>>
>> ... ciao:
>>
>> : on "8-13-2013" "Reindl Harald" writ:
>> : >> and so stop trying to be a smartass in topics you are clueless
>> : >
>> : > Please no per
Am 13.08.2013 21:36, schrieb Stefan Kanthak:
>> *define what is secure* and make sure you define it by context
>>
>> unlink('file_my_script_wrote'); is fine
>
> No, its UNSAFE!
> The standard use case of PHP is "preprocessor for HTTP demon".
> There is ABSOLUTELY no need to allow the preprocesso
"Reindl Harald" wrote:
> Am 12.08.2013 23:32, schrieb coderaptor:
>> Why can't enable_functions be pre-populated with known good functions, and
>> everything else disabled? Again,
>> sacrificing security convenience is the norm.
>
> if you would only have the slightest clue what you are speaking
Seems to me we have two positions that aren't that far apart but due to various
reasons the conversation has devolved into something less worthy of a public
discussion than most of what I see on Bugtraq. FWIW I'm in the camp of "ship
the software with secure defaults" but at the same time I agr
unsubscribe
On Aug 13, 2013, at 6:37 AM, terry white wrote:
>
> ... ciao:
>
> : on "8-13-2013" "Reindl Harald" writ:
> : >> and so stop trying to be a smartass in topics you are clueless
> : >
> : > Please no personal insults
>
> : truth != insult
>
> it is perhaps just me, but when i see
On 08/12/2013 07:45 PM, coderaptor wrote:
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),
Or, one which has a very rich featureset which doesn't require
On Aug 13, 2013, at 3:55 AM, Reindl Harald wrote:
> 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 wh
... ciao:
: on "8-13-2013" "Reindl Harald" writ:
: >> and so stop trying to be a smartass in topics you are clueless
: >
: > Please no personal insults
: truth != insult
it is perhaps just me, but when i see "smartass" in an otherwise
reasoned dialogue, "the TRUTH", is seldom if ever, my fi
In my opinion we got two problems about that.
In some cases tools are user unfriendly. And a bit cryptic...but surely the
sysadmin have to take care of it.
the other question is: the human guilt. Let's assume that the problem is not
Apache or PHP. If i shoot my foot with my gun...the problem is
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
Am 13.08.2013 00:51, schrieb coderaptor:
> On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald 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 t
Am 12.08.2013 23:32, schrieb coderaptor:
> Why can't enable_functions be pre-populated with known good functions, and
> everything else disabled? Again,
> sacrificing security convenience is the norm.
if you would only have the slightest clue what you are speaking about
you would not ask that n
On Mon, Aug 12, 2013 at 4:06 PM, Reindl Harald wrote:
>
> Am 13.08.2013 00:51, schrieb coderaptor:
>> On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald
>> wrote:
ALL software MUST come with SECURE DEFAULTS. PERIOD. Anyone who thinks
otherwise should fly in an aircraft running
his ow
On Mon, Aug 12, 2013 at 2:45 PM, Reindl Harald wrote:
>
> Am 12.08.2013 23:32, schrieb coderaptor:
>> Why can't enable_functions be pre-populated with known good functions, and
>> everything else disabled? Again,
>> sacrificing security convenience is the norm.
>
> if you would only have the slig
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
On Mon, Aug 12, 2013 at 11:11 AM, Reindl Harald 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 de
On Mon, Aug 12, 2013 at 1:28 PM, Coderaptor wrote:
> I have been a silent spectator to this drama, and could not resist adding a
> few thoughts of my own:
>
> 1. All software, especially webservers, should ship with secure defaults.
> Period. It is a fundamental mistake to assume all admins who
Heh
disable_functions and open_basedir is bad example. It's not an apache
part - it's PHP, so forget about it - .
enable_functions is a very bad idea - the list of allowed ones would
be too large for any business, development or user needs. That's why
administrators (I do) read changelogs before u
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 f
-
From: Coderaptor [mailto:coderap...@gmail.com]
Sent: Monday, August 12, 2013 10:28 AM
To: Reindl Harald
Cc: Stefan Kanthak; Tobias Kreidl; bugtraq@securityfocus.com
Subject: Re: [Full-disclosure] Apache suEXEC privilege elevation /
information disclosure
I have been a silent spectator to this
I have been a silent spectator to this drama, and could not resist adding a few
thoughts of my own:
1. All software, especially webservers, should ship with secure defaults.
Period. It is a fundamental mistake to assume all admins who roll out web apps
and maintain servers RTFM before rolling o
Am 11.08.2013 23:56, schrieb Stefan Kanthak:
> "Reindl Harald" 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 so
Am 11.08.2013 22:15, schrieb Stefan Kanthak:
> "Reindl Harald" wrote:
>> Am 10.08.2013 16:52, schrieb Tobias Kreidl:
>>> It is for this specific reason that utilities like suPHP can be used as a
>>> powerful tool to at least keep the
>>> account user from shooting anyone but him/herself in the
"Reindl Harald" wrote:
> Am 11.08.2013 22:15, schrieb Stefan Kanthak:
>> "Reindl Harald" wrote:
>>> Am 10.08.2013 16:52, schrieb Tobias Kreidl:
It is for this specific reason that utilities like suPHP can be used as a
powerful tool to at least keep the
account user from shooting
"Reindl Harald" wrote:
> Am 10.08.2013 16:52, schrieb Tobias Kreidl:
>> It is for this specific reason that utilities like suPHP can be used as a
>> powerful tool to at least keep the
>> account user from shooting anyone but him/herself in the foot because of any
>> configuration or broken secu
Agreed. Many sites limit users to at most SymLinksIfOwnerMatch for that
very reason, not to mention limits on CGI privileges. AllowSymlinks,
IMO, ought to be reserved for the sysadmin on the server and used
sparingly. You can, of course, even require .htaccess configurations to
be set in the s
Am 11.08.2013 14:50, schrieb Ansgar Wiechers:
> On 2013-08-11 Reindl Harald wrote:
>> Am 10.08.2013 16:52, schrieb Tobias Kreidl:
>>> It is for this specific reason that utilities like suPHP can be used
>>> as a powerful tool to at least keep the account user from shooting
>>> anyone but him/hers
> for doing this features in httpd.conf you can use AllowOverride None instead
> of AllowOverride all
AllowSymlinks is a red herring here (hardlinks should do, unless you
have stuff partitioned in a very thoughtful way, which most don't),
similarly to suexec.
In general, sharing web hosting provi
On 2013-08-11 Reindl Harald wrote:
> Am 10.08.2013 16:52, schrieb Tobias Kreidl:
>> It is for this specific reason that utilities like suPHP can be used
>> as a powerful tool to at least keep the account user from shooting
>> anyone but him/herself in the foot because of any configuration or
>> bro
Am 10.08.2013 16:52, schrieb Tobias Kreidl:
> It is for this specific reason that utilities like suPHP can be used as a
> powerful tool to at least keep the
> account user from shooting anyone but him/herself in the foot because of any
> configuration or broken security
> issues. Allowing suexe
... ciao:
: on "8-10-2013" "Gichuki John Chuksjonia" writ:
: most of the Admins who handle webservers
: in a network are also developers
name , just a "few"
: most of the organizations will always need to cut on expenses,
history suggests, security breaches, are NOT a profit cente
It is for this specific reason that utilities like suPHP can be used as
a powerful tool to at least keep the account user from shooting anyone
but him/herself in the foot because of any configuration or broken
security issues. Allowing suexec to anyone but a seasoned, responsible
admin is IMO a
Am 10.08.2013 12:10, schrieb Gichuki John Chuksjonia:
> One thing u gotta remember most of the Admins who handle webservers in
> a network are also developers since most of the organizations will
> always need to cut on expenses, and as we know, most of the developers
> will just look into finish
On Sat, Aug 10, 2013 at 6:10 AM, Gichuki John Chuksjonia
wrote:
> One thing u gotta remember most of the Admins who handle webservers in
> a network are also developers since most of the organizations will
> always need to cut on expenses, and as we know, most of the developers
> will just look in
One thing u gotta remember most of the Admins who handle webservers in
a network are also developers since most of the organizations will
always need to cut on expenses, and as we know, most of the developers
will just look into finishing work and making it work. So if something
doesn't run due to
This is in no way an exploit.
Apache behaviour is as expected.
When an user has the ability to activate FollowSymlinks and to create symlinks
- than this is the fault of the systems operator.
In no way has this anything to do with suEXEC.
suEXEC *does not* disallow read access via HTTP request
hi...
I posted the advisory to make administratos aware that it will be
still possible to read files with the apache uid even when suEXEC is
in place.
suEXEC is installed on many hosting providers. I read the cpanel site
describing the patches [1], tough standart apache httpd does not have
these pa
37 matches
Mail list logo
