[HN Gopher] Never run ldd on unknown executables
       ___________________________________________________________________
        
       Never run ldd on unknown executables
        
       Author : xk3
       Score  : 55 points
       Date   : 2023-07-23 21:01 UTC (1 hours ago)
        
 (HTM) web link (catonmat.net)
 (TXT) w3m dump (catonmat.net)
        
       | dwheeler wrote:
       | This not new info, but it's good to tell others.
       | 
       | My "Program Librarues HOWTO" says this:
       | 
       | "Beware: do not run ldd on a program you don't trust. As is
       | clearly stated in the ldd(1) manual, ldd works by (in certain
       | cases) by setting a special environment variable (for ELF
       | objects, LD_TRACE_LOADED_OBJECTS) and then executing the program.
       | It may be possible for an untrusted program to force the ldd user
       | to run arbitrary code (instead of simply showing the ldd
       | information). So, for safety's sake, don't use ldd on programs
       | you don't trust to execute."
       | 
       | https://dwheeler.com/program-library/Program-Library-HOWTO/x...
       | 
       | I believe that doc dates from 2000. This info wasn't new then
       | either, it was specifically documented in its man page.
        
       | KolmogorovComp wrote:
       | Article is dated 2009.
       | 
       | Previous discussions:
       | 
       | - [2009] https://news.ycombinator.com/item?id=902958
       | 
       | - [2015] https://news.ycombinator.com/item?id=9629667
       | 
       | - [2022] https://news.ycombinator.com/item?id=30033807
       | 
       | Also formatting inside code-block is broken
        
         | a1o wrote:
         | Is the mentioned issue in the article still true today?
        
       | thriftwy wrote:
       | I believe I saw a simple shell script based on nm or binutils
       | which could do a safe ldd on any executable, including
       | executables for different platforms.
       | 
       | Update: Here seems to be one example:
       | https://gist.github.com/jerome-pouiller/c403786c1394f53f44a3...
        
         | nwellnhof wrote:
         | This seems to be based on readelf.
        
         | yakubin wrote:
         | It's _readelf_ , but it will only list libs which are declared
         | in the ELF of the executable. It won't list libraries loaded at
         | startup with _dlopen(3)_ , unlike _ldd_. I 'm also not sure, if
         | this script will recurse, but I suspect not. _ldd_ will print
         | libraries loaded recursively.
        
       | 1vuio0pswjnm7 wrote:
       | None of the previous discussions on HN mentioned using readelf
       | instead of ldd.
       | 
       | Whenever I want to quickly check for dynamically linked libraries
       | in a program, I use                  readelf -d program
       | 
       | The use case I have is that I want to know what are the
       | dependencies the program needs from the host system.
        
         | wyldfire wrote:
         | That's great, but unlike ldd, readelf won't walk the list of
         | dependencies recursively.
        
       | evgpbfhnr wrote:
       | (the various implementations of) lddtree also don't have this
       | "feature" as they all use readelf or similar (EDIT: and unlike
       | readelf -d, will recurse through dependencies like ldd does)
       | 
       | I considered that rather well known though...
        
         | djbusby wrote:
         | I just learned today! Thanks.
        
       | greatfilter251 wrote:
       | [dead]
        
       | throwawaaarrgh wrote:
       | I get that it's important that we call out exploitable situations
       | like this, but it's also kind of moot. There are so many ways to
       | exploit modern systems you can just rustle around in a bag of
       | exploits and one will work. Known executable, unknown, doesn't
       | matter. Not even using a VM will keep you safe. Not even RBAC.
       | 
       | What's easier and more reliable is to work in terms of risks.
       | It's fine if you get exploited, as long as the access you have to
       | sensitive systems is limited, and those sensitive systems have
       | backups, and you can't delete those backups, you can re-deploy
       | systems from scratch using automation if you get compromised,
       | automatically rotate credentials, etc.
       | 
       | Lower the overall risk by setting everything up so the worst case
       | scenario isn't that bad. Then you don't have to worry so much
       | about an "unknown executable" because even if it gets exploited
       | the attacker can't cause too much damage.
        
         | causality0 wrote:
         | The number one method of security, at least for power users, is
         | user behavior. Look at URLs you might visit critically. Don't
         | run random-ass code. Keep an eye out for being taken advantage
         | of.
        
       ___________________________________________________________________
       (page generated 2023-07-23 23:00 UTC)