use of ldd and best practices improvements

[prabhu]

Came across this neat project. I am the author of a similar but more comprehensive tool that can generate a full sbom.

Noticed a few improvement opportunities in this project.

Use of unsafe commands like ldd

It is never a good idea to run commands like ldd, strace, and strings on malicious binaries directly. Below is an extract from the man pages for ldd.

 Security
       Be aware that in some circumstances (e.g., where the program specifies an ELF interpreter other than ld-linux.so), some versions of ldd may attempt to obtain the dependency information by attempting
       to directly execute the program, which may lead to the execution of whatever code is defined in the program’s ELF interpreter, and perhaps to execution of the program itself.   (Before  glibc  2.27,
       the upstream ldd implementation did this for example, although most distributions provided a modified version that did not.)

       Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code.  A safer alternative when dealing with untrusted executables is:

           $ objdump -p /path/to/program | grep NEEDED

concatenated strings passed to os.popen

https://github.com/stolk/sotrace/blob/main/sotrace.py#L20
https://github.com/stolk/sotrace/blob/main/sotrace.py#L31

This coding style could lead to injection vulnerabilities and must be avoided. Construct the arguments manually with shlex split and use with subprocess methods that accept the command and args separately. There could be other better ways to implement this.

Good luck!

[stolk]

So, the objdump command only shows the names of the dependencies, but does not resolve them, so I do not know where they are pointing to.

[prabhu]

@stolk

ldconfig --print-cache

ldd can also resolve the indirect dependencies. Best to offer a cli option so that users can explicitly run the command if they are interested in indirect deps as well.