Stopping the program? [LWN.net]

Stopping the program?

Posted Aug 26, 2004 20:12 UTC (Thu) by kweidner (subscriber, #6483)
In reply to: Stopping the program? by jreiser
Parent article: Distribution of security fixes

False. Nearly all dynamic symbol resolution is done with the equivalent of RTLD_LAZY, which is on-demand. The flags DT_BIND_NOW, DF_BIND_NOW, and DF_1_NOW are used rarely.

I stand corrected and apologize for spreading misinformation. Is the decision to use RDLT_LAZY hardcoded in /lib/ld-linux.so.2 ? Maybe it would make sense to change that to the equivalent of RTLD_NOW for SUID apps for more deterministic behavior, since the delay caused by LD_DEBUG abuse only increases the already present delay for dynamic symbol resolution in the middle of an operation.

-Klaus

(Log in to post comments)

Stopping the program?

Posted Aug 26, 2004 22:55 UTC (Thu) by jreiser (subscriber, #11027) [Link]

RTLD_LAZY is the specified default behavior, and in that sense is hardcoded into ld-linux.so.2. Changing ld-linux.so.2 to use RTLD_NOW for SUID executables seems like a good choice in general. In most cases the intent for an executable to be run SUID is known at build time, so the build itself could put DT_BIND_NOW into the DYNAMIC section, which would achieve the desired effect with no changes required to ld-linux.so.2.

Stopping the program?

Posted Nov 20, 2004 2:59 UTC (Sat) by bluefoxicy (guest, #25366) [Link]

Maybe it would make sense to change that to the equivalent of RTLD_NOW for SUID apps for more deterministic behavior, since the delay caused by LD_DEBUG abuse only increases the already present delay for dynamic symbol resolution in the middle of an operation.

I think that such a patch would be a good idea; RDLT_LAZY looks to me to be less intrusive at runtime, as sporadic minor delays are not easily noticed, while a large chain of such delays are very visible. The targetting of specific entry points (SUID binaries) rather than the entire system (firefox, thunderbird, gnome, X) would be a good way to give the performance benefits of lazy back to the user, which should always be a secondary concern once major security issues are handled.

A few googles right now and a breeze through the source (which confused me and gave me no clue wtf is going on) don't show any obvious indication that current behavior forces RTLD_NOW on SUID or SGID binaries. There are two potential solutions to this issue.

Write a patch
Writing a patch may be the most expedient way to handle this issue, as the glibc people don't seem to have an immediate interest in fixing this, based on the observation that this idea has been out for an adequate time period.
Band together and badger the glibc maintainers until they patch glibc
If nobody else is going to do it, they have to. This may also be required in conjunction with (1), as the glibc team may not want to actually adopt the patch even if somebody else writes it for them.

Well, I'm out for (1) at least; I can't even understand the code, much less patch it.