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: <46C4BC46.7000305@redhat.com>
Date:	Thu, 16 Aug 2007 17:06:14 -0400
From:	Chris Snook <csnook@...hat.com>
To:	Anand Jahagirdar <anandjigar@...il.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Fork Bombing Patch

Anand Jahagirdar wrote:
> Hello All
>            I have searched for Maintainers List to get the correct
> Maintainer for my patch. But i am not getting exact maintainer to
> which i should forward my patch. Will any body please tell me,to which
> maintainer i should forward my patch for its inclusion?
> 
> Summery of the Patch:
> 
> This patch Warns the administrator about the fork bombing attack
> (whenever any user is crossing its process limit). I have used
> printk_ratelimit function in this patch. This function helps to
> prevent flooding of syslog and prints message as per the values set by
> root user in following files:-
> 
> 1) /proc/sys/kernel/printk_ratelimit:- This file contains value for,
> how many times message should be printed in syslog.
> 
> 2) /proc/sys/kernel/printk_ratelimit_burst: - This file contains value
> for, after how much time message should be repeated.
> 
> This patch is really helpful for administrator/root user from security
> point of view. They can take action against attacker by looking at
> syslog messages related with fork bombing attack.
> 
> Added comments will definitely help developers.
> 
> Signed-Off-by: Anand Jahagirdar <anandjigar@...il.com>
> 
> 
> ------------------------------------------------------------------------
> 
> Index: root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c
> ===================================================================
> --- root.orig/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-06-26 20:40:06.000000000 +0530
> +++ root/Desktop/a1/linux-2.6.17.tar.bz2_FILES/linux-2.6.17/kernel/fork.c	2007-06-26 20:41:41.000000000 +0530
> @@ -957,12 +957,19 @@
>  
>  	retval = -EAGAIN;
>  	
> -        
> +        /*
> +         * following code does not allow Non Root User to cross its process
> +         * limit and it alerts administrator about user Nearing the process limit.
> +         */
> + 
>        	if (atomic_read(&p->user->processes) >= p->signal->rlim[RLIMIT_NPROC].rlim_cur) 
>  		if (!capable(CAP_SYS_ADMIN) && !capable(CAP_SYS_RESOURCE) &&
> -				p->user != &root_user) 
> +				p->user != &root_user)  {
> +                        if (printk_ratelimit())
> +                                printk(KERN_WARNING "User with uid %u is Nearing the process limit\n",p->user->uid);
> +
>  			 goto bad_fork_free;
> -			
> +		}			
>  			
>  	atomic_inc(&p->user->__count);
>  	atomic_inc(&p->user->processes);

1) The printk is misleading.  We're hitting this condition because the 
user has hit the limit, not merely approached it.

2) This should probably be KERN_INFO.  The kernel itself is not in any 
danger because of this condition.

3) You should only be printing a warning if the user's hard limit is 
exceeded, not the soft limit.  While these default to the same value, 
applications are free to deliberately lower their soft limit to 
self-manage their resource utilization.  It's even perfectly valid (if 
uncommon) to lower the limit and deliberately keep your process count 
right at that limit by forking opportunistically.  If an application is 
doing this, you don't need or want to spam the message logs.  So, check 
to see if p->signal->rlim[RLIMIT_NPROC].rlim_cur == 
p->signal->rlim[RLIMIT_NPROC].rlim_max before spewing this out into the log.

4) Even with the printk_ratelimit, lowering the priority to KERN_INFO, 
and only logging when the hard limit is reached, an unprivileged user 
can still spam the system logs.  Perhaps a sysctl is in order?

	-- 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/