oss-sec mailing list archives
Re: Fixing the glibc runtime linker
From: Tim Brown <tmb () 65535 com>
Date: Fri, 20 Feb 2015 07:53:58 +0000
On Friday 20 February 2015 08:14:47 Paul Pluzhnikov wrote:
On Thu, Feb 19, 2015 at 11:57 PM, Rich Felker <dalias () libc org> wrote:How is an empty or relative rpath easy?all: foo foo: foo.c ${CC} -Wl,-rpath=${VAR} -o $@ $^ If VAR is unset, or set to relative path, resulting binary will be "bad". Quoting original Tim's message:Over the last couple of years I've spent a good deal of time dealing with vendors who, for one reason or another have shipped binaries where it is possible to inject "untrusted" code into running processes, notably but not exclusively via DT_RPATH.I can easily believe that such binaries are fairly common.
That covers the DT_RPATH/DT_RUNPATH case adequately, here's a (similar) example for LD_LIBRARY_PATH: * https://www.nth-dimension.org.uk/blog.php?id=87 The point is that I don't think it needs to be this way. As I said in my initial post, Solaris has had saner (although IMO not perhaps perfect) handling of this class of bug for years. If you look at the cases I've publicly reported over the last few years, Solaris wouldn't have been affected by any of them (despite what at least one vendor has said) because it does the sensible thing. I'll certainly have another look at the non-priv'd case (I'm leaning towards having $RELATIVE (new) and $ORIGIN honoured for them (despite the fact that it compromises the basic premis a little)) but I don't see a good argument for not protecting setuid/setgid binaries in the manner described. Having guaged appetite, I don't think the objections are insurmountable so it's worth progressing with. I guess, having kicked this bug class for a while (and even put out a paper looking at the wider issue of linker behaviour), I'm trying to put my money where my mouth is. That's what we're supposed to do, no? Find fixes rather than just keep pointing out problems. To Rich specifically, I'm keen to get some kind of fix adopted, so once I've had a chance to mull over the logging and necessary cases for relative paths a little more, I'll circulate a revised patch and we can kick it around further. I don't know what your thoughts are on MUSL, but I'd certainly prefer to get buy in from you guys, if at all possible. Tim -- Tim Brown <mailto:tmb () 65535 com>
Attachment:
signature.asc
Description: This is a digitally signed message part.
Current thread:
- Fixing the glibc runtime linker Tim Brown (Feb 19)
- Re: Fixing the glibc runtime linker Stuart Gathman (Feb 19)
- Re: Fixing the glibc runtime linker Tim Brown (Feb 19)
- Re: Fixing the glibc runtime linker Paul Pluzhnikov (Feb 19)
- Re: Fixing the glibc runtime linker Tim Brown (Feb 19)
- Re: Fixing the glibc runtime linker Paul Pluzhnikov (Feb 19)
- Re: Fixing the glibc runtime linker Rich Felker (Feb 19)
- Re: Fixing the glibc runtime linker Paul Pluzhnikov (Feb 19)
- Re: Fixing the glibc runtime linker Rich Felker (Feb 19)
- Re: Fixing the glibc runtime linker Paul Pluzhnikov (Feb 20)
- Re: Fixing the glibc runtime linker Tim Brown (Feb 20)
- Re: Fixing the glibc runtime linker Rich Felker (Feb 20)
- Re: Fixing the glibc runtime linker Paul Pluzhnikov (Feb 20)
- Re: Fixing the glibc runtime linker Rich Felker (Feb 20)
- Re: Fixing the glibc runtime linker Tim Brown (Feb 19)
- Re: Fixing the glibc runtime linker Stuart Gathman (Feb 19)
- Re: Fixing the glibc runtime linker Paul Pluzhnikov (Feb 20)
- Re: Fixing the glibc runtime linker Rich Felker (Feb 21)