Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?
Hi list The reason for my question is mainly security context. Here the story If you ever tried to replace executable file by new image the message executable is busy appeared and operation fails. But the attempt to replace shared object library succeeded, and I do not understand the logic of this decision. Besides to be security hole, I do not see any legitimate use except of live patching of shared object. I do not know whether production or mission critical system may take a risk of live patching, but development system would do a library update by stopping dependent application first. I saw in kernel archives that some years ago the decision was made to withdraw restriction on shared object live replacement and I would like to know the what what were the reasons because I want to patch my kernel to forbid shared objects live replacement. ( as I said I worry about security issue) Regards, Lev
I have a possible explanation from a distribution perspective. lets say that you have a binary bin.elf that uses a.so and b.so. A.so is packaged in a.deb and b is packaged in b.deb and bin.elf bin.deb. When you are installing/upgrading bin.deb, the package knows how to stop/start bin.elf, so you can stop, upgrade, start When you are installing/upgrading b.deb the package does not know how many binaries are using b.so. It would be pretty nasty to do a kill $(lsof | grep), because there are some services that require some extra steps to turn them on. There is probably another explanation from other perspectives. Cheers! On Fri, Nov 10, 2017 at 2:30 PM, Lev Olshvang <levonshe@yandex.com> wrote:
Hi list
The reason for my question is mainly security context.
Here the story If you ever tried to replace executable file by new image the message executable is busy appeared and operation fails.
But the attempt to replace shared object library succeeded, and I do not understand the logic of this decision.
Besides to be security hole, I do not see any legitimate use except of live patching of shared object. I do not know whether production or mission critical system may take a risk of live patching, but development system would do a library update by stopping dependent application first.
I saw in kernel archives that some years ago the decision was made to withdraw restriction on shared object live replacement and I would like to know the what what were the reasons because I want to patch my kernel to forbid shared objects live replacement. ( as I said I worry about security issue)
Regards, Lev
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Ricardo Ribalda
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?
10.11.2017, 19:24, "valdis.kletnieks@vt.edu" <valdis.kletnieks@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.
On Fri, 10 Nov 2017 21:04:22 +0300, Lev Olshvang said:
I am going to patch inode reference count of mapped shared libs
Congrats. You just corrupted your file system. Hint 1: What happens if you decrement the count by one unnecessarily, and later on, probably during system shutdown, the reference count drops to zero instead of one? Hint 2: What happens if you incremented the count, and at system shutdown, there's still a reference left when the kernel tries to unmount and sync the filesystem?
On Tue, 14 Nov 2017 14:18:42 +0300, Lev Olshvang said:
The difference between executable and file that executable may crash. while shared lib can not.
Oh, a shared lib can indeed crash (or more correctly cause a crash in the process that is using it).
Still there are unknown for me what happen with opened files and mmaped files when crash occurs
Same thing as an executable or a mapped shared library (.so's are just mmap() under the covers), Reference counts are reference counts.
I used to think that kernel decrease reference counts and closes files, whether application exits normally or crashed.
Right. And you change those reference counts on your own at your own peril.
Now I add some facts about executables from kernel code: fss/binfmt_misc.c: deny_write_access(interp_file); fs/exec.c: err = deny_write_access(file); fs/exec.c: ret = deny_write_access(file); And I found following explanatioin in old kernel list archive: https://lists.gt.net/linux/kernel/222875 The reason the kernel refuses to honour it, is that MAP_DENYWRITE is an
excellent DoS-vehicle - you just mmap("/etc/passwd") with MAP_DENYWRITE, and even root cannot write to it.. Vary nasty.
Right - so DENYWRITE is restricted to executables (where it makes sense anyhow) However, shared libraries are just mmap() - so there's no easy way to say "only allow DENYWRITE for .so images". (Hint - a shared library doesn't have to be called something.so - and in fact is usually 'something.so.versionstring")
And I still confused because shared libraries are mapped with PROT_EXEC flag and so they differ from regular file like /etc/passwd and generally have -r-x file system permissions.
Actually, most shared libraries will end up with several mmap() segments - one for .txt, one for .bss (uninitialized variables), and one for .data (initialized variables) - and they will be mapped with different flags. Do an 'strace /bin/echo foo' and ponder what actually happens.
On Fri, Nov 10, 2017 at 8:30 AM, Lev Olshvang <levonshe@yandex.com> wrote:
... Besides to be security hole, I do not see any legitimate use except of live patching of shared object. I do not know whether production or mission critical system may take a risk of live patching, but development system would do a library update by stopping dependent application first.
Somewhat off-topic, but it may give some perspective... Microsoft offers hot patching to avoid reboots and downtime. If I recall correctly, some function calls are padded with no-ops so a jump can be written in its place. I think the Microsoft technology to do it is called the Detours library. Its a neat library even when detached from the hot patching use case. I used it several years ago to test DLL injections and spinning up malicious threads to egress data. Also see https://www.microsoft.com/en-us/research/project/detours/. Jeff
On 11/10/2017 12:49 PM, Jeffrey Walton wrote:
Microsoft technology
That is an oxymoron -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013
On Fri, 10 Nov 2017 17:43:37 -0500, Ruben Safir said:
On 11/10/2017 12:49 PM, Jeffrey Walton wrote:
Microsoft technology
That is an oxymoron
Given the number of systems running Microsoft products, it doesn't seem to be quite as much of an oxymoron as you think. Might want to spend some time learning *why* Microsoft has a hegemony before you diss it out of hand. "IIf you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle." -- Sun Tzu, The Art of War
participants (5)
-
Jeffrey Walton -
Lev Olshvang -
Ricardo Ribalda Delgado -
Ruben Safir -
valdis.kletnieks＠vt.edu