Stopping the program?
Stopping the program?
Posted Aug 26, 2004 19:32 UTC (Thu) by jreiser (subscriber, #11027)In reply to: Stopping the program? by kweidner
Parent article: Distribution of security fixes
... the dynamic linking stage of program execution, which is not intermingled with the normal program execution.
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.
The symbols don't get resolved one by one as they get used.
False. That is exactly how they get resolved nearly all the time.
... the address information printed could be used to replace and subvert library functions.
Yes, getting the addresses can help pinpoint where to attack. The address may vary by library build (Linux distribution) or mmap() randomization.
In general, the entire LD_DEBUG issue doesn't appear to be an exploitable security hole, ...
The ability to block the process (by blocking the output stream from LD_DEBUG) widens the window during which an existing time-dependent weakness may be exploited.
a completely separate security hole that would be sufficient in itself to subvert security
Sometimes holes are time-dependent, and the ability to "stop the clock" can make a 1 millisecond window into eternity.
Posted Aug 26, 2004 20:12 UTC (Thu)
by kweidner (guest, #6483)
[Link] (2 responses)
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
Posted Aug 26, 2004 22:55 UTC (Thu)
by jreiser (subscriber, #11027)
[Link]
Posted Nov 20, 2004 2:59 UTC (Sat)
by bluefoxicy (guest, #25366)
[Link]
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.
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.
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.
Stopping the program?
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.
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?
Stopping the program?
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.