Strange command histories in hacked shell history

Gerhard Schmidt estartu at augusta.de
Mon Dec 20 05:40:58 PST 2004


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 <ganbold at micom.mng.net>
> > Subject: Strange command histories in hacked shell server
> 
> Just a minor comment on one portion of your message.  
> 
> [All deleted except the pertinent part - wjv]
> 
> > Machine is configured in such way that everyone can create an account itself.
> > 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.
> 
> > 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> So in your case there is the possibility that someone else
> su'ed to 'tsgan' and then su'ed to root.
> 
> 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 
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´t prevent him form directly 
logging in as this User an than use su. Therefore there is no gain in 
security just a drawback in usefulness. I use this often to get a 
rootshell on an Xsession from an user who can't su to root. 

Bye
	Estartu

----------------------------------------------------------------------------
Gerhard Schmidt    | Nick : estartu      IRC : Estartu  |
Fischbachweg 3     |                                    |  PGP Public Key
86856 Hiltenfingen | Privat: estartu at augusta.de         |   auf Anfrage/
Germany            |					|    on Request 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 366 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20041220/aab27eca/attachment.bin


More information about the freebsd-security mailing list