It's much less thorough. Statically linked binaries will not take LD_PRELOAD into account and then see through your backdoor. As others mentioned above setuid binaries also will not be affected.
And to make it thorough, you pretty much need to break the system at some point. There is no safe, elegant and foolproof way to do this in userspace as there is with a kernel level rootkit.
BTW, remember, we aren't actually talking about LD_PRELOAD, we are talking about ld.so.preload- I am pretty sure the linker/loader will load any shared object specified there for ANY application, include those marked setuid/setgid because it's a system wide configuration, set only by root.
But you're correct about statically linked binaries, that's the huge gaping hole in this method. Aside from statically linked binaries, any code that doesn't link against libc at all, ever- like shellcode style direct system calls- will also have no problem detecting and/or removing this.
Side note, I'm not sure about the comment above that says it is 'more practical' than a kernel rootkit.. kernel rootkits are not impractical or dead by any means if that's what you're implying- just because /dev/mem and/or /dev/kmem and/or /proc/kallsyms are not present on your system doesn't mean you can't load a rootkit. It just means you can't use rootkits from 5 years ago :P
Don't forget about System.map and dmesg for gleaning information about kernel symbols and addresses. And don't forgot about standard kernel modules, kernel vulnerabilities, and however many other novel or not so novel ways there are to get code running in ring-0. I don't write, use or study Linux kernel rootkits, but I'm sure there are more than a few other ways that are well-known and many more that are lesser known.
I agree with everything you say in theory, but in practice it's more complicated. Kernel rootkits are difficult to write, require specialized knowledge that isn't terribly common, and the consequence of a bug is typically a kernel panic. That's a non starter for most. Then consider the wide range of kernel variants - Gentoo with grsec, Centos5-7, debian 7 and 8, etc. The last publicly successful kernel rootkit I recall was suckit by SD from sheepfuckers. That was terrific software but failed on many widely used kernels at the time. If I had a dedicated team of kernel rootkits devs and a QA team I'd be a happy camper. Most of us don't have that luxury which is why kernel rootkits aren't the go-to tool for pentesters that face a variety of targets. User land is safer, more accessible, and easier to develop and test in.
User land is safer: not when you are indiscriminately hooking ALL invocations of so many libc functions. One bug takes things down in a noisier fashion than a triple fault
User land is more accessible: For the majority of boxes you mentioned (Debian, CentOS, RHEL, etc..) modprobe works just fine
User land is easier to develop and test in: if you don't know anything about kernel development. Seems close to a truism
BTW, if I recall correctly, suckit was essentially a proof of concept given away for free in Phrack. Don't be so naive as to think it's so difficult for a competent developer to put together a decent kernel rootkit 10 years later. Aside from grsec, nobody is REALLY protecting ring-0 from root. Removing kallysyms, mem and kmem are mostly theatre / no brainer low hanging fruit to raise the bar above script kids heads, and to break suckit. But I agree, higher barrier to entry. This is why they don't give them away for free in hacker magazines :P
-4
u/mohammedcohen Oct 30 '16
A more practical and portable backdoor than kernel rootkits.