Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?

valdis.kletnieks at vt.edu valdis.kletnieks at vt.edu
Fri Nov 10 11:24:07 EST 2017


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
replacement.

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*.

http://phrack.org/issues/58/7.html#article

(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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20171110/59b70f54/attachment.bin 


More information about the Kernelnewbies mailing list