Got Root?
-
This was discovered on several of the development boxes where I work:
[xxxxxx@xxxxxx]$ which su
/bin/su
[xxxxxx@xxxxxx]$ ls -la /bin/su
-rwsr-xr-x 1 root root 57632 Aug 23 2005 /bin/su
-
What's wrong with that, besides /bin/su being group and world readable, which isn't necessary, but generally shouldn't do harm?
If you are thinking about the setuid-flag, how's su going to work if it isn't setuid root?
-
Where's the WTF? Assuming that "su" is not buggy, and that passwords are not stored in the application binary, I see nothing wrong here. It's not like they made it world-writable or something.
-
@Rocanys said:
This was discovered on several of the development boxes where I work:
[xxxxxx@xxxxxx]$ which su
/bin/su
[xxxxxx@xxxxxx]$ ls -la /bin/su
-rwsr-xr-x 1 root root 57632 Aug 23 2005 /bin/su[erich@iTux erich]$ ll /bin/su
-rwsr-xr-x 1 root root 20408 Jul 25 2004 /bin/su*
[erich@iTux erich]$
Your setup is absolutely default.
-
@Rocanys said:
This was discovered on several of the development boxes where I work:
[xxxxxx@xxxxxx]$ which su
/bin/su
[xxxxxx@xxxxxx]$ ls -la /bin/su
-rwsr-xr-x 1 root root 57632 Aug 23 2005 /bin/su
How do you think you switch to other users anyway, if the process that does the work is not setuid root?You will also find that /bin/passwd is -r-s--x--x; setuid-root as well.
-
@ammoQ said:
@Rocanys said:
This was discovered on several of the development boxes where I work:
[xxxxxx@xxxxxx]$ which su
/bin/su
[xxxxxx@xxxxxx]$ ls -la /bin/su
-rwsr-xr-x 1 root root 57632 Aug 23 2005 /bin/su[erich@iTux erich]$ ll /bin/su
-rwsr-xr-x 1 root root 20408 Jul 25 2004 /bin/su*
[erich@iTux erich]$
Your setup is absolutely default.'Default'? Not for me.
$ ls -l $(which su) -rws--x--x 1 root root 21968 Jan 4 22:42 /bin/su
I figure making it unreadable by all but root makes sure someone can't read the binary to find exploits or something.
(Ok, something is seriously messed up. Whatever fancy HTML autoformatter this thing's using SHOULDN'T FUCK WITH PRE TAG CONTENT. That is all. (On a related note, I'm switching to the "plain text" editor.)
-
The WTF is probably abuse of root access...
The Three Commandments:
1. Thou shalt not take the name of the one true Root lightly.
2. No mortal user shalt taketh thine name.
3. Goto 1
-
@aquanight said:
I figure making it unreadable by all but root makes sure someone can't read the binary to find exploits or something.
Well... so what? The name of the distro is easy to find out... the version too. So you can just get the very same su binary from the internet.
Making it not readable may help if it is a custom version of su...
-
I've just checked an AIX 5.3 box, it's r-sr-xr-x there too.
-
rwsr-xr-x here on a Debian sarge.
By the way, one should not use su but sudo, as sudoers use their own password instead of having to share the One Root Password. The admin may restrict as well the commands a sudoer may run as another user.
-
@aquanight said:
'Default'? Not for me.
$ ls -l $(which su)
-rws--x--x 1 root root 21968 Jan 4 22:42 /bin/suI figure making it unreadable by all but root makes sure someone can't read the binary to find exploits or something.
you're a very funny guy, but you forgot to put the <sarcasm> tag.
-
@OperatorBastardusInfernalis said:
@aquanight said:
I figure making it unreadable by all but root makes sure someone can't read the binary to find exploits or something.
Well... so what? The name of the distro is easy to find out... the version too. So you can just get the very same su binary from the internet.
Making it not readable may help if it is a custom version of su...
If that's the case, then what is the point? Gentoo makes all setuid root binaries unreadable to normals as they are installed, not just su, so there might be something there or else why would they bother? The one exception is sudo, which also has the owner read/write cleared (not that it matters).
Also, exactly how does one find out the su version? Neither 'su -v' or 'su --version' work on my box, and I somehow doubt modify/create time can be trusted. Guess it depends on the distro though, which as you said, is usually easy enough to figure out.
-
@aquanight said:
Also, exactly how does one find out the su version? Neither 'su -v' or 'su --version' work on my box, and I somehow doubt modify/create time can be trusted. Guess it depends on the distro though, which as you said, is usually easy enough to figure out.
Unless it is a customized version (which would make me supsicious), a good guess is all it takes. I doubt there are so many different versions of su that a security hole exists in exactly one of them an no other version.
-
@ammoQ said:
@aquanight said:
Also, exactly how does one find out the su version? Neither 'su -v' or 'su --version' work on my box, and I somehow doubt modify/create time can be trusted. Guess it depends on the distro though, which as you said, is usually easy enough to figure out.
Unless it is a customized version (which would make me supsicious), a good guess is all it takes. I doubt there are so many different versions of su that a security hole exists in exactly one of them an no other version.
True @ different implementations (and I could see maybe a couple good reasons for customizing: changing the group to something other than 'wheel' or removing that requirement entirely for some special, site-specific cases, but then they should just use sudo). But different versions? I decided to have a look at the shadow tarball and found this in su.c: #ident "$Id: su.c,v 1.74 2006/08/01 10:30:02 kloczek Exp $" - presumably the version number, which is 1.74, so presumably there's been a 1.73, 1.72, etc... One could then assume that perhaps some ancient version had a hole. No sane person would use it, but that's not really the point.
Still doesn't answer the question why a distro would set g-r,o-r on all setuid binaries at all.
-
@acne said:
rwsr-xr-x here on a Debian sarge.
By the way, one should not use su but sudo, as sudoers use their own password instead of having to share the One Root Password. The admin may restrict as well the commands a sudoer may run as another user.
Ditto for Debian etch.
To enforce this line of thinking on all of the boxes I administer, one of the first things I do once I confirm that sudo is working properly is the following, if it hasn't already been done:
- Log in as myself.
- su to root
- Set root's password to a random 64-character string.
- exit
Then I move on with things. If I ever absolutely need a root console (which should rarely--if ever--happen),
sudo su -works quite well.
-
@aquanight said:
True @ different implementations (and I could see maybe a couple good reasons for customizing: changing the group to something other than 'wheel' or removing that requirement entirely for some special, site-specific cases, but then they should just use sudo).
wheel requirement is not enforced by su, but by pam.
-
the only time I login at work as anything other than root is to change the permissions on a file that is under my username.
-
Nothing wrong, it seems:
[renan@panic ~] $ ll /bin/su
-rwsr-xr-x 1 root root 31540 2006-11-25 16:04 /bin/suBTW, I have 's' aliased to 'sudo'. It is quicker this way.
-
@ender said:
@aquanight said:
True @ different implementations (and I could see maybe a couple good reasons for customizing: changing the group to something other than 'wheel' or removing that requirement entirely for some special, site-specific cases, but then they should just use sudo).
wheel requirement is not enforced by su, but by pam.Oops, yeah forgot about that, from the fact that in that source spelunk I saw the iswheel() function which is basically unused with USE_PAM #defined, though iswheel() itself is not in a #ifndef USE_PAM ...
Though non-PAM systems will enforce wheel requirement in su, and that's when custom adjustment would be desired (the use or not of that check can be turned off without customizing presumably, but the hard coded name 'wheel' requires source-edit). Can't name any non-PAM systems off the top of my head though (*BSD maybe?).
-
@cparker said:
Ditto for Debian etch.
To enforce this line of thinking on all of the boxes I administer, one of the first things I do once I confirm that sudo is working properly is the following, if it hasn't already been done:
- Log in as myself.
- su to root
- Set root's password to a random 64-character string.
- exit
Then I move on with things. If I ever absolutely need a root console (which should rarely--if ever--happen),
sudo su -works quite well.What will you do next time you need to log in your system in single user mode? You'll need the root password then. For the machines I do not own but administer, I write down the root password and store it in the company safe.
And if you need a shell, simply type "sudo -s".
-
@acne said:
What
will you do next time you need to log in your system in single user
mode? You'll need the root password then. For the machines I do not own
but administer, I write down the root password and store it in the
company safe.And if you need a shell, simply type "sudo -s".
Well, give the boot loader the kernel option "init=/bin/bash" and hit enter. You do realize thouth that you can change the password again without knowing it, yes? 'sudo passwd' or even 'sudo vim /etc/shadow'
I'm not saying that I agree with random root passwords, as that seems a bit excessive/silly (just set it to your own password if you don't want to worry about remembering it), just that there's no danger in not having the root password.
-
@Nandurius said:
Well, give the boot loader the kernel option "init=/bin/bash" and hit enter. You do realize thouth that you can change the password again without knowing it, yes? 'sudo passwd' or even 'sudo vim /etc/shadow'
Sure, but your bootloader is password protected against any non default kernel line, right? Or you might as well use an empty root password...
And I know that any password may be changed without knowing it, but what if you get that dreaded "Enter root password or hit Ctrl+D to continue"?
-
@acne said:
Sure, but your bootloader is password protected against any non default kernel line, right? Or you might as well use an empty root password...
And I know that any password may be changed without knowing it, but what if you get that dreaded "Enter root password or hit Ctrl+D to continue"?
If access to the console is restricted, it's IMO not necessary to do protect the bootloader. On the other hand, in a very confidentional environment, you have to use encrypted filesystems as well, since someone with access to the console might as well take the harddisk out of the box and mount it on another computer.
