On Jan 20, jtb <jtbat_private> wrote: >> Another way to execute your code in a trusted path environment is >> exploiting the ability of some programs (e.g. BitchX) to link shared >> objects at run time from a predefined set or even user-supplied ones. >> libdl looks at $LD_LIBRARY_PATH too, so the user can supply his own >> directory with a shared object containing arbitrary code. >I'm not sure if you bothered to _read_ the documentation that went along >with the Phrack articles, because if you had you would have realized that I'm not sure if you and daemon9 bothered to read my message. You are right, the second vulnerability I describe does not fully works because ld.so removes the variables from the environment so libdl can't find them, but it's still possible to ask some programs to dinamically link random shared objects. This "protection" looks like more of a side effect of the ld.so protection than something to deal with libdl attacks. libdl is not not mentioned anywhere in the article AFAICS. e.g. bitchx will happily load any file with libdl: /loaddll /dev/null -:- BitchX+Deb1an: couldn't load file: <garbage>: cannot map file data: Operation not supported by device open("/dev/null", O_RDONLY) = 4 mmap(0, 4096, PROT_READ, MAP_PRIVATE, 4, 0) = -1 ENODEV (Operation not supported by device) close(4) = 0 I'm not attacking anybody, just expressing my point: I believe there are too many ways to bypass TPE schemes to consider them a real barrier against malicious people. -- ciao, Marco
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:29:29 PDT