kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: John Wood <john.wood@gmx.com>
To: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
Cc: kernel-hardening@lists.openwall.com,
	Andi Kleen <ak@linux.intel.com>, John Wood <john.wood@gmx.com>,
	Kees Cook <keescook@chromium.org>,
	kernelnewbies@kernelnewbies.org
Subject: Re: Notify special task kill using wait* functions
Date: Wed, 7 Apr 2021 19:51:51 +0200	[thread overview]
Message-ID: <20210407175151.GA3301@ubuntu> (raw)
In-Reply-To: <115437.1617753336@turing-police>

Hi Valdis,

On Tue, Apr 06, 2021 at 07:55:36PM -0400, Valdis Klētnieks wrote:
> On Mon, 05 Apr 2021 09:31:47 +0200, John Wood said:
>
> > > And how does the kernel know that it's notifying a "real" supervisor process,
> > > and not a process started by the bad guy, who can receive the notification
> > > and decide to respawn?
> > >
> > Well, I think this is not possible to know. Anyway, I believe that the "bad
> > guy" not rely on the wait* notification to decide to respawn or not. He
> > will do the attack without waiting any notification.
>
> You believe wrong. After my 4 decades of interacting with the computer security
> community, the only thing that remains a constant is that if you say "I believe
> that...", there will be *somebody* who will say "Challenge accepted" and try to
> do the opposite just for the lulz. Then there will be a second guy saying "Hmm..
> I wonder how much I could sell a 0-day for..."

Ok, lesson learned. I agree.

> [Great explanation and information]

Wow, I'm impressed. Thank you very much for this great explanation and info.

Thanks a lot for do that (insist about this subject). During the discussion [1]
you made me realize that I'm totally wrong (and you are totally right :) ).
The detection of brute force attacks that happen through the execve system
call can be easily bypassed -> Well, I bypass it during the tests using a
double exec. So, this part needs more work.

[1] https://lore.kernel.org/kernelnewbies/20210330173459.GA3163@ubuntu/

A first thought:

Scenario:
A process [p1] execs. The child [p2] execs again. The child [p3] crashes.

Problem:
The brute LSM kills p3 if it forks and crashes with a fast crash rate (fork
brute force attack). But the p2 process can start again the p3. Then brute
kills p2 (exec brute force attack). Now, if p1 starts p2 the attack can
follow without mitigation.

New proposal:
When brute detects a brute force attack through the fork system call
(killing p3) it will mark the binary file executed by p3 as "not allowed".
From now on, any execve that try to run this binary will fail. This way it
is not necessary to notify nothing to userspace and also we avoid an exec
brute force attack due to the respawn of processes [2] by a supervisor
(abused or not by a bad guy).

[2] https://lore.kernel.org/kernel-hardening/878s78dnrm.fsf@linux.intel.com/

This would imply remove the update (walking up in the processes tree) of
the exec stats and add a list of not allowed binaries.

What do you think? Any ideas are welcome. I'm open minded :)

Regards,
John Wood

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

  reply	other threads:[~2021-04-07 17:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30 17:34 John Wood
2021-03-30 18:40 ` Valdis Klētnieks
2021-04-02 12:49   ` John Wood
2021-04-03  3:50     ` Valdis Klētnieks
2021-04-03  7:02       ` John Wood
2021-04-03 21:34         ` Valdis Klētnieks
2021-04-04  9:48           ` John Wood
2021-04-04 21:10             ` Valdis Klētnieks
2021-04-05  7:31               ` John Wood
2021-04-06 23:55                 ` Valdis Klētnieks
2021-04-07 17:51                   ` John Wood [this message]
2021-04-07 20:38                     ` Valdis Klētnieks
2021-04-08  1:51                       ` Andi Kleen
2021-04-09 14:29                         ` John Wood
2021-04-09 15:06                           ` Andi Kleen
2021-04-09 16:08                             ` John Wood
2021-04-09 23:28                             ` Valdis Klētnieks
2021-04-11  8:46                               ` John Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210407175151.GA3301@ubuntu \
    --to=john.wood@gmx.com \
    --cc=ak@linux.intel.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=valdis.kletnieks@vt.edu \
    --subject='Re: Notify special task kill using wait* functions' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).