Comment by jcgl
1 day ago
What makes ss different?
In any case, interesting to think of shared libraries (specifically shared libc) as a risk here. Makes sense, but I hadn't thought about it before.
That said, I'm having a hard time doing a threat model where you worry about an attacker only setting LD_PRELOAD but not modifying PATH. The latter is more general and can screw you with all programs (doesn't cover shell builtins, but it's not like those would just be one more step).
ss obtains the connections information via netlink directly from the kernel (besides parsing /proc):
https://manpages.debian.org/bookworm/manpages/sock_diag.7.en...
https://github.com/vishvananda/netlink/blob/main/inet_diag.g...
Not many rootkits tamper the netlink channel, so in most cases it's a bit more reliable.
Nowadays, there's only one rootkit that can hide itself so perfectly: the Singularity rootkit. It also hides from auditd by using netlink_unicast hooking and other evasive functionalities. Analyzing a machine compromised with Singularity loaded is a real headache, since it prevents memory dumps for analysis.
https://github.com/MatheuZSecurity/Singularity
Okay yeah, sure. So it's not intrinsically more reliable or anything, it's just not specifically vulnerable to LD_PRELOAD. And it's not clear to me why LD_PRELOAD would be a particularly interesting attack vector, but maybe that's just my ignorance.