suid-binary vulnerabilities

Posted Oct 29, 2010 10:59 UTC (Fri) by marcH (subscriber, #57642)
In reply to: suid-binary vulnerabilities by viro
Parent article: Two glibc vulnerabilities

> 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?

to post comments

suid-binary vulnerabilities

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

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 mjthayer (guest, #39183) [Link] (7 responses)

> 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] (6 responses)

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] (1 responses)

/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 (guest, #313) [Link] (3 responses)

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] (2 responses)

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] (1 responses)

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.