readdir and checksecurity

Hi there,

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.

Now suckit alters the system call table to provide specific
functionality to the attacker; one of these is to make specified files
and directories invisible to readdir(3) through a hacked getdents(2)
proxy function.

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?

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: readdir and checksecurity

--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/5mAQCc DzPp
qClHQ6MEFm7QIPl/WUFq+qg=
=Dyqn
-----END PGP SIGNATURE-----

--WIyZ46R2i8wDzkSu--
-
To unsubscribe from this list: send the line "unsubscribe linux-admin" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html