[HCS-D]mod_php alternatives? (and tonight's work)
gline at fas.harvard.edu
Mon Dec 6 16:13:47 EST 2004
Well, ladies and gentlemen, I appear to have found the exploit they've
been using to get into hcs.
gline-hcs% ps aux | grep www
www 16096 0.0 0.1 1568 712 ?? S 4:07PM 0:00.01 ./k
gline-hcs% sudo lsof -p 16096
k 16096 www 10u IPv4 0xcaa2f450 0t0 TCP hcs.harvard.edu:http->proxy2.satfilm.net.pl:35041 (CLOSE_WAIT
gline-hcs% host proxy2.satfilm.net.pl
proxy2.satfilm.net.pl has address 184.108.40.206
and then a quick grep for the IP address in our httpd-access and error
logs yielded plenty of material like this, much of it related to this
phpBB2 script. Which, according to google, is broken.
/usr/local/www/log/httpd-access.log:220.127.116.11 - - [01/Dec/2004:13:50:06 -0500] "GET /~hsmbb/
%54%50%5F%47%45%54%5F%56%41%52%53%5B%72%75%73%68%5D%29.%2527 HTTP/1.0" 200 29997 "-" "-"
Of course, there could be other broken scripts lying around, so we need
to address the phpsuexec problem.
til' tonight, which will again be exciting, I bid you all adieu.
On Mon, Dec 06, 2004 at 03:57:32PM -0500, Gregory N. Price wrote:
> On Mon, Dec 06, 2004 at 09:15:23AM -0500, Philip Zeyliger wrote:
> There are hacky ways to run PHP as users. We use them. I set
> them up... The short story is you copy a binary to your scripts
> dir, add a few lines to .htaccess, and everything *.php gets run
> by that program, which runs PHP for you. I can go into
> more detail at a later time.
> Yeah, I saw what looked like such a thing in ~dunster. I saw also on
> Google a how-to for what looked like setting up such a thing systemwide.
> We do want to make it systemwide.
> I haven't looked carefully at this script; is it the sort of thing
> that'd leave us more secure than we started?
> Some other solutions spotted last night:
> - A patch to suexec that lets it know about PHP:
> - A separate suexec just for PHP:
> Naturally, we won't install any such thing without being confident
> it's a good idea.
> On Mon, Dec 06, 2004 at 02:38:34AM -0500, Ivan Krstic wrote:
> > ... without having apache run as root (which in itself is a really bad idea).
> This is accurate. The solution is securing the system in other ways,
> including but not limited to ACLs, TPE, socket control, and chroot for
> the web server.
> Do you mean running apache as root, and then doing other things to
> maintain security?
> I expect running a small piece as root -- rather like suexec -- is a better idea.
> I will bring this up at the meeting tonight, but several things are
> apparent to me at this point:
> (1) HCS ought to create a new post for a security manager/CSO
> (2) the choice of operating system, security, and software on public HCS
> machines ought to be reconsidered once the CSO has been appointed
> (3) installation baselines ought to be produced and kept on 'cold' media
> (4) installation baselines need to be integrated, probably
> automatically, into an up-to-date map of software, with accompanying
> version information, deployed across all HCS machines, for a god's-eye
> view of potential security problems
> Yep, we'll talk about these. Lots of things are good ideas for HCS to
> do if someone wants to put in the time to do them.
> hcs-discuss mailing list
> hcs-discuss at lists.hcs.harvard.edu
More information about the hcs-discuss