|
|
|
|
|
by forcefsck
5385 days ago
|
|
So, again, the exploit was that a telnet session was exporting environment variables. LD_PRELOAD_PATH was just a way to take advantage of the telnetd exploit, which might not be the only way. I think that naming it "The LD_PRELOAD_PATH exploit" is just misguiding. |
|
No, this was a feature. It had been safe in the days of static libraries, it became a problem when the LD_something family of variables was introduced. Besides, the telnet was just a single vector of introducing the LD_. Other examples concern local privilege escalation by calling suid apps:
http://xorl.wordpress.com/2009/12/01/freebsd-ld_preload-secu...
https://www.kb.cert.org/vuls/id/686403
So there definitely exists a family of exploits that rely on bypassing the usual checks on LD_PRELOAD (and other similar variables) to inject malicious lib into protected code.