Re: Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?
10.11.2017, 22:06, "valdis.kletni...@vt.edu":> 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?> ,> Hi Valdis , Now you make things more clearly to me and I start to see the problem. The difference between executable and file that executable may crash. whileshared lib can not. Still there are unknown for me what happen with opened files and mmaped files when crash occurs I used to think that kernel decrease reference counts and closes files, whether application exits normally or crashed. 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. And I still confused because shared libraries are mapped with PROT_EXEC flag and so they differfrom regular file like /etc/passwd and generally have -r-x file system permissions. Regards,Lev___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?
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 pgprHuIWsGNFD.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?
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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?
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? pgprVtEEz1Ssy.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?
10.11.2017, 19:24, "valdis.kletni...@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. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?
On Fri, Nov 10, 2017 at 8:30 AM, Lev Olshvangwrote: > ... > 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?
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? pgplk_4HeWNmM.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?
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 Olshvangwrote: > 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies