Hi,
On Fri, Apr 09, 2021 at 07:28:20PM -0400, Valdis Klētnieks wrote:
> On Fri, 09 Apr 2021 08:06:21 -0700, Andi Kleen said:
>
> > Thinking more about it what I wrote above wasn't quite right. The cache
> > would only need to be as big as the number of attackable services/suid
> > binaries.
On Fri, 09 Apr 2021 08:06:21 -0700, Andi Kleen said:
> Thinking more about it what I wrote above wasn't quite right. The cache
> would only need to be as big as the number of attackable services/suid
> binaries. Presumably on many production systems that's rather small,
> so a cache (which
Hi,
On Fri, Apr 09, 2021 at 08:06:21AM -0700, Andi Kleen wrote:
> > > 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
> > >
> > 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.
>
Hi Valdis and Andi. Thanks for your comments.
On Wed, Apr 07, 2021 at 06:51:48PM -0700, Andi Kleen wrote:
> > 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
> 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,
On Wed, 07 Apr 2021 19:51:51 +0200, John Wood said:
> 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
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
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.
Hi,
On Sun, Apr 04, 2021 at 05:10:25PM -0400, Valdis Klētnieks wrote:
> On Sun, 04 Apr 2021 11:48:37 +0200, John Wood said:
>
> > that exec and the child crashes is mitigated. The only drawback here, as
> > point Andi, is that a supervisor respawns some process killed. To avoid
> > this situation
On Sun, 04 Apr 2021 11:48:37 +0200, John Wood said:
> that exec and the child crashes is mitigated. The only drawback here, as
> point Andi, is that a supervisor respawns some process killed. To avoid
> this situation he suggest to notify to usersapace via wait* that the
> task has been killed by
Hi,
On Sat, Apr 03, 2021 at 05:34:01PM -0400, Valdis Klētnieks wrote:
> On Sat, 03 Apr 2021 09:02:26 +0200, John Wood said:
>
> > Currently, the scenario you propose is fully mitigated :). And notifying to
> > userspace that all the tasks has been killed by "Brute" not decrease the
> > security.
On Sat, 03 Apr 2021 09:02:26 +0200, John Wood said:
> Currently, the scenario you propose is fully mitigated :). And notifying to
> userspace that all the tasks has been killed by "Brute" not decrease the
> security. It adds the possibility that the supervisor adopts the correct
> policy.
So
Hi,
On Fri, Apr 02, 2021 at 11:50:18PM -0400, Valdis Klētnieks wrote:
> On Fri, 02 Apr 2021 14:49:32 +0200, John Wood said:
>
> > the attack can be started again. So, he suggested that notifying to
> > userspace
> > (via wait*() functions) that a child task has been killed by the "Brute"
> >
On Fri, 02 Apr 2021 14:49:32 +0200, John Wood said:
> the attack can be started again. So, he suggested that notifying to userspace
> (via wait*() functions) that a child task has been killed by the "Brute" LSM,
> the supervisor can adopt the correct policy and avoid respawn the killed
>
Hi,
On Tue, Mar 30, 2021 at 02:40:38PM -0400, Valdis Klētnieks wrote:
> On Tue, 30 Mar 2021 19:34:59 +0200, John Wood said:
>
> > The question is: How can I notify to wait* functions that the task has
> > been killed by the "Brute" LSM.
>
> What wait* functions even *care* that your LSM was what
On Tue, 30 Mar 2021 19:34:59 +0200, John Wood said:
> The question is: How can I notify to wait* functions that the task has
> been killed by the "Brute" LSM.
What wait* functions even *care* that your LSM was what killed it?
If you're caring about somehow notifying userspace that it was your
Hi,
I'm working in a LSM whose goal is to detect and mitigate fork brute force
attacks against vulnerable userspace applications. The detection and
mitigation works as expected by I'm stuck at this point.
The mitigation method used is to kill all the offending tasks involved in
the attack. To do
18 matches
Mail list logo
