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

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

[Lev Olshvang]

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

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

[Ricardo Ribalda Delgado]

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 at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



-- 
Ricardo Ribalda

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

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

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

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

[Lev Olshvang]

10.11.2017, 19:24, "valdis.kletnieks at 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.

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

[valdis.kletnieks at 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?
-------------- 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/a7855194/attachment.bin 

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

[Lev Olshvang]

An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20171114/f636460a/attachment.html 

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

[valdis.kletnieks at vt.edu]

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.
-------------- 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/20171114/3667e94c/attachment.bin 

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

[Jeffrey Walton]

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

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

[Ruben Safir]

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

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

[valdis.kletnieks at vt.edu]

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
-------------- 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/29d90d97/attachment-0001.bin