Re: A long overdue fork-bomb defense ?

[Valdis.Kletnieks@vt.edu]

[-- Attachment #1: Type: text/plain, Size: 1227 bytes --]

On Fri, 08 Apr 2011 15:47:13 CDT, Robert Hailey said:

> 		log("fork_count generation");
> 		divide_all_process_fork_counts_by_two();

This will involve painful locking on large systems with lots of procs running.


> 		for ( p : process_table) {

Ditto.

>	if (fork_alert_level) {
>		if (fork_count >= fork_alert_level) {
>			signal(KILL, proc) && log('killed ...');
>			//don't: fork_alert_time=now();
>			return/dispatch?;
>		}
>		if (now()-fork_alert_time>10 seconds?) {
>			fork_alert_level=0; //Relax
>		}
>	}

A smart attacker can probably use this to  game the fork rate to fly just under
the wire, while still piling up lots of processes, *and* adding extra overhead
as it goes. If the rate limit is 5000 forks every 10 seconds, it can do 4500
every 10 seconds, and in a few minutes the poor scaling sections will eat your
system alive.

(And don't say "but it can be detected and stopped in those few minutes" -
because the *reality* in the security world is that people will say "We have
this great anti-forkbomb patch in the kernel, and don't need to check anymore".
Yes, they *will* do that.  Users that will blindly click on stuff because their AV
will stop anything bad are one of the banes of my existence. ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]