User: Password:
|
|
Subscribe / Log in / New account

suid-binary vulnerabilities

suid-binary vulnerabilities

Posted Oct 28, 2010 12:58 UTC (Thu) by cesarb (subscriber, #6266)
In reply to: suid-binary vulnerabilities by michaeljt
Parent article: Two glibc vulnerabilities

Or even better, do not use setuid at all.

For instance, imagine if ping, instead of being setuid, called into dbus to load a helper daemon, and that helper daemon did all the actions which need root (in this example, sending pings). The part controlled by the user would limit itself to the user interface (showing one line per packet, doing the average calculations, and so on).

This way, the daemon is always run in a clean environment (the one dbus uses to launch daemons).

In the ping example, this also has the advantage that it makes it harder to avoid the restrictions on the minimum ping interval by running several instances of ping in parallel (no matter how many you run, they will talk to a single daemon, which can limit the ping rate per user or even globally).


(Log in to post comments)

suid-binary vulnerabilities

Posted Oct 28, 2010 13:31 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

> Or even better, do not use setuid at all.
>
> For instance, imagine if ping, instead of being setuid, called into dbus to load a helper daemon, and that helper daemon did all the actions which need root (in this example, sending pings).

Actually a clean environment was the main point of what I suggested above - i.e. using a setuid loader which can clean the environment (not just the environment as in setenv of course) before it loads your privileged binary. My worry with using dbus for this is that it requires a sizeable piece of infrastructure to be present and running properly in order to start your binary, which is fine for desktop use, but may not be appropriate for all situations.

suid-binary vulnerabilities

Posted Oct 28, 2010 14:22 UTC (Thu) by marcH (subscriber, #57642) [Link]

> Or even better, do not use setuid at all.

Indeed setuid looks very much like a kludge

> For instance, imagine if ping, instead of being setuid, called into dbus to load a helper daemon,...

This looks like PolicyKit. Another setuid killer is setcap:

chmod u-s /bin/ping
setcap 'CAP_NET_RAW+ep' /bin/ping

Et voilà, all these LD_AUDIT holes are plugged without even upgrading glibc. Correct? If yes why isn't ping installed like this by default?

suid-binary vulnerabilities

Posted Oct 28, 2010 14:58 UTC (Thu) by RobSeace (subscriber, #4435) [Link]

Well, the hole becomes less serious when exploited, but I wouldn't say it was
"plugged", really... Now, successfully exploitation just gets you the ability
to create raw sockets instead of full root... But, raw sockets aren't really
something you want to give to an untrusted user to play with, either...

But, yeah, it'd still be better than giving them root, so yeah, why isn't this
done if it's possible?

suid-binary vulnerabilities

Posted Oct 28, 2010 15:21 UTC (Thu) by ccurtis (guest, #49713) [Link]

Looks like Fedora 15 is going to try it.

http://fedoraproject.org/wiki/Features/RemoveSETUID

suid-binary vulnerabilities

Posted Oct 28, 2010 19:44 UTC (Thu) by dlang (subscriber, #313) [Link]

they are not fundamentally changing anything, they are just moving from a single suid bit to a array of individual capibilities. This still lets a user execute a program that will have more privilages than the user with whatever environment the user defines.

suid-binary vulnerabilities

Posted Oct 29, 2010 11:00 UTC (Fri) by marcH (subscriber, #57642) [Link]

Still looks like a major improvement to me.

suid-binary vulnerabilities

Posted Oct 28, 2010 22:04 UTC (Thu) by kees (subscriber, #27264) [Link]

This just slightly reduces the attack surface, but doesn't fundamentally solve the problem (vulnerabilities like this in the loader are extremely dangerous). There will still be things with CAP_SETUID. Here's Tavis's $ORIGIN attack, unchanged except modified to target /bin/su instead of /bin/ping, and with the proposed change made to /bin/su (drop setuid, gain CAP_SETUID):

[kees@fedora-13-i686 ~]$ ls -la /bin/su
-rwxr-xr-x. 1 root root 29292 Feb 12 2010 /bin/su
[kees@fedora-13-i686 ~]$ getcap /bin/su
/bin/su = cap_setuid+ep
[kees@fedora-13-i686 ~]$ ./glibc-ld_audit-origin.sh
[root@fedora-13-i686 ~]# id
uid=0(root) gid=500(kees) groups=0(root),500(kees) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

suid-binary vulnerabilities

Posted Oct 29, 2010 10:27 UTC (Fri) by marcH (subscriber, #57642) [Link]

Please be fair and compare CAP_NET_RAW with CAP_SETUID..

suid-binary vulnerabilities

Posted Oct 29, 2010 11:49 UTC (Fri) by kees (subscriber, #27264) [Link]

Why? If this is about whole-system security, there will still be binaries with CAP_SETUID (su, sudo, newrole, seunshare, etc). It absolutely reduces the attack surface in general, but linker vulnerabilities will remain a serious problem. Removing the setuid bit is a great idea for reducing the impact of bugs in the setuid program itself, though.

suid-binary vulnerabilities

Posted Oct 29, 2010 11:52 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

"Removing the setuid bit is a great idea for reducing the impact of bugs in the setuid program itself, though"

Precisely, the goal.

suid-binary vulnerabilities

Posted Oct 29, 2010 13:41 UTC (Fri) by marcH (subscriber, #57642) [Link]

> Why? If this is about whole-system security, there will still be binaries with CAP_SETUID (su, sudo, newrole, seunshare, etc).

"Let's not bother making the windows more secure, because the front door sucks anyway".

Actually, let's bother. Because it's progress:
- progress towards the entire perimeter being finally secured.
- some malware knows only about windows. Being hacked once a month is progress compared to twice.

> It absolutely reduces the attack surface in general,...

Agreed!

suid-binary vulnerabilities

Posted Oct 29, 2010 15:14 UTC (Fri) by kees (subscriber, #27264) [Link]

Right, I don't meant to say it shouldn't be done. Getting rid of the setuid bit is a great goal. I was just trying to point out that it does not solve problems like those recently found in glibc. It _does_, of course, kill a whole separate set of problems, and I love that. :) I just don't want people to think dropping setuid bits is a magic bullet for solving all local privilege escalations.

suid-binary vulnerabilities

Posted Oct 28, 2010 17:05 UTC (Thu) by jreiser (subscriber, #11027) [Link]

why isn't this done if it's possible? There are [have been] bigger fish to fry.

suid-binary vulnerabilities

Posted Oct 28, 2010 18:53 UTC (Thu) by RobSeace (subscriber, #4435) [Link]

Oh, and I just realized that if a system were to do this for all setuid binaries,
then it would be very important for the linker to treat these "enhanced capability"
programs just as it would setuid/setgid programs... Ie: don't allow $LD_PRELOAD
and such... Otherwise, of course, it would be trivial for anyone to gain their
enhanced capabilities... Which, while not as bad as gaining root, is still not
something you want to make trivially easy to do...

suid-binary vulnerabilities

Posted Oct 28, 2010 19:55 UTC (Thu) by spender (subscriber, #23067) [Link]

This is exactly what the AT_SECURE auxv entry already does.

-Brad

suid-binary vulnerabilities

Posted Oct 28, 2010 21:24 UTC (Thu) by jengelh (subscriber, #33263) [Link]

>For instance, imagine if ping, instead of being setuid, called into dbus to load a helper daemon

Or just enhance the kernel to enable socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) for unprivileged users, and scrutinize packets sent/received through the socket.

suid-binary vulnerabilities

Posted Oct 29, 2010 7:47 UTC (Fri) by viro (subscriber, #7872) [Link]

Great improvement, that - now ping depends on dbus. Which is to say, that Fine Piece Of Software suddenly becomes mandatory on boxen that used to avoid it just fine.

suid-binary vulnerabilities

Posted Oct 29, 2010 10:59 UTC (Fri) by marcH (subscriber, #57642) [Link]

> Great improvement, that - now ping depends on dbus.

Actually, ping using D-Bus would be such a change that you would rather have new-secure-dbus-user-ping on one hand and good-old-insecure-root-ping on the other hand. Embedded and other single user systems can just run everything as root and use the old one.

If you are serious about security you really need a good IPC on multi-user systems... what would you use instead of D-BUS?

suid-binary vulnerabilities

Posted Oct 31, 2010 15:18 UTC (Sun) by nlucas (subscriber, #33793) [Link]

I don't think ping is a good example for this argument.

It's too simple, so you could also solve this problem by making a static build of ping that can not load any shared library.

In my "non-security guy" perspective that would be enough for most environments.

suid-binary vulnerabilities

Posted Nov 1, 2010 11:17 UTC (Mon) by michaeljt (subscriber, #39183) [Link]

> I don't think ping is a good example for this argument.
>
> It's too simple, so you could also solve this problem by making a static build of ping that can not load any shared library.

I thought that with ELF there was no such thing as a pure statically linked binary.

suid-binary vulnerabilities

Posted Nov 1, 2010 23:34 UTC (Mon) by nix (subscriber, #2304) [Link]

There certainly is! PT_INTERP isn't mandatory: if it's not set, the executable has no interpreter, thus cannot use shared libraries and must be self-contained.

(Also, if pure statically-linked binaries cannot exist, what do you think /lib/ld-linux.so.2 is? If ELF interpreters don't count because they are technically shared objects and relocate themselves, /sbin/sln surely does. No relocation, no PT_INTERP: static as static comes, and on pretty much every system.)

suid-binary vulnerabilities

Posted Nov 1, 2010 23:52 UTC (Mon) by anselm (subscriber, #2796) [Link]

/sbin/sln surely does. No relocation, no PT_INTERP: static as static comes, and on pretty much every system

I'm on Debian sid, and I don't have an executable called »sln« – not in /sbin, not anywhere. Am I missing something?

suid-binary vulnerabilities

Posted Nov 2, 2010 0:14 UTC (Tue) by nix (subscriber, #2304) [Link]

It's part of glibc, and is bloody useful e.g. to put your dynamic linker symlink back in place if something blows it away. Since this is its primary purpose, perhaps some distros don't ship it... but if you don't have that I hope you have sash or busybox or something else statically linked to recover your system in case of disaster. (OK, a boot CD/USB key could do the same job but is somewhat inelegant.)

suid-binary vulnerabilities

Posted Nov 2, 2010 0:17 UTC (Tue) by dlang (subscriber, #313) [Link]

one thing on recent systems is that the name resolution libraries are loaded dynamically, even if you compile a 'static' binary. If those libraries are not available as separate files, in the expected location, name resolution fails.

suid-binary vulnerabilities

Posted Nov 3, 2010 14:58 UTC (Wed) by nix (subscriber, #2304) [Link]

In this case, 'recent' is 'more recent than glibc 2.2'. I haven't seen a glibc 2.2 system for many years. Essentially all current Linux systems work this way. (Usernames as well as hostnames: everything that uses NSS.)

suid-binary vulnerabilities

Posted Nov 3, 2010 23:29 UTC (Wed) by cesarb (subscriber, #6266) [Link]

Does it still happen if you use nscd? Or does it simply open the socket to nscd and lets it load the NSS stuff?

suid-binary vulnerabilities

Posted Nov 4, 2010 0:18 UTC (Thu) by foom (subscriber, #14868) [Link]

Depends on the function. Not all NSS functionality goes through nscd even when it's enabled. I forget the details of which do and which don't, though.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds