Dear Sir
I am forwarding one patch related with fork bombing attack.
actually ulimit helps to prevent fork bombing attack.
1) when i searched for the code which actually prevents
fork bombing attack in kernel/fork.c file, it took lot of time to
search for the code.
2) when we set the ulimit in /etc/security/limits.conf file
for guest account and then try fork bombing attack using guest
account. ulimit prevents fork bombing attack but administrator/root
user wont come to know that somebody is trying fork bombing attack on
his machine.
Due to this two reasons i tried to create a patch which will solve
above mentioned problems.
1) Commented Code in my patch will Definitely Help Developer to get
the prevention code for Fork bombing Attack very easily.
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.
Regards,
Anand
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
On 5/31/07, Jens Axboe <[email protected]> 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
> --
>
>
>
On Friday 01 June 2007 02:48:59 Anand Jahagirdar wrote:
> On 5/31/07, Jens Axboe <[email protected]> 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.
DRH
(I hate having to explain the obvious)
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 <[email protected]> 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.
--
Jens Axboe
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 <[email protected]> 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.
On Fri, Jun 01 2007, Daniel Hazelton wrote:
> 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 <[email protected]> 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!)
Yep, otherwise there would be no need to have introduced
printk_ratelimit().
--
Jens Axboe
On Fri, 1 Jun 2007, Anand Jahagirdar wrote:
> 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.
Your argument is flawed - if the kernel provides more than one possibility
to flood the syslogd, the is free to invoke the events interleaved. This
trivially prevents syslogd from grouping identical reports together.
--
Jiri Kosina
Hello All
I totally agree with all of you, but my idea behind
this patch is that administrator/root user must be able to know that
there is fork bombing attack on his machine and he should be able take
action agianst that particular user and kill all his processes.
can anybody please tell me how can we achive this??
Regards
Anand
On 6/1/07, Jiri Kosina <[email protected]> wrote:
> On Fri, 1 Jun 2007, Anand Jahagirdar wrote:
>
> > 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.
>
> Your argument is flawed - if the kernel provides more than one possibility
> to flood the syslogd, the is free to invoke the events interleaved. This
> trivially prevents syslogd from grouping identical reports together.
>
> --
> Jiri Kosina
>
On 1 Jun 2007, Jens Axboe told this:
> 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.
Not all syslog daemons do that, anyway. (syslog-ng doesn't, for one.)
--
`On a scale of one to ten of usefulness, BBC BASIC was several points ahead
of the competition, scoring a relatively respectable zero.' --- Peter Corlett
On Sunday 03 June 2007 19:01:21 Nix wrote:
> On 1 Jun 2007, Jens Axboe told this:
> > 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.
>
> Not all syslog daemons do that, anyway. (syslog-ng doesn't, for one.)
That syslog-ng doesn't coalesce repeated messages into a single line doesn't
make a difference. The printk_ratelimit stuff is supposed to make it very
hard to DOS a system by flooding syslog, but that doesn't mean its
impossible.
The point of this discussion was that having a part of the kernel log a
message about a fork-bomb was a very large whole that could be used to DOS a
system by flooding the syslog. (In fact, IIRC, the printk_ratelimit (and
somebody, please correct me if I'm wrong) stuff uses a ring buffer and
seriously spamming syslog, like the patch that spawned this thread would have
done, could cause you to lose potentially important messages)
DRH
Hello All
I am forwarding one improved patch related with Fork
Bombing Attack. This patch prints a message (only once) which alerts
administrator/root user about fork bombing attack. I created this
patch to implement my idea of informing administrator about fork
bombing attack on his machine only once.
This patch overcomes all drawbacks of my previous patch related
with fork bombing attack and helps administrator. added comments will
definitely help developers.
Regards
Anand
On 6/3/07, Daniel Hazelton <[email protected]> wrote:
> On Sunday 03 June 2007 19:01:21 Nix wrote:
> > On 1 Jun 2007, Jens Axboe told this:
> > > 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.
> >
> > Not all syslog daemons do that, anyway. (syslog-ng doesn't, for one.)
>
> That syslog-ng doesn't coalesce repeated messages into a single line doesn't
> make a difference. The printk_ratelimit stuff is supposed to make it very
> hard to DOS a system by flooding syslog, but that doesn't mean its
> impossible.
>
> The point of this discussion was that having a part of the kernel log a
> message about a fork-bomb was a very large whole that could be used to DOS a
> system by flooding the syslog. (In fact, IIRC, the printk_ratelimit (and
> somebody, please correct me if I'm wrong) stuff uses a ring buffer and
> seriously spamming syslog, like the patch that spawned this thread would have
> done, could cause you to lose potentially important messages)
>
> DRH
>
On Mon, 4 Jun 2007, Anand Jahagirdar wrote:
> I am forwarding one improved patch related with Fork Bombing
> Attack. This patch prints a message (only once) which alerts
> administrator/root user about fork bombing attack. I created this patch
> to implement my idea of informing administrator about fork bombing
> attack on his machine only once.
> This patch overcomes all drawbacks of my previous patch related with
> fork bombing attack and helps administrator. added comments will
> definitely help developers.
> + /*
> + * following code prints a message which alerts administrator/root * user about fork bombing Attack
> + */
> + if ((atomic_read(&p->user->processes) >= (p->signal->rlim [RLIMIT_NPROC].rlim_cur - 1)) && (atomic_read(&p->user->processes) < p->signal->rlim[RLIMIT_NPROC].rlim_cur)) {
Did this get malformed somehow? Looks like some successive lines got
pasted together, or something.
> + if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) && p->user != &root_user) {
> + printk(KERN_CRIT"User with uid %d is crossing its Process limit\n",p->user->uid);
> + }
> + }
Why not printk_ratelimit() here? Otherwise we have looped back to the
possibility of user flooding the system logs, which has been already
discussed in this thread, right?
Also the { and } braces seem redundant.
Thanks,
--
Jiri Kosina
On Monday 04 June 2007 10:58:41 Jiri Kosina wrote:
> On Mon, 4 Jun 2007, Anand Jahagirdar wrote:
> > I am forwarding one improved patch related with Fork Bombing
> > Attack. This patch prints a message (only once) which alerts
> > administrator/root user about fork bombing attack. I created this patch
> > to implement my idea of informing administrator about fork bombing
> > attack on his machine only once.
> > This patch overcomes all drawbacks of my previous patch related with
> > fork bombing attack and helps administrator. added comments will
> > definitely help developers.
> >
> > + /*
> > + * following code prints a message which alerts administrator/root *
> > user about fork bombing Attack + */
> > + if ((atomic_read(&p->user->processes) >=
> > (p->signal->rlim [RLIMIT_NPROC].rlim_cur - 1)) &&
> > (atomic_read(&p->user->processes) <
> > p->signal->rlim[RLIMIT_NPROC].rlim_cur)) {
>
> Did this get malformed somehow? Looks like some successive lines got
> pasted together, or something.
Seeing the lack of the '+' I think it's a mangling from not paying attention
to the 80 column marker in the editor.
> > + if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
> > p->user != &root_user) { + printk(KERN_CRIT"User with uid %d is
> > crossing its Process limit\n",p->user->uid); + }
> > + }
>
> Why not printk_ratelimit() here? Otherwise we have looped back to the
> possibility of user flooding the system logs, which has been already
> discussed in this thread, right?
>
> Also the { and } braces seem redundant.
They are.
Here's two hints:
1) double check for hidden "word wrap" problems. A sane programmers editor
will alert you to this, and careful checking of the patches before posting
will also reveal them. (emacs shows a \ in the 80th column, jed puts a $
there, etc...)
2) when there is a potential for syslog spam - like your patch has - use
printk_ratelimit() instead of printk(). This will throttle the output so that
flooding the syslog is no longer possible.
DRH
ps: you patch is very difficult to apply - try using git
Hello All
I am forwarding one more improved patch related with fork
bombing attack. I have used printk_ratelimit function in my patch
and it works rellly well. it prints message as per printk_ratelimit
values stored in /proc/sys/kernel/printk_ratelimit
and /proc/sys/kernel/printk_ratelimit_burst.
root can set printk_ratelimit values(such as how many times message
should be repeated ,after how much time message should repeat) by
making changes in the above 2 mentioned files.
this patch will never flood syslog anymore and will definitely
help administrator by informing him about fork bombing attack.
added comments will help developers.
Regards,
Anand
On 6/4/07, Daniel Hazelton <[email protected]> wrote:
> On Monday 04 June 2007 10:58:41 Jiri Kosina wrote:
> > On Mon, 4 Jun 2007, Anand Jahagirdar wrote:
> > > I am forwarding one improved patch related with Fork Bombing
> > > Attack. This patch prints a message (only once) which alerts
> > > administrator/root user about fork bombing attack. I created this patch
> > > to implement my idea of informing administrator about fork bombing
> > > attack on his machine only once.
> > > This patch overcomes all drawbacks of my previous patch related with
> > > fork bombing attack and helps administrator. added comments will
> > > definitely help developers.
> > >
> > > + /*
> > > + * following code prints a message which alerts administrator/root *
> > > user about fork bombing Attack + */
> > > + if ((atomic_read(&p->user->processes) >=
> > > (p->signal->rlim [RLIMIT_NPROC].rlim_cur - 1)) &&
> > > (atomic_read(&p->user->processes) <
> > > p->signal->rlim[RLIMIT_NPROC].rlim_cur)) {
> >
> > Did this get malformed somehow? Looks like some successive lines got
> > pasted together, or something.
>
> Seeing the lack of the '+' I think it's a mangling from not paying attention
> to the 80 column marker in the editor.
>
> > > + if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
> > > p->user != &root_user) { + printk(KERN_CRIT"User with uid %d is
> > > crossing its Process limit\n",p->user->uid); + }
> > > + }
> >
> > Why not printk_ratelimit() here? Otherwise we have looped back to the
> > possibility of user flooding the system logs, which has been already
> > discussed in this thread, right?
> >
> > Also the { and } braces seem redundant.
> They are.
>
> Here's two hints:
> 1) double check for hidden "word wrap" problems. A sane programmers editor
> will alert you to this, and careful checking of the patches before posting
> will also reveal them. (emacs shows a \ in the 80th column, jed puts a $
> there, etc...)
> 2) when there is a potential for syslog spam - like your patch has - use
> printk_ratelimit() instead of printk(). This will throttle the output so that
> flooding the syslog is no longer possible.
>
> DRH
> ps: you patch is very difficult to apply - try using git
>