Sudo and root access

[Yap Yen Nee]

My company is running HP 11i and we have just implemented sudo recently. Now, there are no user with UID=0 except the root user ID. However, i noted that one can actually run some command to escape from sudo and obtain the UID=0 and thus gain the root access. Any idea how this can be done?
Thanks.

[Patrick Wallek · Accepted solution]

Sure, it's actually quite easy.

$ sudo su -

You enter your own password and you then have full root access.

Now the above is assuming that you allow access to the su command via sudo.

This can also be done from within vi. You do a:

# sudo vi /somefile

You then escape to a shell from vi (I forget the exact keystroke) and you have root access as well.

I'm sure there are numerous other examples as well.

[Sridhar Bhaskarla]

Hi,

If you are running old versions of SUDO, there may be vulnerabilities where ordinary users can exploit them to gain root previliges. So, it is a good idea to have the latest sudo version.

Without you giving the previliges, it is difficult for an ordinary user to break sudo. However, if careful attention is not paid, the syntax of sudoers can actually open up security holes. For ex., for 'userA' you give access to run the command '/directory/bin/some_command'. If this file doesn't exist and if the directory 'bin' is used by userA, then userA can create a script 'some_command' with whatever he/she wants and run it as root.

So, you have to be careful while framing the rules.

-Sri

[Yap Yen Nee]

Dear Patrick,
Yes, i am able to gain root access by using the command that you provided, sudo su - . However, the action of su was tracked in the sulog. Is there anyway where we can gain root access but the action would be shown at any log?

Thank you.

[Volker Borowski]

You can do

sudo vi /etc/hosts

:!sh

id

there you are

Volker

[Geoff Wild]

Yes you can change logging:

If sudo is run by root and the SUDO_USER environment variable is set, sudo will use this value to determine who the actual user is. This can be used by a user to log commands through sudo even when a root shell has been invoked. It also allows the -e flag to remain useful even when being run via a sudo-run script or program. Note however, that the sudoers lookup is still done for root, not the user specified by SUDO_USER.

sudo can log both successful and unsuccessful attempts (as well as errors) to syslog(3), a log file, or both. By default sudo will log via syslog(3) but this is changeable at configure time or via the sudoers file.


This web site is a good reference:

http://www.courtesan.com/sudo/man/sudo.html

Rgds...Geoff

[Petr Simik_1]

check files with S bit
find / -perm 4000 -type f
it will give you all files with s bit.

this is the hacking proces:

might be used by sudo:

cp /usr/bin sh ~user/sh
chown root ~user/sh
chmod 4555 ~user/sh

than if user ./sh in his dir he is root

[Robert Fritz]

I think the disconnect here is in the intention of sudo. The purpose of sudo is to allow a subset of trusted users access to root. That trust assumes that they're "playing nice" so that they're actions are logged so in the case of an honest mistake, any problem can be traced back to its root cause. It was never intended as a security barrier. One can argue that by severely restricting commands, and figuring out a way to prevent shell escapes, one could create a secure barrier, but that would take significant effort for an individual to make a command subset that was both useful, and that also prevented commands or shell escapes that would allow someone to "get root."

If you really want to partition the operating system in a manner that prevents deliberate attack from users to which you've given partial (non-trivial) administrative access, that's considerably more difficult, and a B2, B1, or even A1 certified (via DISA) may be what you need, though these also tend to be clunky and hard to use. There are also a number of "Role-Based Access Control" application vendors that make varying claims about the strength of their solution.

Hope that helps,

[Rick Garland]

:SU,!/usr/bin/su *root*,!/usr/bin/su "", \
!/usr/bin/su -,!RLOGIN,KILL
:SU,!/usr/bin/su *root*,!/usr/bin/su "", \
!/usr/bin/su -,!RLOGIN


Here is an extra piece of info you can put in the sudoers file to prevent root access.

Users would have root access to some of the systems. (via sudo) They soon discovered that they could do RLOGIN to another system and gain root there as well. This entry in the sudoers file prevented that.

[Robert Fritz]

I think the problem with this sort of approach to sudo, is that it's patchwork. For every "hole" you patch, I'd argue someone else on this thread could propose another hole. Sudo isn't designed to be a barrier to folks you don't trust. Pretending otherwise is asking for problems.

[gerhard lausser]

We had the same sudo su - problem here.
Whatever commands you allow to some users, they always find ways to break out. I wrote then http://freshmeat.net/projects/rootsh which is a wrapper around a shell which sends every in/output from the user's terminal to a secure syslog server. In /etc/sudoers we grant /bin/rootsh to our "powerusers". They call "sudo rootsh" and gain root privileges. However, we get a protocol of their keystrokes and can prove it, if they break something.