Re: [Full-disclosure] Apache suEXEC privilege elevation / inform
--vp94VgDlp4WGUKXnxACE9Hl7j7mlxKXj7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 naive
[harry@srv-rhsoft:~]$ php -r "print_r(get_defined_functions());" | wc -l
1330
oh, and they depend on the loaded extensions (inlcuding 3rd party extensi=
ons)
oh, and they *all* would have to be classified if, how and in which conte=
xt
they all may or may not have a secuirity impact
> 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();
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
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
> On Mon, Aug 12, 2013 at 12:10 PM, George Machitidze <giomac@gmail.com <=
mailto:giomac@gmail.com>> wrote:
>=20
> Heh
>=20
> disable_functions and open_basedir is bad example. It's not an apac=
he part - it's PHP, so forget about it -
> <it's a feature of PHP>. 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 upgrading
> software, and why they check all the functions documented and all t=
he details regarding what these functions
> do, this is PHP feature, not httpd feature or httpd bug. The questi=
on is why PHP processes, forks etc running
> under apache/cgi/etc are allowed to do anything what apache can do.=
This is the issue right? If PHP has
> security a bug, which allows to bypass these php.ini-related securi=
ty/sandboxing settings, it means we should
> sacrifice security needs and trust PHP only? I need them both, wher=
e possible. We can't even control and
> isolate subprocesses with selinux, because for cgroups/selinux they=
share same group and contexts. BTW, one
> reminded me in here - itk mpm has workarounds for this problem. htt=
p://mitka.us/articles/mpm-itk/
> It's definitely not a bug, it's an architecture, which must be rede=
signed sooner or later.
>=20
> On Mon, Aug 12, 2013 at 9:28 PM, Coderaptor <coderaptor@gmail.com <=
mailto:coderaptor@gmail.com>> wrote:
>=20
> disable_functions
--vp94VgDlp4WGUKXnxACE9Hl7j7mlxKXj7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlIJV4IACgkQhmBjz394AnmNwgCglKMt7Mxz9r7yw4lgWjdfQxCY
k8gAn2wvw57pVJzuLM8zhDJ8cW/Co0vI
=AKuX
-----END PGP SIGNATURE-----
--vp94VgDlp4WGUKXnxACE9Hl7j7mlxKXj7--
討論串 (同標題文章)
完整討論串 (本文為第 23 之 32 篇)：