> Message: 1 > Date: Thu, 16 Dec 2004 20:31:05 +0800 > From: Ganbold <ganbold@micom.mng.net> > Subject: Strange command histories in hacked shell serverJust 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. Bill -- Bill Vermillion - bv @ wjv . com
I thought on BSD, there was no distinction between euid and uid. If you login as user 'foo', and su to 'bar', your uid is bar and you gain all of "bar"'s privs. 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@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. > > Bill > > > -- > Bill Vermillion - bv @ wjv . com > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"-- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/
Bill Vermillion wrote:> >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. > >Bill > > > >Because su does exactly what is says. From the manual - DESCRIPTION *su* requests the password for /login/ and switches to that user and group ID after obtaining proper authentication. Just for fun, here's an little snippet from the sudo manual - DESCRIPTION *sudo* allows a permitted user to execute a /command/ as the superuser or another user, as specified in the /sudoers/ file. The real and effective uid and gid are set to match those of the target user as specified in the passwd file and the group vector is initialized based on blah blah blah... -- --- ---- http://www.ods.org
Let me just comment on two items that are in the thread which I seem to have caused to get a bit long. On Sat, Dec 18, 2004 at 12:01 , while impersonating an expert on the internet, freebsd-security-request@freebsd.org sent this to stdout:> ------------------------------> Message: 4 > Date: Fri, 17 Dec 2004 10:51:35 -0500 (EST) > From: "Jerry Bell" <jerry@syslog.org> > Subject: re: Strange command histories in hacked shell server> Did I understand correctly, that anyone can connect to the shell server > and create an account for themselves?> I have a somewhat rudimentry hardening guide for FreeBSD at > http://www.syslog.org/Content-5-4.phtml> I've tried to keep it up-to-date, but I have yet to incorporate > IMAC, which think will help out a good bit more.> I hope you find this a useful.I do agree with that, espeically the first paragraph " ... no matter how paranoid your philsophy ..." I have had one instance of an attempt was I had missed one machine out of about 8 applying one security patch. All were patched within hours, the one that got hit was 2 days later. You have to get to any patches as soon as the hole becomes known. And my machines are pretty accessable to the world being on a backbone. One machine was getting about 300,000 spams/day until I finally took off all MX for that domain. If anyone has problems they need to perform a whois and use those contacts. It's one of those domains whose name alone drives it up the list. I haven't set the security levels high as that means that any problems would require driving to the colo - and that's about 1/2 hour at 3AM - and two to three times higher during the daylight hours. ...> Message: 9 > Date: Fri, 17 Dec 2004 22:13:47 -0600 > From: Elvedin Trnjanin <mnsan11@earthlink.net>And Elvedin wrote in reply to my post where I wrote:> >This means that the 'wheel' security really is nothing more > >than a 2 password method to get to root.> Precisely. If you don't like this then the way around is to only > allow a certain group access to su and none for everyone else.That thought had not crossed my mind. Craig also mentinoed that. [his comment follows].> >If the EUID of the orignal invoker is checked, even if they su'ed > >to a person in wheel, then they should not be able to su to root.> >I'm asking why is this permitted, or alternatively why is putting a > >user in the wheel group supposed to make things secure, when in > >reality it just makes it seem more secure - as there is only one > >more password to crack.> One more password to crack is more time which means a better > chance of catching the cracker in the act. Although I don't know > why exactly the authors of su did that the way they did but my > first and best guess would be convenience. The two password > method is better than a new login session each time you want > to get to root. Second best guess would be is that they didn't > figure out that issue or at least think much of it.One more password to hack does make it harder, but in a paranoid mode if someone did break a password of a wheel user, then they have a root password to break. I'd just as soon them not have that ability at all. I'm concerned about some application turning out to have an unknown hole and someone wandering around before they are found. It seems there are tons of attempts on sshd logins in the past few months, but I'm thinking that if some app breaks then that person could perhaps su to a local person that is in wheel. Your idea of changing su to be only executeable root and user in group wheel may be just what I need. I may be overly paranoid, but in this day and age you can't be too secure. The one penetration that I had three years ago on one non-critical machine was one more than I'd have like to have had. There are a total of 4 people who have wheel accounts, and one person has a set of sudo command so he can edit his own private set of sendmail aliases, primarly for a large mailing list he maintains, but other than that it's locked down pretty well. As above I'm concerned about some unknown hole in an app giving someone a chance locally.> ------------------------------ > Message: 12 > Date: Sat, 18 Dec 2004 11:45:45 +0000 > From: Craig Edwards <brain@winbot.co.uk>> You could change the permissions on the su binary, so that only > users in the wheel group can even execute su. that way, when a > non-wheel user attempts to su to a user in the wheel group, they > simply get permission denied.That's one that had not crossed my mind. I will probably do that.> The idea of chmod'ing your suid binaries is always good in my > opinion, and will stop this from happening simply and easily > without having to change any code.Which is very good. The fewer things modified the fewer things to get missed on system upgrades. Thanks to all who responded. Now my only unanswered question has to do with why su was designed like this originally. Those reasons are probably lost somewhere in history. But now I can ease some of my paranoic worries at least by changing su. Bill -- Bill Vermillion - bv @ wjv . com
While normally not able to pour water out of a boot with instructions on the heel, on Mon, Dec 20, 2004 at 10:56 our dear friend Gerhard Schmidt uttered this load of codswallop:> On Fri, Dec 17, 2004 at 09:53:15AM -0500, Bill Vermillion wrote:[much deleted - wjv]> > 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.You can limit the access for the person who has wheel/su privledges by running sshd and then permitting connections only from certain IPs or IP blocks. So another person is severely restricited from logging in as this user even if they have cracker that persons password. But once the craccker is in the system they can attempt breaking the password on a local basis, and the attack the root system. I think the comment one other person made about limiting the su stack to 1, so that you can not su to an account and then su to another account is a good approach. Considering the HUGE abount of attempted SSH logins I see on my servers from all over the world, with most coming from Korea, China, and lately Brazil, to add to those from Germany and Russia [just some I recall from the whois queries] andthing we can do to improve the security is a step forward. In server environments security far outweighs all other considerations IMO. Bill -- Bill Vermillion - bv @ wjv . com
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@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@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