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 [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

--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:
>
> 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.
(...)
> 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=

that will never alert you)
- you cannot trust its reports (it might be based on false information
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
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=

as root [0]

That being said, you could argue that the setuid check is useless but,
still, it might be able to find some stuff that the intruder left around
without knowing it (people make mistakes, worms do too). And it still might=

alert you _before_ the rootkit gets installed [1] (in some cases, a system=

reboot is needed in order to get a proper rootkit installed, and the setuid=

check might run before that reboot).

I wouldn't consider checksecurity's suid problem a bug, more like a
limitation.

Just my 2c.

Regards

Javier


[0] Unless, of course, you use MAC (se-linux, rsbac....) and even then it=

might only make it more difficult not necessarily impossible.
[1] _If_ you send these alerts/reports off-site, otherwise they can be
manipulated after the intruder got admin priviledges (most rootkits can
wipe out logfiles, they don't wipe out checksecurity setuid's files just
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 [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html