From mboxrd@z Thu Jan 1 00:00:00 1970 From: Javier =?iso-8859-15?Q?Fern=E1ndez-Sanguino_Pe=F1a?= Subject: Re: readdir and checksecurity Date: Wed, 24 Mar 2004 16:02:37 +0100 Sender: linux-admin-owner@vger.kernel.org Message-ID: <20040324150237.GA4060@dat.etsit.upm.es> References: <20040324135507.GA940@async.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WIyZ46R2i8wDzkSu" Return-path: Content-Disposition: inline In-Reply-To: <20040324135507.GA940@async.com.br> List-Id: To: Christian Robottom Reis Cc: linux-admin@vger.kernel.org, debian-security@lists.debian.org --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 24, 2004 at 10:55:08AM -0300, Christian Robottom Reis wrote: >=20 > Hi there, >=20 > one of our servers (which runs Debian Woody) was recently > compromised, and had a suckit variant installed. We've gone through the > reinstall and restore steps, and one of the things I looked at is > debian's /usr/sbin/checksecurity script, which checks for changes in > setuid files.=20 (...) > My question is: doesn't this situation sort of invalidate > checksecurity's setuid check, since setuid files that are in "hidden" > directories won't show up in the listing? IMHO any local host intrusion detection system (hids) is screwed once the system gets compromised. That is: - you cannot trust it at all (it might have been replaced with other stuff= =20 that will never alert you) - you cannot trust its reports (it might be based on false information=20 since it can be tricked by the rootkit, just like a local admin might be) The deeper you put the hids in (that is, kernel space vs. userspace) the=20 more you can trust it or expect it to find hidden stuff. But even then there are always ways around it if can have a rootkit installed and running= =20 as root [0] That being said, you could argue that the setuid check is useless but,=20 still, it might be able to find some stuff that the intruder left around=20 without knowing it (people make mistakes, worms do too). And it still might= =20 alert you _before_ the rootkit gets installed [1] (in some cases, a system= =20 reboot is needed in order to get a proper rootkit installed, and the setuid= =20 check might run before that reboot). I wouldn't consider checksecurity's suid problem a bug, more like a=20 limitation. Just my 2c. Regards Javier [0] Unless, of course, you use MAC (se-linux, rsbac....) and even then it= =20 might only make it more difficult not necessarily impossible. [1] _If_ you send these alerts/reports off-site, otherwise they can be=20 manipulated after the intruder got admin priviledges (most rootkits can=20 wipe out logfiles, they don't wipe out checksecurity setuid's files just=20 because Debian is not yet an specific target of rootkits AFAIK) --WIyZ46R2i8wDzkSu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAYaMMi4sehJTrj0oRAltGAJ4o/29OcZJOS99lK1c4nkQ55/5mAQCcDzPp qClHQ6MEFm7QIPl/WUFq+qg= =Dyqn -----END PGP SIGNATURE----- --WIyZ46R2i8wDzkSu--