Re: Strange command histories in hacked shell history

--T4sUOijqQbZv57TR
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 17, 2004 at 09:53:15AM -0500, Bill Vermillion wrote:
> > Message: 1
> > Date: Thu, 16 Dec 2004 20:31:05 +0800
> > From: Ganbold <[e-mail]>
> > Subject: Strange command histories in hacked shell server
>=20
> Just a minor comment on one portion of your message. =20
>=20
> [All deleted except the pertinent part - wjv]
>=20
> > Machine is configured in such way that everyone can create an account i=
tself.
> > Some user dir permissions:
> > ...
> > drwxr-xr-x  2 root       wheel         512 Mar 29  2004 new
> > drwx------  3 tamiraad   unix          512 Apr  9  2004 tamiraad
> > drwxr-xr-x  6 tsgan      tsgan        1024 Dec 16 17:51 tsgan
> > drwx------  4 tugstugi   unix          512 Dec 13 20:34 tugstugi
> > drwxr-xr-x  5 unix       unix          512 Dec 13 12:37 unix
> > ...
> > User should log on as new with password new to create an account.
>=20
> > Accounting is enabled and kern.securelevel is set to 2. Only one
> > account 'tsgan' is in wheel group and only tsgan gan become root
> > using su.
>=20
> I've asked others before and never got a real answer on the design
> of 'su' which to my way of thinking has a security hold that shold
> be fixed.
>=20
> su checks the EUID of the user to see if they are in 'wheel' to
> enable them to su to root.   It would seem to me it should
> use the UID.
>=20
> In your case if the 'tsgan' account does not have a secure
> password, and some breaches the 'tsgan' account in any manner, such
> as a SUID tsgan as I see it, then that user who cracked the 'tsgan'
> account can su to root.
>=20
> So in your case there is the possibility that someone else
> su'ed to 'tsgan' and then su'ed to root.
>=20
> Can anyone explain why  su   does not use the UID from the login
> instead of the EUID ?  It strikes me as a security hole, but I'm no
> security expert so explanations either way would be welcomed.

I'm not a security expert, but if someone has the Username/Password for=20
an Account that can su to root. Where is the point of disallowing him
to su to this user and than to su. You can=B4t prevent him form directly=20
logging in as this User an than use su. Therefore there is no gain in=20
security just a drawback in usefulness. I use this often to get a=20
rootshell on an Xsession from an user who can't su to root.=20

Bye
	Estartu

----------------------------------------------------------------------------
Gerhard Schmidt    | Nick : estartu      IRC : Estartu  |
Fischbachweg 3     |                                    |  PGP Public Key
86856 Hiltenfingen | Privat: [e-mail]         |   auf Anfrage/
Germany            |					|    on Request=20


--T4sUOijqQbZv57TR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: bCHKE95AEm527a0z6msw7JBkunBZk/u3

iQCVAwUBQcahzAzx22nOTJQRAQEFxAP8ConN73YFl+0J2qSB2vcMG1PPYuAKX08J
qROZIkoHekpR88S6BMIHom0ynCo9mH9NiyvH+ctU7WPw4+a2pMiCMMiTtqDAo+g0
IeHL1GzryxDTnaNhxXf8bbbg6c5ve/tXmpNp8yVh29z6D6DhEqSG+tVlDfGNJMlo
xf+zz099ayU=
=njyH
-----END PGP SIGNATURE-----

--T4sUOijqQbZv57TR--