SUID accidently removed from /bin/su file

Question

It is a production server - CentOS 6.1

Some user having root access in the past had logged on to the server and removed the SUID bit from the /bin/su file and then exited root. Now we are not able to switch back to root. Also ssh access for root is disabled on the server, so root directly cannot login to the machine. Since we are nor able to su to root nor able to ssh as root we can't set the suid bit for the /bin/su file back.(Also we are not able to switch between users using su)

How it should had been:

$ ll /bin/su
-rwsr-xr-x. 1 root root 30092 Mar 10  2011 /bin/su

How it is right now:

$ ll /bin/su
-rwxr-xr-x. 1 root root 30092 Mar 10  2011 /bin/su

Is there any way we can switch back to root or set the SUID bit in any way?

Note: We want to avoid a reboot no networking usermode because the server is in use 24x7 and getting downtime is a bit difficult. If reboot was possible then we could simply login using single user mode as root and reset that bit.

Feel free to give creative answers. I can test your answers on our test environment.

Answer 1

Some options:

• sudo -i, that's the most obvious alternative.
• sudo -l then look for a command that you are allowed to use that you could use to solve the problem, like : editing a file executed by root, like crontab, logrotate, executon yum/rpm...
• go to the console, and connect as root (only ssh is restricted if I understood)
• open a graphical session, some distribution have tools to become root that don't rely on sudo. Also, many of them have some update manager .. Maybe you can reinstall the package which provides su
• if you have a configuration management tool like puppet/chef/ansible/fai... Push the configuration!
• investigate your crontab to see if you can edit a file to escalade.
• if your server is connected to a central authentication system (especially LDAP/nis), create an account with high permission (group wheel, or user uid=0).
• if it's a virtual server, shut it down, then mount and edit the filesystem.

Some silver bullets:

• reboot your server in single user mode (red hat) or specify init=/bin/sh (Debian and rhel/CentOS 7), then fix the permission.
• reboot the server in a CD/DVD/USB/NetBoot and use the recovery (or just mount and edit)

And some really ugly:

• find a vulnerability in you system to compromise it!

If your sysadmin did a good job, a regular user can't do any of those things (but you are the sys admin)

Answer 2

Assuming you're in a group that allows you to sudo, then:

sudo -i

will give you root access and allow you to repair /bin/su. Remember that you use your user's password with sudo - not root's password.

Answer 3

The question implies SSH (or equivalent) as the only access. The only way generally to get from a user privileged process to a root privileged is via su, sudo, or another site local alternative. If you don't have one then you are hopefully out of luck as the presence of an alternative suggests a security hole of some sort.

That said, the suggestion of rebooting to gain access suggests console access is available in some form. Generally root can login directly on the console and would be the first thing to try (perhaps remotely with IPMI or an IP KVM?). Both the graphical console and the serial ports are worth trying.

An alternative is to look for an external file system which either is mounted or can be mounted and allows a static setuid su binary to be presented for your user to run.

If there is a config-management system in place (puppet, chef, etc.) then it may be still running and be usable to fix or update the binaries.

If the running system is a virtual machine you may have access to it in some form from the host environment. (Conversely if it's a host machine you may be able to exploit root access on a virtual machine to gain control)

After that, first evaluate how much time it's worth spending on re-gaining access to the system without doing the re-boot. Then if the time is justified it's a matter of looking at what you do have access to. Look at each of these and evaluate them for the ability to either fix the set-uid bit or otherwise run a relatively arbitrary command:

• Every set-uid binary on the system accessible to your user
• Every process running as the root user (looking at intended uses)
• The underlying storage system and alternate access to it
• Every process running as the root user (looking for unpatched local code execution vulnerabilities)
• The kernel version (looking for unpatched code execution vulnerabilities)

At some point in there it actually becomes a security audit.

Answer 4

Also you can use this command :

sudo -s

It will give you root access