From mboxrd@z Thu Jan 1 00:00:00 1970 From: levonshe@yandex.com (Lev Olshvang) Date: Fri, 10 Nov 2017 21:04:22 +0300 Subject: Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ? In-Reply-To: <16969.1510331047@turing-police.cc.vt.edu> References: <1337441510320617@web44g.yandex.ru> <16969.1510331047@turing-police.cc.vt.edu> Message-ID: <489841510337062@web43g.yandex.ru> To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org 10.11.2017, 19:24, "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 > 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? > > , Hi Valdis, 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.