| |||||||||||||
|
| |||||||||||||
Stopping the program?Stopping the program?Posted Aug 26, 2004 13:55 UTC (Thu) by kweidner (subscriber, #6483)Parent article: Distribution of security fixes
The ability to stop a program at an arbitrary point can turn a small, difficult window into a wide-open one which can be exploited at leisure. I can't see how this is supposed to happen - as far as I can tell LD_DEBUG generates all its output in the dynamic linking stage of program execution, which is not intermingled with the normal program execution. The symbols don't get resolved one by one as they get used. If a program dynamically loads additional shared libraries at runtime, that's where you could cause a delay, but that doesn't appear to result in anything exploitable other than perhaps a denial of service attack. Also, the original advisory claimed that the address information printed could be used to replace and subvert library functions, something that LD_DEBUG doesn't offer any mechanism for. In general, the entire LD_DEBUG issue doesn't appear to be an exploitable security hole, and is only a harmless information leak about information that's likely to be public anyway. If you want to know how a specific SUID binary works, you can usually find out by trying it yourself by running it on your own system, using the same Linux distribution. All "exploits" mentioned so far require a completely separate security hole that would be sufficient in itself to subvert security, even without using LD_DEBUG. -Klaus
(Log in to post comments)
Stopping the program? Posted Aug 26, 2004 19:32 UTC (Thu) by jreiser (subscriber, #11027) [Link] ... 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.
Stopping the program? Posted Aug 26, 2004 20:12 UTC (Thu) by kweidner (subscriber, #6483) [Link] 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
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.
Well, I'm out for (1) at least; I can't even understand the code, much less patch it.
|
|
||||||||||||