* Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit @ 2014-06-14 15:35 Steven Honeyman 2014-06-14 15:50 ` Szabolcs Nagy ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Steven Honeyman @ 2014-06-14 15:35 UTC (permalink / raw) To: musl I noticed this by accident (ran ldd as usual without even thinking)... but if you compile with musl-gcc, and use shared instead of static, then ldd can cause different behaviour in the binary (code will execute). It is described here [1] from 2009, on how to modify uclibc to enable this behaviour... musl needs no mods to achieve this! Simple example: $ echo 'void main() { puts("executed"); }' >lddtest.c $ musl-gcc lddtest.c && ldd ./a.out Of course the exploit is only useable if you check for LD_TRACE_LOADED_OBJECTS and do something different in the code if it is set. Thanks, Steven. [1] http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 15:35 Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit Steven Honeyman @ 2014-06-14 15:50 ` Szabolcs Nagy 2014-06-14 15:51 ` Daniel Cegiełka 2014-06-14 16:02 ` Rich Felker 2 siblings, 0 replies; 17+ messages in thread From: Szabolcs Nagy @ 2014-06-14 15:50 UTC (permalink / raw) To: musl * Steven Honeyman <stevenhoneyman@gmail.com> [2014-06-14 16:35:25 +0100]: > I noticed this by accident (ran ldd as usual without even thinking)... > but if you compile with musl-gcc, and use shared instead of static, > then ldd can cause different behaviour in the binary (code will > execute). It is described here [1] from 2009, on how to modify uclibc > to enable this behaviour... musl needs no mods to achieve this! musl never had this problem by design it's only the broken ldd of glibc that tries to execute the binary.. > $ echo 'void main() { puts("executed"); }' >lddtest.c > $ musl-gcc lddtest.c && ldd ./a.out > > Of course the exploit is only useable if you check for > LD_TRACE_LOADED_OBJECTS and do something different in the code if it > is set. works here as expected the environment variables the libc and loader cares about are documented: http://www.musl-libc.org/doc/1.0.0/manual.html (LD_TRACE_LOADED_OBJECTS is not listed there) $ ldd musl libc Version 1.1.2-git-7-g66fcde4 Dynamic Program Loader Usage: ldd [options] [--] pathname $ ldd ./a.out /lib/ld-musl-i386.so.1 (0xb76cd000) libc.so => /lib/ld-musl-i386.so.1 (0xb76cd000) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 15:35 Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit Steven Honeyman 2014-06-14 15:50 ` Szabolcs Nagy @ 2014-06-14 15:51 ` Daniel Cegiełka 2014-06-14 16:03 ` Szabolcs Nagy 2014-06-14 16:02 ` Rich Felker 2 siblings, 1 reply; 17+ messages in thread From: Daniel Cegiełka @ 2014-06-14 15:51 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 864 bytes --] musl checks suid/sgid http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c#n984 Daniel 2014-06-14 17:35 GMT+02:00 Steven Honeyman <stevenhoneyman@gmail.com>: > I noticed this by accident (ran ldd as usual without even thinking)... > but if you compile with musl-gcc, and use shared instead of static, > then ldd can cause different behaviour in the binary (code will > execute). It is described here [1] from 2009, on how to modify uclibc > to enable this behaviour... musl needs no mods to achieve this! > > Simple example: > > $ echo 'void main() { puts("executed"); }' >lddtest.c > $ musl-gcc lddtest.c && ldd ./a.out > > Of course the exploit is only useable if you check for > LD_TRACE_LOADED_OBJECTS and do something different in the code if it > is set. > > Thanks, > Steven. > > [1] http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ > [-- Attachment #2: Type: text/html, Size: 1436 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 15:51 ` Daniel Cegiełka @ 2014-06-14 16:03 ` Szabolcs Nagy 2014-06-14 16:16 ` Rich Felker 0 siblings, 1 reply; 17+ messages in thread From: Szabolcs Nagy @ 2014-06-14 16:03 UTC (permalink / raw) To: musl * Daniel Cegie??ka <daniel.cegielka@gmail.com> [2014-06-14 17:51:43 +0200]: > musl checks suid/sgid > > http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c#n984 > http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c#n1201 this is the relevant line: musl's loader exits before executing main in ldd mode independently of setuid or env vars the checked binary has no control over this at all in glibc the interpreter linked into the binary has to do the right thing.. and it used to fail to do that (and of course if you have a binary with non-glibc interpreter it does the wrong thing with arbitrarily bad consequences..) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 16:03 ` Szabolcs Nagy @ 2014-06-14 16:16 ` Rich Felker 0 siblings, 0 replies; 17+ messages in thread From: Rich Felker @ 2014-06-14 16:16 UTC (permalink / raw) To: musl On Sat, Jun 14, 2014 at 06:03:02PM +0200, Szabolcs Nagy wrote: > * Daniel Cegie??ka <daniel.cegielka@gmail.com> [2014-06-14 17:51:43 +0200]: > > musl checks suid/sgid > > > > http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c#n984 > > > > http://git.musl-libc.org/cgit/musl/tree/src/ldso/dynlink.c#n1201 > > this is the relevant line: musl's loader exits before > executing main in ldd mode independently of setuid or > env vars the checked binary has no control over this > at all Steven Honeyman's original report was in regard to using the glibc ldd utility with musl binaries. This just executes the program normally, but it does not give you any elevated privileges you wouldn't already have by executing it directly. Rich ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 15:35 Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit Steven Honeyman 2014-06-14 15:50 ` Szabolcs Nagy 2014-06-14 15:51 ` Daniel Cegiełka @ 2014-06-14 16:02 ` Rich Felker 2014-06-14 16:10 ` Steven Honeyman 2014-06-14 16:14 ` Solar Designer 2 siblings, 2 replies; 17+ messages in thread From: Rich Felker @ 2014-06-14 16:02 UTC (permalink / raw) To: musl On Sat, Jun 14, 2014 at 04:35:25PM +0100, Steven Honeyman wrote: > I noticed this by accident (ran ldd as usual without even thinking)... > but if you compile with musl-gcc, and use shared instead of static, > then ldd can cause different behaviour in the binary (code will > execute). It is described here [1] from 2009, on how to modify uclibc > to enable this behaviour... musl needs no mods to achieve this! > > Simple example: > > $ echo 'void main() { puts("executed"); }' >lddtest.c > $ musl-gcc lddtest.c && ldd ./a.out > > Of course the exploit is only useable if you check for > LD_TRACE_LOADED_OBJECTS and do something different in the code if it > is set. I fail to see how this is exploiting anything. Running a musl-based program with the glibc ldd utility does the exact same thing as running the musl-based program directly. This does not give you any additional privileges. > [1] http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ This is a social engineering exploit against the administrator. The whole reason it happened is because somebody (not sure who was originally responsible for this mistake) designed their ldd to actually run the program, which is a horrible design. musl's ldd does not do this, and musl does not support LD_TRACE_LOADED_OBJECTS. Yes this makes it easier to make binaries that can be used for social engineering, but it does not expose users of musl to any additional danger, and in my view it actually increases awareness about the danger of glibc ldd since users who run it on musl binaries see immediately what it's doing behind the curtains. (Actually, I think this issue may be fixed in modern glibc ldd, but I'm not sure.) Rich ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 16:02 ` Rich Felker @ 2014-06-14 16:10 ` Steven Honeyman 2014-06-14 16:30 ` Rich Felker 2014-06-14 16:14 ` Solar Designer 1 sibling, 1 reply; 17+ messages in thread From: Steven Honeyman @ 2014-06-14 16:10 UTC (permalink / raw) To: musl I'm not suggesting it is the "fault" of musl - but as in your own words, it provides a social engineering exploit. ldd (GNU libc) 2.19 Copyright (C) 2014 ^ still works with that version. As for "additional danger" - sure it can: if (getenv("LD_TRACE_LOADED_OBJECTS")) eraseHomeDir(); I was suggesting/posting this thinking it be a good idea to check for LD_TRACE_LOADED_OBJECTS and output something e.g. "Please use ldd from musl" then exit? Even without root permissions, a careless user could still have their files wiped out (etc). Thanks, Steven On 14 June 2014 17:02, Rich Felker <dalias@libc.org> wrote: > On Sat, Jun 14, 2014 at 04:35:25PM +0100, Steven Honeyman wrote: >> I noticed this by accident (ran ldd as usual without even thinking)... >> but if you compile with musl-gcc, and use shared instead of static, >> then ldd can cause different behaviour in the binary (code will >> execute). It is described here [1] from 2009, on how to modify uclibc >> to enable this behaviour... musl needs no mods to achieve this! >> >> Simple example: >> >> $ echo 'void main() { puts("executed"); }' >lddtest.c >> $ musl-gcc lddtest.c && ldd ./a.out >> >> Of course the exploit is only useable if you check for >> LD_TRACE_LOADED_OBJECTS and do something different in the code if it >> is set. > > I fail to see how this is exploiting anything. Running a musl-based > program with the glibc ldd utility does the exact same thing as > running the musl-based program directly. This does not give you any > additional privileges. > >> [1] http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ > > This is a social engineering exploit against the administrator. The > whole reason it happened is because somebody (not sure who was > originally responsible for this mistake) designed their ldd to > actually run the program, which is a horrible design. musl's ldd does > not do this, and musl does not support LD_TRACE_LOADED_OBJECTS. Yes > this makes it easier to make binaries that can be used for social > engineering, but it does not expose users of musl to any additional > danger, and in my view it actually increases awareness about the > danger of glibc ldd since users who run it on musl binaries see > immediately what it's doing behind the curtains. (Actually, I think > this issue may be fixed in modern glibc ldd, but I'm not sure.) > > Rich ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 16:10 ` Steven Honeyman @ 2014-06-14 16:30 ` Rich Felker 0 siblings, 0 replies; 17+ messages in thread From: Rich Felker @ 2014-06-14 16:30 UTC (permalink / raw) To: musl On Sat, Jun 14, 2014 at 05:10:40PM +0100, Steven Honeyman wrote: > I'm not suggesting it is the "fault" of musl - but as in your own > words, it provides a social engineering exploit. > > ldd (GNU libc) 2.19 > Copyright (C) 2014 > > ^ still works with that version. As for "additional danger" - sure it > can: if (getenv("LD_TRACE_LOADED_OBJECTS")) eraseHomeDir(); > > I was suggesting/posting this thinking it be a good idea to check for > LD_TRACE_LOADED_OBJECTS and output something e.g. "Please use ldd from > musl" then exit? > Even without root permissions, a careless user could still have their > files wiped out (etc). It's inherently unsafe to run glibc ldd on binaries you don't trust: it's equivalent to running the binary and giving it full access to the invoker's privileges. For musl to suppress this as you suggested does not protect anyone. An attacker making a malicious binary can just modify musl (or just make a static-linked binary) for use in the attack. All that processing LD_TRACE_LOADED_OBJECTS would do is prevent non-malicious binaries from running when it's set, which itself could be a source of exploits (e.g. arranging for a script not to execute a command it should by having LD_TRACE_LOADED_OBJECTS in the environment when the command is run; this could work especially well on systems with a mix of static and dynamic binaries where only the dynamic binaries would be suppressed). Rich ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 16:02 ` Rich Felker 2014-06-14 16:10 ` Steven Honeyman @ 2014-06-14 16:14 ` Solar Designer 2014-06-14 16:24 ` Rich Felker 1 sibling, 1 reply; 17+ messages in thread From: Solar Designer @ 2014-06-14 16:14 UTC (permalink / raw) To: musl Rich, On Sat, Jun 14, 2014 at 12:02:43PM -0400, Rich Felker wrote: > (Actually, I think > this issue may be fixed in modern glibc ldd, but I'm not sure.) IIRC, we have this worked around in patched glibc's ldd on Owl by having it always explicitly run the program through /lib/ld-linux.so.2, which obviously does interpret its env vars that the ldd script sets. That ldd script assumes glibc's /lib/ld-linux.so.2 anyway (env vars, exit codes). I don't know why upstream glibc would not(?) patch the issue that way. It's a trivial change. Is there some WONTFIX for this in glibc Bugzilla already? Sounds like material for your blog if so. ;-) Alexander ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 16:14 ` Solar Designer @ 2014-06-14 16:24 ` Rich Felker 2014-06-14 16:27 ` Steven Honeyman 2014-06-14 17:24 ` Solar Designer 0 siblings, 2 replies; 17+ messages in thread From: Rich Felker @ 2014-06-14 16:24 UTC (permalink / raw) To: musl On Sat, Jun 14, 2014 at 08:14:01PM +0400, Solar Designer wrote: > Rich, > > On Sat, Jun 14, 2014 at 12:02:43PM -0400, Rich Felker wrote: > > (Actually, I think > > this issue may be fixed in modern glibc ldd, but I'm not sure.) > > IIRC, we have this worked around in patched glibc's ldd on Owl by having > it always explicitly run the program through /lib/ld-linux.so.2, which > obviously does interpret its env vars that the ldd script sets. That ldd > script assumes glibc's /lib/ld-linux.so.2 anyway (env vars, exit codes). One improvement to this, if one wants to support multiple glibc installations with different interpreters, would be parsing the PT_INTERP from the binary, then exec'ing it in a way that inhibits suid if the pointed-to binary happens to be suid. (One idea is open+fstat+fexecve; another is ptrace+exec, where ptrace just serves to inhibit suid.) > I don't know why upstream glibc would not(?) patch the issue that way. > It's a trivial change. Is there some WONTFIX for this in glibc Bugzilla > already? Sounds like material for your blog if so. ;-) There was a new patch for this issue on the libc-alpha list back in March of this year, but I don't think it's been committed yet. See "[PATCH] Never try to execute the file in ldd", Message-ID: <mvma9cfobqi.fsf@hawking.suse.de>. Rich ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 16:24 ` Rich Felker @ 2014-06-14 16:27 ` Steven Honeyman 2014-06-14 16:42 ` Szabolcs Nagy 2014-06-14 17:24 ` Solar Designer 1 sibling, 1 reply; 17+ messages in thread From: Steven Honeyman @ 2014-06-14 16:27 UTC (permalink / raw) To: musl A quick search suggests it's been "patched" in Debian, Redhat, Owl glibc packages at least, but not upstream yet for some reason. If that libc-alpha commit makes it through (eventually!) then agreed, this is no longer an issue. On 14 June 2014 17:24, Rich Felker <dalias@libc.org> wrote: > On Sat, Jun 14, 2014 at 08:14:01PM +0400, Solar Designer wrote: >> Rich, >> >> On Sat, Jun 14, 2014 at 12:02:43PM -0400, Rich Felker wrote: >> > (Actually, I think >> > this issue may be fixed in modern glibc ldd, but I'm not sure.) >> >> IIRC, we have this worked around in patched glibc's ldd on Owl by having >> it always explicitly run the program through /lib/ld-linux.so.2, which >> obviously does interpret its env vars that the ldd script sets. That ldd >> script assumes glibc's /lib/ld-linux.so.2 anyway (env vars, exit codes). > > One improvement to this, if one wants to support multiple glibc > installations with different interpreters, would be parsing the > PT_INTERP from the binary, then exec'ing it in a way that inhibits > suid if the pointed-to binary happens to be suid. (One idea is > open+fstat+fexecve; another is ptrace+exec, where ptrace just serves > to inhibit suid.) > >> I don't know why upstream glibc would not(?) patch the issue that way. >> It's a trivial change. Is there some WONTFIX for this in glibc Bugzilla >> already? Sounds like material for your blog if so. ;-) > > There was a new patch for this issue on the libc-alpha list back in > March of this year, but I don't think it's been committed yet. See > "[PATCH] Never try to execute the file in ldd", Message-ID: > <mvma9cfobqi.fsf@hawking.suse.de>. > > Rich ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 16:27 ` Steven Honeyman @ 2014-06-14 16:42 ` Szabolcs Nagy 2014-06-14 17:11 ` Rich Felker 0 siblings, 1 reply; 17+ messages in thread From: Szabolcs Nagy @ 2014-06-14 16:42 UTC (permalink / raw) To: musl * Steven Honeyman <stevenhoneyman@gmail.com> [2014-06-14 17:27:33 +0100]: > > If that libc-alpha commit makes it through (eventually!) then agreed, > this is no longer an issue. > i dont see how this is an issue it is simply not the responsibility of musl to fix or work around such bugs in other projects even if it were dangerous ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 16:42 ` Szabolcs Nagy @ 2014-06-14 17:11 ` Rich Felker 0 siblings, 0 replies; 17+ messages in thread From: Rich Felker @ 2014-06-14 17:11 UTC (permalink / raw) To: musl On Sat, Jun 14, 2014 at 06:42:56PM +0200, Szabolcs Nagy wrote: > * Steven Honeyman <stevenhoneyman@gmail.com> [2014-06-14 17:27:33 +0100]: > > > > If that libc-alpha commit makes it through (eventually!) then agreed, > > this is no longer an issue. > > > > i dont see how this is an issue > > it is simply not the responsibility of musl to fix or > work around such bugs in other projects even if it were > dangerous Indeed, I see the request to "fix" this on musl's side as a request for something that falls midway between security-through-obscurity and DRM. It's not musl's responsibility to make it difficult to write malicious programs any more than it's the compiler's responsibility to do so, and of couse since musl is open source, it's not even possible to actually prevent users from doing so. Rich ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 16:24 ` Rich Felker 2014-06-14 16:27 ` Steven Honeyman @ 2014-06-14 17:24 ` Solar Designer 2014-06-14 18:29 ` Rich Felker 1 sibling, 1 reply; 17+ messages in thread From: Solar Designer @ 2014-06-14 17:24 UTC (permalink / raw) To: musl On Sat, Jun 14, 2014 at 12:24:43PM -0400, Rich Felker wrote: > On Sat, Jun 14, 2014 at 08:14:01PM +0400, Solar Designer wrote: > > On Sat, Jun 14, 2014 at 12:02:43PM -0400, Rich Felker wrote: > > > (Actually, I think > > > this issue may be fixed in modern glibc ldd, but I'm not sure.) > > > > IIRC, we have this worked around in patched glibc's ldd on Owl by having > > it always explicitly run the program through /lib/ld-linux.so.2, which > > obviously does interpret its env vars that the ldd script sets. That ldd > > script assumes glibc's /lib/ld-linux.so.2 anyway (env vars, exit codes). > > One improvement to this, if one wants to support multiple glibc > installations with different interpreters, would be parsing the > PT_INTERP from the binary, then exec'ing it in a way that inhibits > suid if the pointed-to binary happens to be suid. (One idea is > open+fstat+fexecve; another is ptrace+exec, where ptrace just serves > to inhibit suid.) I don't understand what scenario you have in mind. When we invoke the interpreter explicit, we already inhibit a possible SUID/SGID on the target binary. > > I don't know why upstream glibc would not(?) patch the issue that way. > > It's a trivial change. Is there some WONTFIX for this in glibc Bugzilla > > already? Sounds like material for your blog if so. ;-) > > There was a new patch for this issue on the libc-alpha list back in > March of this year, but I don't think it's been committed yet. See > "[PATCH] Never try to execute the file in ldd", Message-ID: > <mvma9cfobqi.fsf@hawking.suse.de>. Yes, it's the same patch we've been using for years. https://sourceware.org/ml/libc-alpha/2014-03/msg00713.html BTW, it wasn't the social engineering attack possibility that provided the initial motivation for us to patch the issue: * Wed Jun 12 2002 Solar Designer <solar-at-owl.openwall.com> - ldd(1) will no longer try to invoke programs directly, even when it seems like that would work. The dynamic linker will be invoked as a program instead. This makes a difference when the program is SGID and is being ldd'ed by root. If the program was executed directly, glibc would detect its SGID status and drop LD_* variables, resulting in the program being actually started rather than ldd'ed. Thanks to Dmitry V. Levin of ALT Linux for suggesting this solution. Maybe stock glibc doesn't ignore LD_TRACE_LOADED_OBJECTS for SGID (nor for SUID?), which is why it didn't(?) have that other issue exposed. I notice that Dmitry has already commented in that recent libc-alpha thread as well. Alexander ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 17:24 ` Solar Designer @ 2014-06-14 18:29 ` Rich Felker 2014-06-14 18:37 ` Solar Designer 0 siblings, 1 reply; 17+ messages in thread From: Rich Felker @ 2014-06-14 18:29 UTC (permalink / raw) To: musl On Sat, Jun 14, 2014 at 09:24:11PM +0400, Solar Designer wrote: > On Sat, Jun 14, 2014 at 12:24:43PM -0400, Rich Felker wrote: > > On Sat, Jun 14, 2014 at 08:14:01PM +0400, Solar Designer wrote: > > > On Sat, Jun 14, 2014 at 12:02:43PM -0400, Rich Felker wrote: > > > > (Actually, I think > > > > this issue may be fixed in modern glibc ldd, but I'm not sure.) > > > > > > IIRC, we have this worked around in patched glibc's ldd on Owl by having > > > it always explicitly run the program through /lib/ld-linux.so.2, which > > > obviously does interpret its env vars that the ldd script sets. That ldd > > > script assumes glibc's /lib/ld-linux.so.2 anyway (env vars, exit codes). > > > > One improvement to this, if one wants to support multiple glibc > > installations with different interpreters, would be parsing the > > PT_INTERP from the binary, then exec'ing it in a way that inhibits > > suid if the pointed-to binary happens to be suid. (One idea is > > open+fstat+fexecve; another is ptrace+exec, where ptrace just serves > > to inhibit suid.) > > I don't understand what scenario you have in mind. When we invoke the > interpreter explicit, we already inhibit a possible SUID/SGID on the > target binary. I was thinking of scenarios where the interpreter is suid, but that's probably actually not what we need to be worried about. The attack is where the interpreter is provided by the user who asked you to invoke ldd. There are some sanity checks that could still be done with the open+fstat+fexecve approach, but I don't think they can be made sufficiently complete so the best approach is probably just printing an error (and giving the user an option to --force) if PT_INTERP does not match what ldd expects it to be. > BTW, it wasn't the social engineering attack possibility that provided > the initial motivation for us to patch the issue: > > * Wed Jun 12 2002 Solar Designer <solar-at-owl.openwall.com> > - ldd(1) will no longer try to invoke programs directly, even when it > seems like that would work. The dynamic linker will be invoked as a > program instead. This makes a difference when the program is SGID and > is being ldd'ed by root. If the program was executed directly, glibc > would detect its SGID status and drop LD_* variables, resulting in the > program being actually started rather than ldd'ed. Thanks to Dmitry > V. Levin of ALT Linux for suggesting this solution. > > Maybe stock glibc doesn't ignore LD_TRACE_LOADED_OBJECTS for SGID (nor > for SUID?), which is why it didn't(?) have that other issue exposed. Stock glibc accepts all of the LD_* environment variables for suid/sgid, including dangerous ones, and only applies weak restrictions to them (for example it even allows LD_PRELOAD after imposing some insufficient conditions on the library to be preloaded). > I notice that Dmitry has already commented in that recent libc-alpha > thread as well. Ah yes. :) Rich ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 18:29 ` Rich Felker @ 2014-06-14 18:37 ` Solar Designer 2014-06-14 19:39 ` Rich Felker 0 siblings, 1 reply; 17+ messages in thread From: Solar Designer @ 2014-06-14 18:37 UTC (permalink / raw) To: musl On Sat, Jun 14, 2014 at 02:29:42PM -0400, Rich Felker wrote: > Stock glibc accepts all of the LD_* environment variables for > suid/sgid, including dangerous ones, and only applies weak > restrictions to them (for example it even allows LD_PRELOAD after > imposing some insufficient conditions on the library to be preloaded). Oh, I recall it allows LD_PRELOAD on libraries that are placed in system directories and are themselves marked with the SUID bit. IIRC, libc5's dynamic linker had that, too. Alexander ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit 2014-06-14 18:37 ` Solar Designer @ 2014-06-14 19:39 ` Rich Felker 0 siblings, 0 replies; 17+ messages in thread From: Rich Felker @ 2014-06-14 19:39 UTC (permalink / raw) To: musl On Sat, Jun 14, 2014 at 10:37:25PM +0400, Solar Designer wrote: > On Sat, Jun 14, 2014 at 02:29:42PM -0400, Rich Felker wrote: > > Stock glibc accepts all of the LD_* environment variables for > > suid/sgid, including dangerous ones, and only applies weak > > restrictions to them (for example it even allows LD_PRELOAD after > > imposing some insufficient conditions on the library to be preloaded). > > Oh, I recall it allows LD_PRELOAD on libraries that are placed in system > directories and are themselves marked with the SUID bit. IIRC, libc5's > dynamic linker had that, too. Yes, I don't recall if there are other cases it allows or not, but I think as long as you avoid setting the suid bit on any libraries, the allowance seems safe. On the other hand, any actual use of this feature is probably insecure. Some issues that come to mind, assuming suid libraries are present: - After an upgrade, if the old library is left behind, an attacker can force the old version to be loaded in place of the new one in order to exploit bugs that are fixed in the new version. - If there exists any suid library which contains symbol names which overlap with symbols that appear in other libraries, preloading it can interpose definitions for these symbols which have nothing to do with the actual functions/objects the application is trying to use (from another library) and thereby cause runaway incorrect behavior in an suid program. I wouldn't be surprised if there are more related issues too.. Rich ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2014-06-14 19:39 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-06-14 15:35 Binaries compiled with musl (1.1.2) are vulnerable to an ancient ldd exploit Steven Honeyman 2014-06-14 15:50 ` Szabolcs Nagy 2014-06-14 15:51 ` Daniel Cegiełka 2014-06-14 16:03 ` Szabolcs Nagy 2014-06-14 16:16 ` Rich Felker 2014-06-14 16:02 ` Rich Felker 2014-06-14 16:10 ` Steven Honeyman 2014-06-14 16:30 ` Rich Felker 2014-06-14 16:14 ` Solar Designer 2014-06-14 16:24 ` Rich Felker 2014-06-14 16:27 ` Steven Honeyman 2014-06-14 16:42 ` Szabolcs Nagy 2014-06-14 17:11 ` Rich Felker 2014-06-14 17:24 ` Solar Designer 2014-06-14 18:29 ` Rich Felker 2014-06-14 18:37 ` Solar Designer 2014-06-14 19:39 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).