Re: Full-xploiting PHP Nuke

[RoMaN SoFt / LLFB <roman () madrid com>]

 Hi.

 I didn't talk about this because it is indeed related to generic
webserver security, it's not phpnuke bug specific. The exploitation I
described in my former mail could have been easily *avoided* if
propper file permissions and webserver configuration were implemented.
Or at least it could be reduced to some kind of DoS, but not a serious
break-in (I mean, no machine compromise)

 Some facts:
- since webserver is usually running as "apache" user, you could have
web files owned by *another* user: for instance, user "webmaster". In
this way you can have all files & directories of website as read-only.
Then phpnuke bug "copy" feature would NOT work, at least in webserver
directories! (the bug would be limited to some common writable dirs as
"/tmp"). Also note that /tmp dir is not directly reachable from web
and could NOT be used to launch a php shell.
- if you need to have some web dir as "apache" writable (for uploading
files via admin.php, eg) don't let php scripts to be executed in it.
Use php features like "safe mode" and "safe_mode_exec_dir" to limit
dirs where php scripts could be executed. Writeable directories
shouldn't have php execute permissions (this was pointed by Markus
Graf <mgraf () hilogix com>)
- if some file need to be "apache" writable (for instance, some
dinamic config file, etc) it's a good idea to include it in a special
directory ("conf", eg) and have this dir with no execute permissions
(as described formerly). This way if someone breaks into your
webserver and modifies this file, it couldn't insert php system/exec
calls, mysql calls, etc.
- "this exploit is only possible if the "file manager" module is
installed." (this was pointed by Phiber
<nikola.mailing () mail inet hr>). I've not tested this but it seems a
logical thought :-)

 Greetz!

RoMaNSoFt @ irc.irc-hispano.org
roman () deathsdoor com