From: John Wood <firstname.lastname@example.org> To: "Valdis Klētnieks" <email@example.com> Cc: firstname.lastname@example.org, Andi Kleen <email@example.com>, John Wood <firstname.lastname@example.org>, Kees Cook <email@example.com>, firstname.lastname@example.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  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.  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  by a supervisor (abused or not by a bad guy).  https://email@example.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
next prev parent 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --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).