Hacker News new | ask | show | jobs
by danielhlockard 247 days ago
dear lord. This is not new. ld_preload to do things like this existed even back when I was doing Cyber Defense Competitions at Iowa State back in '07
3 comments

Yep. Every few months, someone learns about this, thinks they've made a new discovery, and writes a breathless blog post imagining the possibilities of what can be done with it.

Spoiler alert, you almost certainly have been completely pwned already if someone can set LD_PRELOAD or modify /etc/ld.so.conf.

LD_PRELOAD "works as designed" but people who don't know about it often make false assumptions, leading to exploitable bugs.

One such assumption is "if /bin/foo is a trustworthy executable then any process with /proc/pid/exe pointing to /bin/foo is trustworthy"

Exactly, that is our thought process!

We know that this isn't anything revolutionary, but most people assume that this kind of thing can't happen, so we wrote a blog post about it.

Please describe the scenario where someone needs to make the assumption you described and it is reasonable to expect that they are unaware that symbolic links could be changed by a third party library?
I know one example off the top of my head, but it's part of an exploit chain I haven't got around to reporting yet ;)

What's the relevance of symlinks here?

Maybe I misunderstood your argument, but /proc/[pid]/exe is a symlink in Linux 2.2 and later (so virtually all running instances of Linux today).

That said, your example doesn't make much sense to me. I'd be willing to bet a lot of money that the authors of the exploit chain you mentioned are aware of LD_PRELOAD and /etc/ld.so.conf.

I remember using LD_PRELOAD for reverse engineering Linux binary-only apps in the late 90's so it's likely from much earlier than that, always has been a neat trick
It was also a way to defeat license managers for UNIX software back in the day…
It’s how I got my “license” for Apple’s discontinued Macintosh Application Environment back in the day.