From: John Wood <john.wood@gmx.com>
To: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
Cc: John Wood <john.wood@gmx.com>,
kernelnewbies@kernelnewbies.org, Andi Kleen <ak@linux.intel.com>,
Kees Cook <keescook@chromium.org>,
kernel-hardening@lists.openwall.com
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
next parent reply other threads:[~2021-04-07 17:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210330173459.GA3163@ubuntu>
[not found] ` <79804.1617129638@turing-police>
[not found] ` <20210402124932.GA3012@ubuntu>
[not found] ` <106842.1617421818@turing-police>
[not found] ` <20210403070226.GA3002@ubuntu>
[not found] ` <145687.1617485641@turing-police>
[not found] ` <20210404094837.GA3263@ubuntu>
[not found] ` <193167.1617570625@turing-police>
[not found] ` <20210405073147.GA3053@ubuntu>
[not found] ` <115437.1617753336@turing-police>
2021-04-07 17:51 ` John Wood [this message]
2021-04-07 20:38 ` Notify special task kill using wait* functions 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 \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 read-only IMAP folder(s) and NNTP newsgroup(s).