linux-kernel - Re: Fork Bombing Patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <25ae38200708290454r5be02a2ct568260cb429e4f1a@mail.gmail.com>
Date:	Wed, 29 Aug 2007 17:24:53 +0530
From:	"Anand Jahagirdar" <anandjigar@...il.com>
To:	"Simon Arlott" <simon@...e.lp0.eu>
Cc:	"Chris Snook" <csnook@...hat.com>,
	"Krzysztof Halasa" <khc@...waw.pl>, linux-kernel@...r.kernel.org
Subject: Re: Fork Bombing Patch

Hi
   consider a case:
if non root user request admin for more number of processes than root
user,admin needs to modify settings in /etc/security/limits.conf file
and if that user is not trustworthy and if does fork bombing attack it
will kill the box.
(I have already tried this attack). in that case this loop will work,
but by the time attack might have killed the box (Bcoz so many
processes has already been created at that time) . so in that case
admin wont come to know that what has happened.

Like this there are many cases..(actually these cases has already been
discussed On LKML 2 months before in my thread named "fork bombing
attack").
in all these cases this printk helps adminstrator a lot.


Anand

On 8/29/07, Simon Arlott <simon@...e.lp0.eu> wrote:
> On Wed, August 29, 2007 10:48, Anand Jahagirdar wrote:
> > Hi
> >                 printk_ratelimit function takes care of flooding the
> > syslog. due to printk_ratelimit function syslog will not be flooded
> > anymore. as soon as administrator gets this message, he can take
> > action against that user (may be block user's access on server). i
> > think the my fork patch is very useful and helps administrator lot.
> >                 i would also like to mention that in some of the cases
> > ulimit solution wont work. in that case fork bombing takes the machine
> > and server needs a reboot. i am sure in that situation this printk
> > statement helps administrator to know what has happened.
>
> If ulimit "wont work" in some situations, how is it going to trigger this printk?
> (When doesn't it work?)
>
> > Anand
> >
> > On 8/24/07, Chris Snook <csnook@...hat.com> wrote:
> >> Krzysztof Halasa wrote:
> >> > Hi,
> >> >
> >> > "Anand Jahagirdar" <anandjigar@...il.com> writes:
> >> >
> >> >>    I am forwarding one more improved patch which i have modified as
> >> >> per your suggestions. Insted of KERN_INFO i have used KERN_NOTICE and
> >> >> i have added one more if block to check hard limit. how good it is?
> >> >
> >> > Not very, still lacks "#ifdef CONFIG_something" and the required
> >> > Kconfig change (or other runtime thing defaulting to "no printk").
> >>
> >> Wrapping a single printk that's unrelated to debugging in an #ifdef
> >> CONFIG_* or a sysctl strikes me as abuse of those configuration
> >> facilities.  Where would we draw the line for other patches wanting to
> >> do similar things?
> >>
> >> I realized that even checking the hard limit it insufficient, because
> >> that can be lowered (but not raised) by unprivileged processes.  If we
> >> can't do this unconditionally (and we can't, because the log pollution
> >> would be intolerable for many people) then we shouldn't do it at all.
> >>
> >> Anand -- I appreciate the effort, but I think you should reconsider
> >> precisely what problem you're trying to solve here.  This approach can't
> >> tell the difference between legitimate self-regulation of resource
> >> utilization and a real attack.  Worse, in the event of a real attack, it
> >> could be used to make it more difficult for the administrator to notice
> >> something much more serious than a forkbomb.
> >>
> >> I suspect that userspace might be a better place to solve this problem.
> >>  You could run your monitoring app with elevated or even realtime
> >> priority to ensure it will still function, and you have much more
> >> freedom in making the reporting configurable.  You can also look at much
> >> more data than we could ever allow in fork.c, and possibly detect
> >> attacks that this patch would miss if a clever attacker stayed just
> >> below the limit.
> >>
> >>        -- Chris
> >>
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >
>
>
> --
> Simon Arlott
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/