Bug 1222763

Summary: Maybe ldd should be changed to emit a warning and require an extra switch before it runs code from non-system executables
Product: [openSUSE] openSUSE Tumbleweed Reporter: ell1e <el>
Component: SecurityAssignee: Security Team bot <security-team>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Enhancement    
Priority: P5 - None    
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description ell1e 2024-04-15 03:53:40 UTC
I found an interesting write-up about ldd, which prints out the dependencies of an executable:

https://catonmat.net/ldd-arbitrary-code-execution

It contains this interesting observation:

    If you are on Linux, take a look at the ldd executable. [...]
    If you step through it very carefully, you'll notice that the 2nd command 
    gets executed if the program specified to ldd can't be loaded by the ld-
    linux.so loader, and that the 3rd command gets executed if it can.

    One particular case when a program won't be handled by ld-linux.so is when
    it has a different loader than the system's default specified in it's
    .interp ELF section.

This seems to mean basically, when running `ldd ./someprogram` depending on what's inside `./someprogram` that will lead to parts of it actually being run without any further confirmation prompt or warning and without any sandboxing or restrictions.

I would suggest this behavior is in some situations unexpected, which as the blog post points out might be a potential problem. I don't work with linkers enough to suggest a solution that is guaranteed to be feasible to implement and to still work for all the usual cases when needed. But I think something similar to the following behavior would be more expected by the average user:

1. If any traced file being looked at is inside any of /bin /usr/bin /usr/lib, /lib, /usr/lib64, /lib64 then enable handling of different loaders than ld-linux.so including invoking it silently, potentially running arbitrary code from within the binary.

2. If a traced file being looked at is outside of /usr/lib, /lib, /usr/lib64, /lib64 then disable handling of different loaders than ld-linux.so that might rn arbitrary code. If any such different loader would be required, print an error and quit. Unless some special option was used for ldd to allow that, preferably not an environment option since it's easier to pass that without being aware.

My apologies if that's not actually a feasible thing to do, I'm sure smarter minds than me have more useful thoughts on this situation.
Comment 1 hui 2024-04-16 04:07:13 UTC
.

*** This bug has been marked as a duplicate of bug 677787 ***