Linux and forkbomb - with link
Sorry, my earlier post did not include the link to the story at securityfocus.com 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. http://www.securityfocus.com/columnists/308?ref=rssdebia -- Jim Flanagan linuxjim@jjfiii.com
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
On Friday 18 March 2005 11:03 am, Randall R Schulz wrote:
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:
9.2 pro seems to have different values.... # ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) 32 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) 3583 virtual memory (kbytes, -v) unlimited Scott -- POPFile, the OpenSource EMail Classifier http://popfile.sourceforge.net/ Linux 2.6.8-24.11-default x86_64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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? 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". Reguards Philippe - -- Diese Nachricht ist digital signiert und enthält weder Siegel noch Unterschrift! Die unaufgeforderte Zusendung einer Werbemail an Privatleute verstößt gegen §1 UWG und 823 I BGB (Beschluß des LG Berlin vom 2.8.1998 Az: 16 O 201/98). Jede kommerzielle Nutzung der übermittelten persönlichen Daten sowie deren Weitergabe an Dritte ist ausdrücklich untersagt! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQD1AwUBQjwUa0Ng1DRVIGjBAQILZwcAhg8TGQS4juk5wNHHMpM10vbEqVcAD7MJ 4en7krIKFUterXprrVFSRqaZQr009LLFtnnMWJHPfn/HeGzTrpgzCoL5DLDwQWhJ di5tR3ReiWBAAyjrJcOc+zD1EIRNLbIRXF8aJLrwkwNCE8bcO8JEID7gFf4OTjIn VC/hCvsVXuJQpkaKyEq+k15e8kWsdZ4F6ktGqqvguK0rKwPSbu4wB7nwWqdBfag3 s+Mauy5oxmaLg7SrK7hqOH4Z0YLmB/NS60IEwfHs9cgdb4zOVc7pXJBDq592VcJs oSdNDEyuK4s= =O4Wi -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Randall R Schulz wrote: | 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. Well, maybe i'm not a normal user, but i don't use kde at all at the moment on my desktop and have around 125 processes running. And i'm not doing any multimedia stuff at all atm. So its not that easy to say 'noone will need more than around 100 processes'. The next problem is, even with only a few you can crash a box. Finetuneing the limits is hard if you want to do some 'general rules', some apps may need more then x meg of ram, so they won't work anymore. If you allow users to start maybe 100 processes with 16 meg ram each you'll need up to 1,6gb of ram for just one user to prevent him from bombing your box. If he eats up all your mem, your kernel will normaly start to kill processes. With the newer OOM Killer this may work better then it did in the last years because the OOM Killer just started to kill stuff, if you had an bad day, he would start with things like sshd... | The malicious script is utterly trivial. Robustly solving the problem | with out interfering with legitimate patterns of use is probably much | harder. the only bomb i can actually remember is this one: (:(){ :|:;};:) (kids, don't try this at home ;-) It looks so easy and kills so much ;-) | 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. Well yeah, but the problem still exsist: where to set the limit to? Not every user will be able to set such limits, so you have to set them in a clever way. Take openoffice as a start, it needs much more cpu and ram then many many other apps. If you allow enough of mem/cpu to run openoffice, then you're maybe back to the original problem: your limits won't work for such a bomb. As said in other posts, if someone will bring your box down, he can do it (as long as he's a local user). Regards, Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFCPsQWQoCguWUBzBwRAvMWAJ9yTFnG9xpLhah3xnyuZAg5vH135wCeJAdp crT7JjVTk6XRLPddzK61Vkc= =coto -----END PGP SIGNATURE-----
Sven, On Monday 21 March 2005 04:54, Sven 'Darkman' Michels wrote:
Randall R Schulz wrote: | 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.
Well, maybe i'm not a normal user, but i don't use kde at all at the moment on my desktop and have around 125 processes running. And i'm not doing any multimedia stuff at all atm. So its not that easy to say 'noone will need more than around 100 processes'. The next problem is, even with only a few you can crash a box. Finetuneing the limits is hard if you want to do some 'general rules', some apps may need more then x meg of ram, so they won't work anymore. If you allow users to start maybe 100 processes with 16 meg ram each you'll need up to 1,6gb of ram for just one user to prevent him from bombing your box. If he eats up all your mem, your kernel will normaly start to kill processes. With the newer OOM Killer this may work better then it did in the last years because the OOM Killer just started to kill stuff, if you had an bad day, he would start with things like sshd...
I just picked that number based on my own experience. But surely even you don't need thousands of processes?
| The malicious script is utterly trivial. Robustly solving the | problem with out interfering with legitimate patterns of use is | probably much harder.
the only bomb i can actually remember is this one: (:(){ :|:;};:) (kids, don't try this at home ;-) It looks so easy and kills so much ;-)
You can find several by Googling for "Fork Bomb"
| 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.
Well yeah, but the problem still exsist: where to set the limit to? Not every user will be able to set such limits, so you have to set them in a clever way. Take openoffice as a start, it needs much more cpu and ram then many many other apps. If you allow enough of mem/cpu to run openoffice, then you're maybe back to the original problem: your limits won't work for such a bomb. As said in other posts, if someone will bring your box down, he can do it (as long as he's a local user).
Yes. That's my point. It's not an easy problem to solve for exactly the reason that there's just a continuum of legitimate needs which eventually become pathological (at different points for systems with different hardware capacity). What exactly characterizes pathological demand or load?
Sven
Randall Schulz
Randall R Schulz wrote:
Yes. That's my point. It's not an easy problem to solve for exactly the reason that there's just a continuum of legitimate needs which eventually become pathological (at different points for systems with different hardware capacity). What exactly characterizes pathological demand or load?
The "limits" are mostly to stop *server*-processes from going berserk (e.g. apache) - or shell-users (anybody remember the shell-accounts one got at university before the Windoze-desease spread?). The limits work quite well on shell-only accounts (no X). But with X (and qt et.al) apps have just been getting bigger and more power-hungry - so limits are of not much use and I can see why SuSE dropped them alltogether (can you say "support-nightmare"?). On my FreeBSD-box, it looks like this: rainer@bsd>limits Resource limits (current): cputime infinity secs filesize infinity kb datasize 524288 kb stacksize 65536 kb coredumpsize infinity kb memoryuse infinity kb memorylocked infinity kb maxprocesses 3618 openfiles 7236 sbsize infinity bytes vmemoryuse infinity kb But of course, that's comparing apples with oranges (or penguins with daemons).... cheers, Rainer -- =================================================== ~ Rainer Duffner - rainer@ultra-secure.de ~ ~ Freising - Munich - Germany ~ ~ Unix - Linux - BSD - OpenSource - Security ~ ~ http://www.ultra-secure.de/~rainer/pubkey.pgp ~ ===================================================
On Fri, Mar 18, 2005 at 12:47:51PM -0600, Jim Flanagan wrote:
Sorry, my earlier post did not include the link to the story at securityfocus.com
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.
Yes it is. Because we have unlimited ulimits by default. To fix that: Install the "ulimit" package. Adapt /etc/sysconfig/ulimit to your needs. Done. Ciao, Marcus
On Fri, Mar 18, 2005 at 12:47:51PM -0600, Jim Flanagan wrote:
Sorry, my earlier post did not include the link to the story at securityfocus.com
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.
Yes it is.
Because we have unlimited ulimits by default.
To fix that: Install the "ulimit" package. Adapt /etc/sysconfig/ulimit to your needs.
From what I can tell this vulnerability is open to local users, not necessarily remote users, but, the potential damage is high (instantaneous system failure) and is a known old attack. -- Jim Flanagan
What I don't understand is that the article mentions that the BSD kernels have been modified for some time (years) for this old attack, but linux has not. I thought linux was more cutting edge and up to date than that. linuxjim@jjfiii.com
What I don't understand is that the article mentions that the BSD kernels have been modified for some time (years) for this old attack, but linux has not. I thought linux was more cutting edge and up to date than that.
Unless I missed something, he talks about *BSD systems and servers, not the kernels. It's a default configuration issue, not a kernel issue as such. The kernel can't really know the demands that are going to be placed on it, so shouldn't try to restrict them. It should just try to adapt as best it can given the user's workload. The problem is that most Linux systems, including SUSE, still ship with a configuration that can give any user all the system resources. The BSDs haven't done that for years. -- --- Derek Fountain, on the web here : <a href="http://www.derekfountain.org">Derek Fountain</a>
This article is somewhat misguided. Limiting the number of user processes is an excellent idea, but provides no protection against a knowledgeable hostile user. If one of your users wishes to make your service unusable by hogging some resource then they will certainly find a way of doing it. The solution is to take away their account. Fortunately legitimate users very rarely wish to make the service unusable. However, they may very well *accidentally* run a fork bomb (I have done it myself) and for this reason it would be friendly of SuSE to ensure that default setups always set a process limit (it doesn't have to be very small). Bob ============================================================== Bob Vickers R.Vickers@cs.rhul.ac.uk Dept of Computer Science, Royal Holloway, University of London WWW: http://www.cs.rhul.ac.uk/home/bobv
participants (9)
-
Bob Vickers -
Derek Fountain -
Jim Flanagan -
Marcus Meissner -
Philippe Vogel -
Rainer Duffner -
Randall R Schulz -
Scott Leighton -
Sven 'Darkman' Michels