Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?
levonshe at yandex.com
Fri Nov 10 13:04:22 EST 2017
10.11.2017, 19:24, "valdis.kletnieks at vt.edu" <valdis.kletnieks at vt.edu>:
> On Fri, 10 Nov 2017 16:30:17 +0300, Lev Olshvang said:
>> But the attempt to replace shared object library succeeded, and I do not
>> understand the logic of this decision
> You might want to do an lsof after such an upgrade, and ponder what
> *really* happened.
> Hint 1: How do you do this in a way that doesn't break currently running binaries?
> Hint 2: Do you see the string '(deleted)' in the lsof output? What does it mean?
>> I want to patch my kernel to forbid shared objects live replacement. ( as I
>> said I worry about security issue)
> Attackers doing that is the least of your problems. If your system is
> correctly set up, if an attacker manages to get to a point where this attack is
> feasible, you're *already* in deep trouble even before they do a live
> For bonus points - you're probably worrying about the wrong security issue,
> because you're probably only thinking about the *obvious* problem. The trouble
> is that even if you forbid live replacement of a .so, that's *not* the only
> attack surface.
> Phrack ran an interesting article many years ago on how to inject a module into
> a Linux kernel *even if the kernel was built with CONFIG_MODULE=n*.
> (The important part isn't the exact mechanism - that SucKIT code from 16
> years ago probably won't work on a 4.14 kernel. But it illustrates the out-of-box
> thinking the attacker can use - and that you'll have to defend against.
> How did Emacs in times gone by do an 'unexec()' to write out an executable
> image of itself, as the state was after startup?
> What can you over-write by setting /proc/sys/kernel/core_pattern, forking,
> and then forcing a coredump in the child process?
> Can you combine the techniques to splat a .so that's currently in use?
Thank you for prompt response.
I am afraid you did not quite understand my question.
I am going to patch inode reference count of mapped shared libs to disable overwrite because I do not see any other
solution giving requirements I got - prevent overwrite by simple tools like dd.
I agree with you that is is this is not enough to protect the system, but this is just one line of defense.
I understand that it is hard to not crash running executable by changing lib under the hood, but hackers can repedeately crash
programs until desired result achieved.
I am not seasoned kernel developer, there are a lot of things do not know about kernel.
I would like to consult with list whether increment inode nlink_count in shared libraries in the same way is done for
executable will break things in kernel.
More information about the Kernelnewbies