| 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
| ||
|
Date: Sat, 09 Apr 2011 16:12:08 -0400
From: Valdis.Kletnieks@...edu
To: linux-kernel@...r.kernel.org, lkml@...dok.com
Subject: Re: A long overdue fork-bomb defense ?
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. ;)
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists