Re: Patch related with Fork Bombing Atack
From: Daniel Hazelton
Date: Fri Jun 01 2007 - 04:01:21 EST
On Friday 01 June 2007 03:30:20 Jens Axboe wrote:
> On Fri, Jun 01 2007, Daniel Hazelton wrote:
> > On Friday 01 June 2007 02:48:59 Anand Jahagirdar wrote:
> > > On 5/31/07, Jens Axboe <jens.axboe@xxxxxxxxxx> wrote:
> > > > On Thu, May 31 2007, Anand Jahagirdar wrote:
> > > > > 2) Printk message in my patch will definitely help
> > > > > Administrator/Root User to detect which particular user is trying
> > > > > fork bombing attack on his machine by looking at /var/log/messages
> > > > > or dmesg . he can take action against that particular user and kill
> > > > > his processes.
> > > >
> > > > You just opened a DoS possibility for any user, they can now flood
> > > > the syslog instead.
> > >
> > > Jens Axboe
> > >
> > > when they try to flood the syslog using fork bombing attack,
> > > their messge will be printed only once in syslog and it will show how
> > > many times it has repeated. due to this he will not able to flood the
> > > syslog.and i am using only one single variable in my printk messge so
> > > it is quite not possible to flood the syslog.
> > >
> > > am i missing something??
> > >
> > > anand
> >
> > Most definately. Each printk() call outputs to syslog - which means
> > that every time your code outputs its message there is another line in
> > the logs. It then becomes possible to use that to flood the syslog.
>
> I think Anand is assuming that because syslog may coalesce identical
> messages into "repeated foo times" in the messages file, that it's not a
> dos. That is of course wrong.
Well... The problem, IMHO, isn't the logfiles flood-filling the disc but the
klogd -> syslogd communications sucking down processor bandwidth and memory.
A quick grep of the sources shows that the kernel doesn't do that
nifty "repeated foo times" bit, but the userspace syslogd. That's what that
closing tagline in my previous response to this thread was all about - the
whole fact that the "repeated foo times" thing is from the userspace
component of the syslog system. Any program fed the massive amount of input
starting a recursive forkbomb would generate with the kernel doing this "I've
detected a forkbomb" printk would start to lag as it struggled to keep up -
so it starts using more and more processor until its stopped the machine from
doing anything *but* process those messages. (Oh, wait - I just described the
DoS that happens when the syslog gets flooded - silly me!)
DRH
PS: Most of that is for one persons benefit - hope I didn't offend anyone and
that you've all enjoyed my attempt at sarcasm.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/