Philippe, On Saturday 19 March 2005 04:00, Philippe Vogel wrote:
Randall R Schulz schrieb:
Jim,
On Friday 18 March 2005 10:47, Jim Flanagan wrote:
...
Are any of the currently supported Suse versions suseptable to this forkbomb attack? I'm not very sure what it is, but I'm sure many of you are. I'm running suse 8.2 pro and 9.1 pro.
From my SuSE 9.1 Pro:
% ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) 16369 virtual memory (kbytes, -v) unlimited
This suggests the vulnerability exists. Don't ask me to run the forkbomb script, though.
Here's the story at my ISP:
% ulimit -a core file size (blocks) 0 data seg size (kbytes) 20000 file size (blocks) 100000 max locked memory (kbytes) unlimited max memory size (kbytes) 10000 open files 1024 pipe size (512 bytes) 8 stack size (kbytes) 8192 cpu time (seconds) 600 max user processes 7168 virtual memory (kbytes) unlimited
% uname -a Linux bolt.sonic.net 2.4.29-rc2-A-STAND #1 SMP Thu Jan 13 20:54:15 PST 2005 i686 unknown
That looks better, but unless that host has s**tloads of RAM and some kind of CPU throttling, it might still be vulnerable. Definitely don't ask me to attack my own ISP. I need them!
Jim Flanagan
Randall Schulz
So which values do you suggest?
I find it hard to believe an interactive user would need much more than 100 processes. Logged in to a KDE session with the usual panoply of gadgets running, I'm using only 43 processes. Perhaps some users with special needs might, but they can be granted more. Perhaps these numbers are a throwback to the time when a LWP / thread counted as a process. And allowing any given process to commandeer all the physical RAM and swap / paging space is also highly questionable.
Depending if the machine is a server or a workstation with multiple users on it differences have to be made im memory usage and open files. There is nothing said in the article what to do and how to prevent this. There is only a "there is some malice script".
The malicious script is utterly trivial. Robustly solving the problem with out interfering with legitimate patterns of use is probably much harder. However, on my SuSE 9.1 system, unmodified w.r.t. to the pertinent limits, I've three times had the system rendered useless and was forced to press the hardware reset button (!) by a runaway process that consumed so much memory that nothing else could happen. But I have to confess that I don't believe I fully understand this issue and know nothing about how the systems mentioned in the article as not being susceptible to these attacks have achieved that robustness.
Philippe
Randall Schulz