Thread (18 messages) 18 messages, 3 authors, 2021-04-11

Re: Notify special task kill using wait* functions

From: John Wood <hidden>
Date: 2021-04-09 14:30:32

Hi Valdis and Andi. Thanks for your comments.

On Wed, Apr 07, 2021 at 06:51:48PM -0700, Andi Kleen wrote:
quoted
I didn't even finish the line that starts "From now on.." before I started
wondering "How can I abuse this to hang or crash a system?"  And it only took
me a few seconds to come up with an attack. All you need to do is find a way to
sigsegv /bin/bash... and that's easy to do by forking, excecve /bin/bash, and
then use ptrace() to screw the child process's stack and cause a sigsegv.

Say goodnight Gracie...
Yes there is certainly DoS potential, but that's kind of inevitable
for the proposal. It's a trade between allowing attacks and allowing DoS,
with the idea that a DoS is more benign.

I'm more worried that it doesn't actually prevent the attacks
unless we make sure systemd and other supervisor daemons understand it,
so that they don't restart.
I'm working on it. I will send a formal proposal in the next version.
Any caching of state is inherently insecure because any caches of limited
size can be always thrashed by a purposeful attacker. I suppose the
only thing that would work is to actually write something to the
executable itself on disk, but of course that doesn't always work either.
I'm also working on this. In the next version I will try to find a way to
prevent brute force attacks through the execve system call with more than
one level of forking.
-Andi
Again, thank you very much.
John Wood

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help