Is suid bit so dangerous?

F

freemason

HELL-O!

I install urxvt from ports and see that it is installed with root suid bits set on both daemon and not-daemon binary! non-sense! What a security risk!

And after that I seriously begin to think of what real impact on security it does?
And also write bits - normally executables should not have them set?

How do I find all executables/libraries in system with suid bit and write bits set?
And is it safe to unset these bits on binaries from base system? And from what ports?


And my traditional robotic: "Thanks in advance for any help!"
 
Find all files (in /usr/local/bin) with S_ISUID bit set
$ find /usr/local/bin -perm +4000

Find all files with S_ISUID and that are writable by ownser
$ find /usr/local/bin -perm -4200


find(1)

from chmod(1)
4000 (the setuid bit). Executable files with this bit set will
run with effective uid set to the uid of the file owner.
Directories with this bit set will force all files and sub-
directories created in them to be owned by the directory
owner and not by the uid of the creating process, if the
underlying file system supports this feature: see chmod(2)
and the suiddir option to mount(8).
Click to expand...
 
Some binaries require suid root to function. They require additional priviledges a regular user doesn't have. For example /usr/local/bin/Xorg.
 
Setuid is not dangerous by itself, however you should audit the list of setuid executables on your system and ensure they are patched.

The most common reason for a program to be setuid is to enable it to act as root (setuid root). This can be if it needs access to hardware, or secure storage, etc.

This means, however that any vulnerability in a program that is set up as setuid root can get an attacker root-level access to your box, by running the command as a regular user (privilege escalation).


Essentially, if you can avoid it (and as above, with some things, you can't - or doing so is inconvenient or opens up other holes), you don't want things to run setuid root. Setuid root files on shared storage are a particularly nasty trap - if you are mounting shares that have setuid root files on them that were created by a user on another box, they can be used to own your box. There are options to mount such shares no-setuid - so the setuid bit on files will be ignored on that filesystem.

You don't want files that are setuid to be writable by non-root users, otherwise someone could replace them with malicious code that will then be executed as root.
 
Setuid programs that are not trojaned found in a *NIX distribution, are -normally- innocuous. Nevertheless, I have servers running inside jails where the only binary that has the suid bit it set (if I remember well...) is /usr/bin/login.

As a rule of thumb I'd say: The suid bit is not dangerous for "well known programs". On the other hand, if you find a suid-root binary whose origins are unknown, then there is a huge chance that your system has been compromised by some careless attacker.
 
Thank you, folks!

So, here is what I've got after walking through the whole "/":
1) SUID bit set on these:
Code: 
> find / -perm +4000
/usr/bin/at
/usr/bin/atq
/usr/bin/atrm
/usr/bin/batch
/usr/bin/chpass
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/ypchpass
/usr/bin/ypchfn
/usr/bin/ypchsh
/usr/bin/lock
/usr/bin/login
/usr/bin/opieinfo
/usr/bin/opiepasswd
/usr/bin/passwd
/usr/bin/yppasswd
/usr/bin/quota
/usr/bin/rlogin
/usr/bin/rsh
/usr/bin/su
/usr/bin/crontab
/usr/bin/lpq
/usr/bin/lpr
/usr/bin/lprm
/usr/libexec/ulog-helper
/usr/local/bin/sudoedit
/usr/local/bin/sudo
/usr/local/bin/Xorg
/usr/local/bin/pkexec   <----  This is also writable!
/usr/local/libexec/gnome-pty-helper
/usr/local/libexec/dbus-daemon-launch-helper   <----  This is also writable!
/usr/local/libexec/polkit-agent-helper-1   <----  This is also writable!
/usr/sbin/ppp
/usr/sbin/timedc
/usr/sbin/traceroute
/bin/rcp
/sbin/mksnap_ffs
/sbin/ping
/sbin/shutdown
/sbin/poweroff
 
Everything from /bin/, /sbin/, /usr/bin and /usr/sbin should be safe, they are part of the base OS. You don't, for example, want to remove the suid bit from /usr/bin/passwd, if you do nobody will be able to change his password.
Code: 
/usr/local/bin/pkexec   <----  This is also writable!
Click to expand...
Writeable by who? If it's only writeble by root there isn't much of an issue. If somebody is able to overwrite it they already have root access and you have more serious problems than just a suid binary.

You can find out which port/package installed it with pkg_info(1):
# pkg_info -W /usr/local/bin/pkexec
 
mamalos said:
As a rule of thumb I'd say: The suid bit is not dangerous for "well known programs". On the other hand, if you find a suid-root binary whose origins are unknown, then there is a huge chance that your system has been compromised by some careless attacker.
Click to expand...


I'd agree with that, with the proviso that it's not just trojanned programs that are a worry.

If an executable has a buffer overflow or is otherwise exploitable to get a shell (maybe even a 0-day), with a setuid root executable that will mean a root shell. Without setuid, it would only give the user a shell as their own userid.

In short, if you're security conscious, you should avoid running programs that require setuid root if an alternative that will do the same job exists that does not require the privilege. Or, consider manually running the programs as required as root using sudo, if this is possible.

Again though, some programs require setuid to work. But if you find something that isn't part of the base OS, and is setuid you should be asking "why does this need to be setuid", followed by "do I need this feature?" If there is no valid reason, then I'd use something else, or remove the setuid program.

If you find setuid binaries in non-binary filesystem locations (especially in for example /tmp or anywhere under /var) you may have been hacked.
 
SirDice said:
Everything from /bin/, /sbin/, /usr/bin and /usr/sbin should be safe, they are part of the base OS. You don't, for example, want to remove the suid bit from /usr/bin/passwd, if you do nobody will be able to change his password.
Click to expand...
Generally speaking, I shouldn't touch base system, should I?
Just inspect such foreign things as ports, packages, scripts and my own experimental stuff only..ok

Writeable by who? If it's only writeble by root there isn't much of an issue. If somebody is able to overwrite it they already have root access and you have more serious problems than just a suid binary.
Click to expand...
by root obviously:
Code: 
> l /usr/local/bin/pkexec
-rwsr-xr-x  1 root  wheel

You can find out which port/package installed it with pkg_info(1):
# pkg_info -W /usr/local/bin/pkexec
Click to expand...
Code: 
> pkg_info -W /usr/local/bin/pkexec
/usr/local/bin/pkexec was installed by package polkit-0.99
Thanks, SirDice.

And one more question (which may be considered off-topic)!
What is fashion in using sudo? It is not in base system, there were vulnerabilities with it - so it is really NOT SAFE tool. I can use su (and it comes with system) for everything instead of sudo...or not?
 
Nobody said sudo(8) was a safe tool. You need to be really careful with its use.

One of the downsides of su(1) is that it requires the root password. If there's only one user (you) this may not be an issue but if you have multiple users administrating the box you don't want to make root's password public knowledge.
 
As above, if you're on a single user system then just using su is probably fine.

If it is a multi-user box, then you don't want to give everyone the root password.

sudo has had vulnerabilities in the past, but so has ssh, sendmail, named, etc - it is a judgement call as to whether you want to run with it or not.

The advantage in this instance would be that you could limit users to specific commands they can run as root, and not divulge your root password. As mentioned, using su enables a user to do basically anything, as they have the root password.
 
To continue on the sudo(8) path, be very, very careful what you allow. Something that looks innocuous can be a huge risk. Best example of this is less(1). It may seem innocent enough but less(1) has an option to spawn a local command and you can easily spawn a shell. If less(1) was sudo'd, the user now has a root shell.
 
throAU said:
I'd agree with that, with the proviso that it's not just trojanned programs that are a worry.
Click to expand...
What I mean is that when a program is designed to be suid root, then it should be suid root. So, if this program is located in the main distribution of an OS, it probably is "necessary" for many users, hence you're "accepting the risk" of having it present. Of course, as you've already mentioned, setuid root programs are more dangerous than most other programs when compromised. But, in order to be precise and with respect to your quote:

throAU said:
If an executable has a buffer overflow or is otherwise exploitable to get a shell (maybe even a 0-day), with a setuid root executable that will mean a root shell. Without setuid, it would only give the user a shell as their own userid.
Click to expand...

This is not true at all. All root owned binaries that are using some system call of the setuid(2) family are exactly as dangerous as any other setuid root program for the part of the code that runs with escalated privileges. And trust me, there are many programs present in every *NIX distribution that use some variant of this family of system calls (just play with grep(1) with the binaries located in your $PATH and you'll find many). And for those programs, you don't have the luxury of disabling the setuid bit; so who is more dangerous now? ;-)
 
You can not gain root privilegdes by accident on a non-setuid program if it's started by an unpriviledged user no matter what system calls it makes. It does not matter who owns the binary if the setuid bit is not set.
 
mamalos said:
This is not true at all. All root owned binaries that are using some system call of the setuid(2) family are exactly as dangerous as any other setuid root program for the part of the code that runs with escalated privileges. And trust me, there are many programs present in every *NIX distribution that use some variant of this family of system calls (just play with grep(1) with the binaries located in your $PATH and you'll find many). And for those programs, you don't have the luxury of disabling the setuid bit; so who is more dangerous now? ;-)
Click to expand...
Really?

http://lists.grok.org.uk/pipermail/full-disclosure/2009-November/071686.html
http://stealth.openwall.net/xSports/fbsd-rtld-full-package

Note how a bug in rtld(1) is used to trick a setuid root process (/sbin/ping) and obtain a root shell.
 
Sorry guys, you're right. I had a very specific scenario in my head with a program running as root and dropping privileges to a lower privileged user. From that scenario I rushed into generalizing that this could also happen for every user, which -as you well pointed out- is not true, since the setuid(2) system call family can be used by any user, but, of course, the kernel decides whether the effective or real UID of the process is allowed to change or not.

Sorry again for the misunderstanding I've caused.
 
No problem, it's a difficult subject. And to be honest I had to search for quite a while to find a proper example. Although this exploit doesn't abuse the setuid binary directly it does show you need to be very careful. Even if you program your setuid application perfectly bug free you can still get bitten.

I think this is the argument the OP was trying to make. Setuid should be used sparingly and only if you absolutely have to.
 
...while I was out for lunch break I realised that what I had written was only partially true and that my general argument was false. When I came back to write an excuse for my post, your answers had already been written :).

The irony is that I've been using setresuid(2) and setresgid(2) for quite a while now in a client/server program that a colleague of mine and me have written in order to "unify" user management in FreeBSD hosts (LDAP, SAMBA, KERBEROS). For this program's needs, I had studied these system calls very well with respect to their secure use...based on this, I now understand that my brain starts forgetting a lot faster than it learns...:)
 
You must log in or register to reply here.
Back
Top