From owner-freebsd-stable@FreeBSD.ORG Thu Dec 10 07:24:48 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 169881065679 for ; Thu, 10 Dec 2009 07:24:48 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7AE338FC19 for ; Thu, 10 Dec 2009 07:24:47 +0000 (UTC) Received: from happy-idiot-talk.infracaninophile.co.uk (localhost [IPv6:::1]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.3/8.14.3) with ESMTP id nBA7OfwY096707; Thu, 10 Dec 2009 07:24:42 GMT (envelope-from m.seaman@infracaninophile.co.uk) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp.infracaninophile.co.uk nBA7OfwY096707 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=infracaninophile.co.uk; s=200708; t=1260429882; bh=TH9VBs/tlnj2xu7yvYCavl7sd9eYPCbEW8+sKMeb3BQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Cc:Content-Type:Date:From:In-Reply-To: Message-ID:Mime-Version:References:To; z=Message-ID:=20<4B20A232.1010800@infracaninophile.co.uk>|Date:=20T hu,=2010=20Dec=202009=2007:24:34=20+0000|From:=20Matthew=20Seaman= 20|Organization:=20Infracaninophi le|User-Agent:=20Thunderbird=202.0.0.23=20(X11/20091129)|MIME-Vers ion:=201.0|To:=20squirrel@isot.com|CC:=20Chuck=20Swiger=20,=20=0D=0A=20FreeBSD-STABLE=20Mailing=20List=20|Subject:=20Re:=20Hacked=20-=20FreeBSD=207.1-Rel ease|References:=20<70b530187d5c4ef4336260f6fdf72193@mail.isot.com >|In-Reply-To:=20<70b530187d5c4ef4336260f6fdf72193@mail.isot.com>| X-Enigmail-Version:=200.95.6|Content-Type:=20multipart/signed=3B=2 0micalg=3Dpgp-sha256=3B=0D=0A=20protocol=3D"application/pgp-signat ure"=3B=0D=0A=20boundary=3D"------------enigF70EE955C764AAA534194B 4D"; b=cI+feLGJlaJudoHGeLS6JbyUdRLoon7U2dJXqDO3OaKrUaDudOlaZmXlTSTsKh3ol 6GoZIphoNuKkETPUd5nI2l8dnHfraY2XLVSByx/RQyJXNzS3i4qqEdTnKPG82UVL4z sdPAgdeWhcFt8yR8AwFCMASNRbDPzQ5aifCFApT4= X-Authentication-Warning: happy-idiot-talk.infracaninophile.co.uk: Host localhost [IPv6:::1] claimed to be happy-idiot-talk.infracaninophile.co.uk Message-ID: <4B20A232.1010800@infracaninophile.co.uk> Date: Thu, 10 Dec 2009 07:24:34 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Thunderbird 2.0.0.23 (X11/20091129) MIME-Version: 1.0 To: squirrel@isot.com References: <70b530187d5c4ef4336260f6fdf72193@mail.isot.com> In-Reply-To: <70b530187d5c4ef4336260f6fdf72193@mail.isot.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF70EE955C764AAA534194B4D" X-Virus-Scanned: clamav-milter 0.95.3 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VERIFIED,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on happy-idiot-talk.infracaninophile.co.uk Cc: FreeBSD-STABLE Mailing List Subject: Re: Hacked - FreeBSD 7.1-Release X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2009 07:24:48 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF70EE955C764AAA534194B4D Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Squirrel wrote: > I've just finished the rtld patch. Now in process of regenerating > all the keys and certs. Next will look into php. But far as rtld > vulnerability, doesn't it require at least a local user account? > Looking at all the authentication, there wasn't any authenticated > session during the time frame. So I'm leaning more towards php > 5.2.9, and checking all my ports. You don't necessarily need to have a login session (ie. recorded in wtmp)= to exploit the rtld bug -- just control over some process and the ability= to run commands through it. Although the rtld bug is "only" a local root= compromise, since it is so simple to exploit it is a lot more dangerous than most, and in combination with just about any form of remote exploit it means your box get rooted. Upgrading PHP and all ports is a good move. portaudit(1) is a good idea but it doesn't necessarily address the direct route your attackers used. My suspicions (in the absence of any detailed forensic examination of your machine) are that you are running some vulnerable PHP code. This may be part of a well known application, or it may be something locally w= ritten. In this case, I'd recommend a number of measures: * Run a security scanner like nikto (ports: security/nikto) against each of the websites on your server. Do this at=20 regular intervals, and take action to fix any problems it discovers. * Make sure that you only grant the minimum necessary permissions on the filesystem to allow apache to run your applications. In general, everything under your doc root should be *readable* by uid www but not *writable* -- don't be seduced by the idea of=20 making the webroot owned by www:www --- root:wheel is a much=20 better idea, and files should be mode 644, directories mode 755 unless there's a good reason to have them otherwise. * Refuse to run any PHP application that requires you to have=20 'register_globals =3D YES' or to similarly poke enormous holes in security through php.ini. Any application developer that has not modified their code to use the $GLOBALS array by now is lazy and incompetent and their code is likely to have all sorts of other holes. * Similarly give your web application only the minimum necessary permissions it needs to access any databases. You'll frequently see instructions to do things like: 'GRANT ALL PRIVILEGES ON foo.* TO www@localhost WITH GRANT OPTION;' This is way too much and should= be trimmed down. Web apps rarely have any need to make schema=20 changes, and creating other UIDs is right out, so 'GRANT SELECT,INSERT,UPDATE,DELETE ON foo.* TO www@localhost' is a=20 much more reasonable starting point. =20 * Where a web application has a legitimate reason to want to write to the filesystem (eg. uploading files), preferably confine the write access to a separate directory tree outside the web root -- /tmp or /var/tmp aren't bad choices, but it might be better to create a specific location for a particular application. * Where a web application has an administrative mode preferably arrange to run this over HTTPS thus protecting any passwords=20 from snooping. If the administrative mode needs to have generic read/write access to the web tree, then consider running it in a completely separate Apache instance with different user credentials than the generally accessible web server. Making the last point work with some arbitrary web application is=20 frequently challenging, but usually at least possible by a combination of mod_rewrite and mod_proxy functions in the Apache config. =20 Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enigF70EE955C764AAA534194B4D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAksgojkACgkQ8Mjk52CukIwoHACbB4kHNpD9I22hcatY1WE6+UQA lM0An1XGF6YdCB2OB8c7NlImo0+jBbRO =P6Xj -----END PGP SIGNATURE----- --------------enigF70EE955C764AAA534194B4D--