Linux Kernel Security, Again

Linux Kernel Security, Again
Jason Miller, 2005-03-16

It's a sad day when an ancient fork bomb attack can still take down most of the latest Linux distributions.

silly article 2005-03-17
Anonymous (4 replies)

silly article 2005-03-18
Anonymous

Clarification:

Point about distributions not supporting user limits out of the box = not so silly. This may be an oversight or may be done on purpose on desktop-centric distros. Server installs should support reasonable ulimits by default though, good point.

You do seem to hint that the linux...

[ more ] [ reply ]

silly article 2005-03-18
Anonymous (1 replies)

Yes, you can use ulimit. By why should the sysadmin have to bother to do more work to lock a box down? After an install the box should be "secure". It shouldn't be necessary to do things to make it secure: that's what Microsoft did in the past and look where it got them.

This is about sane defaul...

[ more ] [ reply ]

shouldn't you people already have your boxes secured? 2005-03-18
Anonymous (2 replies)

the sysadmins job is to ensure the security of the box and the network! What kind of retard statement is that?

Yes, better out of the box security would be nice, but as a sysadmin, shouldn't you be worrying about these things and keeping up with them?

If you are a sysadmin that doesn't pay at...

[ more ] [ reply ]

shouldn't you people already have your boxes secured? 2005-03-19
Anonymous

No, your box does not _deserve_ to be hacked because your job does not happen to be one which requires intimate details of how to secure a box.

If the distribution is 'secure by default' meaning that the default settings provide a secure environment, not suceptible to forkbombing, or other attack...

[ more ] [ reply ]

shouldn't you people already have your boxes secured? 2005-03-23
anon

I agree with you. Sysadmins have ultimate responsibility for not only what they run, but how they run it.

That being said, usually a sysadmin is thinking of keeping people out of the box, maybe thinking about elevated privelege exploits, service exploits, etc.

Something like a reasonable ulimi...

[ more ] [ reply ]

silly response 2005-03-18
Anonymous

don't miss the point of the article?

(let me spell it out for you, just in case - set secure DEFAULTS at the kernel level to eliminate the *need* for "snap-on security" later)
...

[ more ] [ reply ]

silly comment 2005-03-18
Anonymous (1 replies)

Yes, use ulimit. That's the point. The system should be enforcing ulimits on the shells of non-root users. Do you seriously think an attacker is going to be nice enough to use ulimit on their shell to prevent themselves from bringing your machine down? They should not have a choice, root should ...

[ more ] [ reply ]

silly article 2005-03-18
Anonymous

You don't grok ulimit. There are two kinds of limits: hard limits and soft limits. A hard limit cannot be increased by non-root users, while a soft limit can.

If a distribution sets hard limits in a shell startup file like /etc/profile or whatever, then those limits will be applied at login tim...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-17
Karyl Stein (1 replies)

How can you tell the difference between something like a heavily loaded web server and a fork bomb? In both cases you have a non-root user spawning a number of processes. Is it the job of the distro maintainers to make a judgment on what the user's system can handle? Default process, memory use, ...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-17
Jason V. Miller (Author) (1 replies)

"How can you tell the difference between something like a heavily loaded web server and a fork bomb?"

If you're running a heavily loaded Web server, you should increase the default limits (assuming that they are reasonably set) to handle the load that is acceptable for your machine.

"Is it the...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Anonymous

"No, but I do think that it's their job to prevent the default configuration from allowing any local user to take down the entire system."

There is your clue Jason, "local user". It just hasn't hit you on the head yet.
...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-17
Anonymous (3 replies)

I wonder if HP-UX, AIX or Solaris have the same problem?...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-17
Jason V. Miller (Author) (3 replies)

I didn't have the chance to test them, but I do plan to, if the opportunity arises. I should be able to test at least some version of Solaris at some point....

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-17
mrsad (1 replies)

Believe me, the default installation of both HPUX and Solaris suffer from this stupied 'attack'....

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-17
Jason V. Miller (Author) (1 replies)

Yeah, I just got verification from someone that this works on Solaris 10. I'm speechless. :)

Is it really that unreasonable to expect a Unix machine to not be so easily brought down by a local user?
...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Anonymous (2 replies)

yes. if you don't trust your users, you should know to take appropriate precautions. if you do trust them, you don't have a problem.

the problem here is people who expect unix to be friendly to ignorant people, ie, themselves....

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
crf (2 replies)

As an old coworker had in his sig: Unix doesn't prevent you from doing stupid things, because that would also prevent you from doing clever things.

I think the point that Jason is missing here is that the majority of people who are using Linux (or any *nix, really) are generally using it either...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Anonymous

Exactly; local users can always hose a box. Its pointless to attack Linux for this. I bet the *BSDs can all be taken down by a local user; maybe not with trivial stuff like this but what about /tmp on swap? I mean, the only way to control local users is to log extensively and assign blame on the bac...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Anonymous

A nice sentiment, but unworkable, I'm afraid.

On your home box it isn't a problem. On any server it is, even if the only real user is root. The reason is simple: you don't want someone who managed to gain local user through an exploit to be able to DoS the machine.

Security consists of layers....

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-20
Anonymous

the problem is an insecure default setting. Plain and simple.. quit trolling! ...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Anonymous

Sun OS is older than you kid so don't bother with your fork bomb script...

...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-19
CrossChris

The author doesn't seem to understand that this is *not* a "kernel security" issue. It's a simple configuration issue, which will be handled by any competent sysop.

It is not (and should not) be an issue addressed by a distro's installer - it should just be another of the configuration things se...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Anonymous

IIRC default value for maximum number of processes per user in AIX is 128....

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Anonymous

HP-UX (at least 11i) has limits in the kernel. They're 'tunables' -- meaning they can be changed without a reboot....

[ more ] [ reply ]

simple fork bomb? 2005-03-17
Anonymous (1 replies)

Simple fork bomb?

1. were your limits rationally set? As in sized for your system. My limit is 4095 (though I REALLY shouldn't do that...)

2. Was your memory limits properly sized? This tends to limit the effect of some fork bombs (fork/exec type) since the memory allocated is shared (copy on ...

[ more ] [ reply ]

simple fork bomb? 2005-03-17
Jason V. Miller (Author) (3 replies)

"1. were your limits rationally set? As in sized for your system. My limit is 4095 (though I REALLY shouldn't do that...)"

No, they weren't. That's the point. They should be reasonably set by default. Should a regular user *really* be allowed to run 4095 processes on your machine by default? By h...

[ more ] [ reply ]

simple fork bomb? 2005-03-17
Anonymous

At which point, doesn't this make it a distribution problem, not a kernel problem? You seem to be hinting at this in your article, but you also seem to be hinting that the blame lies in the kernel itself.

i.e. on an old RH9 box /etc/security/limits.conf there are no limits set. That's not the fau...

[ more ] [ reply ]

simple fork bomb? 2005-03-17
Anonymous (1 replies)

"No, they weren't."

Then don't blame the distribution or the kernel.

Vendors DON'T have any way to know how you want to use the system. They can ask basic questions - "do you want Server, Workstation, user, minimum..."

Most people on a workstation take responsibility for overload/oversubscr...

[ more ] [ reply ]

simple fork bomb? 2005-03-17
Jason V. Miller (Author) (1 replies)

"Then don't blame the distribution or the kernel."

Should I not blame Microsoft for running services by default that allow remote compromise? Sure, the severity of this attack is much different, but you're still dealing with something that can and should be fixed by the developers.

"On a ser...

[ more ] [ reply ]

simple fork bomb? 2005-03-18
Stephen Samuel (3 replies)

One of the problems with Linux is that it is so scalable. Limits that wouldn't sweat a 3Gz P4 with 4GB of ram would reduce my 200Mz P2 with 128MB of ram to a quivering pile of silicon, but I can install onto both from the same CD.

Similarly, limits that seemed reasonable on my P2 might have peop...

[ more ] [ reply ]

simple fork bomb? 2005-03-18
Eric F.

Distributions should include in their installer a quick-and-dirty detection scheme that sets reasonable limits based on the hardware.

Knowledgeable users can then go change it if they know they're going to be running a heavy load, but it eliminates the most common concern: the average user isn'...

[ more ] [ reply ]

simple fork bomb? 2005-03-18
Michael Ayres

Perhaps a script for sanity checking ulimits could be written? A benchmark script/suite that either creates a config, or verifies that the existing configuration would not allow a single user to bring the machine to its knees? Something like the tests some fps games have to verify the best setting...

[ more ] [ reply ]

simple fork bomb? 2005-03-20
Anonymous

How about computing the limits based on processor speed, memory, hard disk partition space, etcetera? That information is available to both the installer and the OS, so they should simply apply limits like that.

e.g: User allowed RAM = (RAM + Swap) / 5...

[ more ] [ reply ]

simple fork bomb? 2005-03-20
Anonymous

I tried this on my Fedora Core 3 machine, and while the load avaerage reached about 850.00, the machine was still responsive. I was able to open a new terminal and do a killall -9 on the process.

The default process limit on Fedora Core 3 is 8192.

-Jeremy...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-17
AdamW

What security level of MDK did you test this on? The default security level is intended for single-user or trusted-circle desktops and has little emphasis on security from rogue users. The installation specifically advises you to use a higher security level for a server machine. I don't know if high...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-17
Todd Knarr

As some people have pointed out, sane default limits are hard to define. Within reach of me I have machines whose "sane default" limits would vary by 2 orders of magnitude, and I can make an argument for a machine that should sanely have a default an order of magnitude smaller yet. With that much va...

[ more ] [ reply ]

Intended use dictates the limits 2005-03-17
Erik Keller (1 replies)

I have to agree with most of the comments here, setting an artificial limit to the number of processes cannot be done in a "one size fits all" manner. And while testing things, I don't want the kernel telling me: "You are not allowed to spawn/fork another process, mate. Change the settings."
IMHO, ...

[ more ] [ reply ]

Intended use dictates the limits 2005-03-17
Jason V. Miller (Author) (4 replies)

I'm seeing a lot of the same comments here, so I'm just going to respond to this post, which seems to have some of the main points in it.

"And while testing things, I don't want the kernel telling me: "You are not allowed to spawn/fork another process, mate. Change the settings.""

You have jus...

[ more ] [ reply ]

Intended use dictates the limits 2005-03-18
Erik Keller (1 replies)

Maybe I didn't stress enough that I agree that something has to be done, I therefore suggested a script to enforce secure settings. I really like the Solaris approach, there is a script covering the most important bases, the admin just has to run it. The script issues a warning about "increasing sec...

[ more ] [ reply ]

Maybe just use proper distros where needed? 2005-03-20
Michael Shigorin

Well the message "distro makers should have done it" is equally true or false depending on _what_ is "it".

They're routinely doing a bunch of things administrators would have to even more routinely perform otherwise, and the only sane proposal I see here is some kind of "security level" (btw, d...

[ more ] [ reply ]

Intended use dictates the limits 2005-03-18
Jim

"You have just chosen usability over security. Sure, security is a balance between good usability and good security, however, I personally think that this is a bad place to make a compromise. How hard is it to bump up your limits, if required? "

Under OpenBSD, you must edit the kernel source code...

[ more ] [ reply ]

Intended use dictates the limits 2005-03-23
Anonymous

This all brings up an interesting point about a targetted market.
All the different distros are trying to be hammered onto the desktop as an alternative to Windows. If this is the case then perhaps when they specify the option to install a desktop they should create this "sane" limit.

The point...

[ more ] [ reply ]

Intended use dictates the limits 2005-03-25
Anon

all,
would it be too far fetched to expect a kernel RPM to set this reasonable starting limit based on the number of processers, type, and the Mhz speed of them?

You can find this out by parsing /proc/cpuinfo... Just my 2 cents.

It should be easy to come up with reasonable limits with a littl...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-17
Anonymous (2 replies)

"There are so many great projects that add security to the Linux kernel. GRSecurity and PaX come to mind immediately. But these products could do so much more if they, or at least some portions of their technology, were included in the base Linux kernel."

You haven't been looking.

PARTS of bot...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-17
Jason V. Miller (Author) (1 replies)

If you can provide some more information / links / URLs, it would be helpful. Searching for LSM gives me the following site.

Linux Security Module
http://lsm.immunix.org/

The last update seems to be from around mid 2003. Also, I see nothing for the 2.6.x kernels....

[ more ] [ reply ]

LSM is in the standard kernel. 2005-03-18
Anonymous

so the EXTERNAL version is not being maintained as much. It is really only usefull for really old kernels (2.3 was where it started; most 2.4 kernels required the patches)

The current activity is via the LSM mailing list and the LKML list.

The LSM is part of 2.6, as is SELinux, though you do h...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Anonymous (1 replies)

Having talked to some of the grsec devs over the years, it seems to me that they're not even interested in getting into the mainline kernel, so your lambasting them for not complying with whatever rules is missing the point. Otherwise i'm sure you can point out all the mails on lkml where the grsec ...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Anonymous (1 replies)

"why not answer those points.."

No problem.

1. the patch is too invasive and disruptive to the kernel (as in "too many different interfaces that the developers can't maintain while other kernel API changes are made".
2. the patch is too large to be analyzed by the developers - so break it dow...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-19
PaX Team

[thanks for the anonymous guy pointing to this thread/discussion]

1. there're more issues with LSM than you answered, and those you answered prove the politics at play. SELinux wasn't rejected due to its invasiveness (LSM is nothing less invasive than SELinux was/is, yet it's 'in' now), it was re...

[ more ] [ reply ]

Once again... 2005-03-18
Anonymous (1 replies)

Once again, another badly misleading headline from tis author. Last time, "Linux Kernel Security is Lacking" led to a discussion about the lack of a kernel "security coordinator", an issue that has little or nothing to do with the actual security of the Linux kernel (and was founded on some very que...

[ more ] [ reply ]

re: Once again... 2005-03-18
editor

Jason didn't pick the headline, I did. More important than the headline, however, is the tagline which clearly mentions fork bombing in Linux.

Thank-you for your attention.

-editor...

[ more ] [ reply ]

Debian not vulnerable? 2005-03-18
Wilmer van der Gaast (2 replies)

I installed a fresh and new Debian system a couple of weeks ago. Since it's my first dual CPU box I was curious how it would survive a fork() bomb, so I tested it.

And guess, it didn't like it at all, even the local console was almost completely dead. Had to define sane ulimits myself to make the...

[ more ] [ reply ]

Debian not vulnerable? 2005-03-18
k_the_c

http://catb.org/~esr/jargon/html/F/fork-bomb.html

The shell script listed in the above link took down a FC3 and Debian MIPS system. Amazingly devious....

[ more ] [ reply ]

Debian not vulnerable? 2005-03-18
Anonymous

don't read into it too much. writers probably just another "apt-get everything" deb. fanatic...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Matthew

>>"1. were your limits rationally set? As >>in sized for your system. My limit is >>4095 (though I REALLY shouldn't do >>that...)"

>No, they weren't. That's the point. They >should be reasonably set by default. >Should a regular user *really* be allowed >to run 4095 processes on your machine by...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Gentoo User (1 replies)

While this article is very informative (I happen to be a gentoo linux user who is getting slammed by what I beleive to be a botnet) I'm somewhat upset that it doesn't go into any detail on how to fix the problem. Thank you for pointing out the problem, but that doesn't really help much if people do...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Another Gentoo User (2 replies)

Yeah! Me 2! Someone please help me out here.... Although I am unknowing of what this problem is, I'm not ignorant. Someone please tell me:

1. How do I know I have this problem on my Gentoo box?

2. What can I do to fix it, if I do have it?

3. This is limited to folks, I've given shell access...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Gentoo/Debian/OpenBSD user (1 replies)

Go and edit /etc/security/limits.conf if you're worried about user accounts forkbombing; in Gentoo, it's commented with basic instructions for setting up user limits.

If you want to see the current limits for a user, run ulimit -a; note that as an ordinary user (not root), you can only move the l...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Jason V. Miller (Author)

Thanks for posting this information.

These articles are supposed to be non-technical opinion columns, so I can't really get into gory details. Regardless, I've received feedback from several people asking for more information on mitigation, so I appreciate you taking the time to post this....

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
gregm

To see if you're vulnerable, drop this into a script:
(`$0 & $0 &`)
Warning: running it can bomb your box! You might want to place something like 'ulimit -u 2000'ahead of the above line. Depending upon your system, that might allow you to recover by issuing a lot of kills.

I was able to, at any...

[ more ] [ reply ]

python forkbomb one liner + thoughts 2005-03-18
X

this python one liner can be used to forkbomb rather quickly:

python -c 'while 1: __import__("os").fork()'

as for your statement regarding NetBSD handling forkbombs without issue: from a completely regular user account on my server and using the stated python forkbomb code -- it brought up res...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
FreeBSD user (2 replies)

My default FreeBSD 5.3 desktop box took about 10 minutes to completely lock up when I tried this. I had to hard reset to get out in the end. Looking at my login.conf, it seems user resource limits are off by default in FBSD 5.3...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Jason V. Miller (Author)

The FreeBSD machine that I tested this on was a 4.11-RELEASE box. Although there have been a bunch of changes made to this machine in general, I haven't changed anything regarding user limits....

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-19
Ryan

My 5.3 box killed the forkbomb in a couple of minutes but it performed poorly while it was running....

[ more ] [ reply ]

Debian IS vulnerable! 2005-03-18
Anonymous (2 replies)

From my Debian Unstable box:

eherr@chernobyl:~$ 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 ...

[ more ] [ reply ]

Debian IS vulnerable! 2005-03-18
Anonymous

Maybe that's what makes it "Unstable"?!...

[ more ] [ reply ]

Debian IS vulnerable! 2005-03-18
Anonymous (2 replies)

Looks like this is something they need to fix, especially before the next version is released.

On my stable box:

$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unl...

[ more ] [ reply ]

Get SuSE 2005-03-18
Anonymous

My SuSE laptop, out of the box:

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
pip...

[ more ] [ reply ]

Debian IS vulnerable! 2005-03-18
Anonymous

I remember fork bombing my old Slackware box back in the early 90s, and later trying it on Debian and finding it handled it fine and thinking that the problem had been fixed.

ULimit settings are configured in /etc/security/limits.conf so it's easy to set your Debian system up. I also think it wou...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Gentoo User

I tried forkbombing on an FC3 box and it died. All 3 of my Gentoo boxes held up ok, with the user's workbomb going for about 20 seconds before being killed by bash. I'm not sure what kind of setup you did. I don't recall having done anything special to prevent resource abuse. Thus I have to ques...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Anonymous

Whining about limits shouldn't be touched by the distro makers and should be set manually since they are needed for server work etc etc is pretty useless. Imagine having to go somewhere just to reboot it just becouse you can't login any more.

I remember a friend having this problem a long time ag...

[ more ] [ reply ]

Linux only? perhaps across the board problem? Conflict of interest? 2005-03-18
glotfeltys@gmail.com (1 replies)

Jason,

You work for Symantec - a primarily Windows based vendor. (Come to think of it wasn't SF bought out there by your company as well?) My main point is this article would be better titled : Computer OS's still not secure enough by default. Of course that headline is not as exciting or good ...

[ more ] [ reply ]

no conflict, thank-you very much 2005-03-18
editor

There is no conflict of interest. SecurityFocus retains 100% editorial control and content is not directed by Symantec in any way, shape, or form.

Most of our columnists do not work for Symantec anyway. All are free to express their own opinions, which are not the opinions of any company they wo...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Angel Freire

This is a extract of Gentoo Linux Guide to security that can be found in http://www.gentoo.org/doc/en/gentoo-security.xml:

--
6. User/group limitations

/etc/security/limits.conf

Controlling resource usage can be very effective when trying to prevent a local Denial of Service or restricting...

[ more ] [ reply ]

Gentoo vulnerable? 2005-03-18
Anonymous (1 replies)

You decry the fact that grsecurity and pax aren't in Linux distro kernels... yet the gentoo kernel does indeed come with grsecurity and pax. While I haven't tried forkbombing my gentoo box, RBAC should prevent that.

Now, if you chose the vanilla Linux kernel install or something else other than t...

[ more ] [ reply ]

Gentoo vulnerable? 2005-03-18
dk

This whole story is a bit odd to me as this topic is rehashed every so often. The linux user should configure this themselves, or not use linux. :) rlimits are *nix 101.

>> yet the gentoo kernel does indeed come with grsecurity and pax.

Kinda hard to say what's "default" concerning gentoo, as ...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Saltine (1 replies)

With Gentoo you are responsible for building your own kernel. If you left this vulnerability open its your own fault not Gentoos....

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-20
Anonymous

yeah right as if you know how to limit it lol!...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Stef (1 replies)

I think your article merges two different points:
- 21 vulnerabilities are a concern (but on most ditros, not all were there since distros kernels are heavily patched)

- if it is a local user, then the administrator may see how he behaves, you'll always be able to scratch a computer, unplug the ...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Jason V. Miller (Author)

"Last, could you be more precise: wheren't you able to connect on the computer from another one?"

No. SSH runs in user-space, and everything user-space was pretty much totally unusable (preventing you from logging in to fix the problem). The machine responded to ICMP echo requests just fine, howe...

[ more ] [ reply ]

Jason's opinion is too biased 2005-03-18
Anonymous (2 replies)

It is clear from Jason's articles, whether he'll admit it or not, he just doesn't like Linux or despises it's success. In his last article he admitted being "a huge follower of BSD-based operating systems". He continues that statement with "I keep an open and analytical mind when looking at any OS...

[ more ] [ reply ]

Jason's opinion is too biased 2005-03-18
Anonymous

The interesting thing to note here is that his home machine running Mandrake was forkbomb-able due to his misuse and misconfiguration. From the beginning of the install, YOU choose the security level which ultimately determines your ulimit settings as well as a secure kernel. Here's an example of Ma...

[ more ] [ reply ]

Jason's opinion is too biased 2005-03-18
Jason V. Miller (Author) (1 replies)

"It was also brought up by one of the users that his beloved FreeBSD was also brought down by a fork bomb. Does this mean that FreeBSD kernel security is lacking???"

I mention in my article that this isn't an obvious kernel issue. That being said, if FreeBSD 5.3 can be brought down by by a non-pr...

[ more ] [ reply ]

Jason's opinion is too biased 2005-03-23
Anonymous

Jason,

I am glad that you wrote the article. It brought my attention to a problem that I did not know existed. I had read about fork bomb attempts on the "big iron" of the early 90's, but I thought all that was in the dead past. Imagine my dismay when I was able to kill my mail server with the...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-18
Anonymous

Ubunutu Warty with the latest packages is vulnerable as well...but that's probably because it based on unstable I believe...

[ more ] [ reply ]

Take the first step author. 2005-03-18
EG (2 replies)

So several distributions of Linux are vulnerable. Great.

And the teams creating the distributions should be more proactive about a solution. Good idea.

But if you're going to suggest such things then why don't you take the first step and tell Linux users what steps they can take to secure th...

[ more ] [ reply ]

Take the first step author. 2005-03-18
Anonymous (1 replies)

In Red Hat/Fedora, it appears you need to take two steps:

1) assign all users to the same group (like "users", or "students")
2) edit /etc/security/limits.conf. Uncomment the line which refers to "nproc", and use the group name which you've assigned, preceded by the "@" symbol (like "@users" or ...

[ more ] [ reply ]

Take the first step author. 2005-03-18
Anonymous

It's much easier just to use the wildcard character '*' to set the default for all users.
Add the line:

* hard nproc 16384

to /etc/security/limits.conf

(this is on my Fedora Core 3 box)

However, don't worry about this. In all likelihood the only person who wi...

[ more ] [ reply ]

Take the first step author. 2005-03-18
Jason V. Miller (Author)

These are opinion columns, not technical articles. That being said, I have had several requests for additional technical information from readers of this article, and I will be sure to include at least a reference for people to get additional information in the future.

Thanks for your feedback....

[ more ] [ reply ]

Solution was?... 2005-03-18
Anonymous (2 replies)

Did I miss the link to the solution? Say, for instance, that I'm a barely UNIX-literate user that wants to fix this problem on his Mandrake box... You've just pointed out the problem... Solution? Anywhere? Anywhere?...

[ more ] [ reply ]

Solution was?... 2005-03-18
Anonymous

On a Debian system, and perhaps others, look in the file /etc/security/limits.conf. My copy has some good comments in it (a nice thing about text based config files).

Failing that, every distribution should have a /etc/profile and should ideally use it as part of the login process. Best also loo...

[ more ] [ reply ]

Solution was?... 2005-03-19
Anonymous

Yea, you missed the solution a good few lines up....

[ more ] [ reply ]

Not quite a valid criticism... 2005-03-18
Anonymous (2 replies)

While it's true that you can fork bomb a box by default, this isn't a wholly unreasonable default. Linux is typically deployed as a user workstation or a dedicated server without non-administrative users. In such and environment, you probably do not need, nor want the limit's set.

The idea of imp...

[ more ] [ reply ]

Not quite a valid criticism... 2005-03-20
darwin lopez

i think your right about this. it's not a kernel issue or a distribution issue it's more of a SECURITY POLICY. if you enforce it YOU'LL HAVE IT!.. it's plain and simple.

i won't go into the default installation war-of-the-OS hype thing because i think it's much ideal to deal with the current issu...

[ more ] [ reply ]

Not quite a valid criticism... 2005-03-20
Anonymous

Just wanted to make an observation:

I did appreciate the information that was brought out on this thread about Linux OS's. Thanks to everyone contributing test results and OS tweaks and ideas. We can all learn or contribute in these forums. Let's keep them going.

But I do have a problem wit...

[ more ] [ reply ]

Linux^H^H^H^H^HAny Kernel Security, Again 2005-03-18
Anonymous

try this one on freebsd:

#include
#include
#include
#include

#define MSIZE 4097
...

[ more ] [ reply ]

Silly IDS kid needs to learn C. 2005-03-19
OpenBSD is for Girls

try this one on freebsd:

#include
#include
#include
#include
...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-19
Anonymous

It's irresponsible to publish such a security flaw that you obviously know how to easily correct and to not also post the fix....

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-19
Anonymous

How about a kernel security distributed computing package?...

[ more ] [ reply ]

FC2 vulnerable, too - copy of script enclosed 2005-03-19
Anonymous

this is from the discussion of the OSX fork bomb problem many of us were making fun of last year, I changed the prompt from root to user ... and had to reboot after running the script. The ones who are saying "no problem" should try it.

http://apple.slashdot.org/apple/04/10/23/0229241.shtml?tid..
.

[ more ] [ reply ]

Linux Kernel Security 2005-03-19
Anonymous

There is propably quite a bit of truth in this article ... there are all these hardened Linuxes & special security patches but Linux isnt secured to the best by default it seems .
so respect :-) to the author of the article ... hopefully it will have an effect ....

[ more ] [ reply ]

Does it work on Mac OS X? 2005-03-19
huwr

Out of curiosity, I tried this on Mac OS X 10.3.1.

It is not vulnerable, probably due to the base in projects like FreeBSD. It did, however, stop my user from creating any new processes, but other users kept working fine.

This isn't definite because this is also not the latest version of Mac O...

[ more ] [ reply ]

Fresh FreeBSD 5.3 install 2005-03-20
Anonymous

$ su
su: Sorry
$ ulimit -a
cpu time (seconds, -t) unlimited
file size (512-blocks, -f) unlimited
data seg size (kbytes, -d) 524288
stack size (kbytes, -s) 65536
core file size (512-blocks, -c) unlimited
max memory size (kbytes,...

[ more ] [ reply ]

Gentoo: emerge hardened-dev-sources 2005-03-20
Scoove

What's difficult about that? Reading the kernel options portion of the Gentoo Handbook, one can quickly learn how to automatically select a PaX and GRSecurity hardened kernel, either in 2.6 or 2.4 flavors.

And better yet, stack smash protection is explained in simple steps.

Apparently the auth...

[ more ] [ reply ]

Try, disk I/O and mem. alloc 2005-03-20
Bipin Gautam

windows is horrible at this!
>shouldn't you people already have your boxes secured?
yap, that's why we have PAM.

i tested it in windows 2003 server long ago... its horrible. If you have a local logon, in windows its a shame to to crack that box. There are lot of ways to disrupt the service.

...

[ more ] [ reply ]

Solaris 10 vulnerable, too 2005-03-20
Anonymous

solaris 10 is vulnerable, too ... (tested on x86-edition)
so it seems not to be a 'linux-only' problem .....

[ more ] [ reply ]

Why its Valid! 2005-03-21
Anonymous

No desktop user should be running more than 1000 processes. Hell our 5 user desktop server (think thin clients) is only running about 600! Rarely does that total exceed 1000.... I've yet to see a user hit the limit of 1000 processes.

Knoppix also seems to have resonable Process limits, expecte...

[ more ] [ reply ]

Mandrake 10.1 didn't freeze... 2005-03-21
Anonymous

I ran forkbomb - http://home.tiscali.cz:8080/~cz210552/forkbomb.html - on MDK 10.1, my mouse slowed down for a couple of seconds, that was it.
...

[ more ] [ reply ]

Scaremongering. Not a serious problem. 2005-03-21
Anonymous

Let's order our threat levels roughly...

1. Remote execute arbitrary code as root exploit.
2. Other remote exploits.
3. Remote DoS attacks.
4. Local root exploits.
5. Local other exploits.
6. Local DoS attacks.

This... 'attack' ... is 6th on my list of threat levels. I question the sanity...

[ more ] [ reply ]

DEBIAN 2005-03-21
Anonymous (1 replies)

Debian's permissions allow roots home dir to be read by anyone by default....

[ more ] [ reply ]

DEBIAN 2005-03-22
Anonymous (1 replies)

False (at least for woody).

ls -ld /root
drwx------ 43 root root 4096 Mar 3 12:27 /root

...

[ more ] [ reply ]

DEBIAN 2005-03-23
Lucio

True for Sarge!!! But Sarge is currently "testing" and its security issues are not addressed by design until it becomes "stable"....

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-23
Anonymous

Also what I find interesting is if you're running linux under a VM on a windows box, it slowly but surely eats away at resources allocated to the VM.

That's definable but the interesting part is if you set your resource limit on the VM to more than is available on the windows box(which is allowed...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-24
Anonymous

Ok, so you tested on Mandrake, Gentoo, Redhat, Debian, big deal. I want to know what versions and if they were fully patched. That, and I want you to test on some more distros. It's not cool to be "well this distro died, this did not" without more information. I've seen this kind of thing before...

[ more ] [ reply ]

PAM 2005-03-24
Maestr0

"yap, that's why we have PAM."
Seriously.

Although I was suprised when I noticed you could fbomb by default, its not terribly hard to fix, and I really wasnt aware this was a big secret, its been like this for ages. And it is possible to crash Debian too, just try different resources too exhaus...

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-28
Anonymous

You must be using FreeBSD 5.x. My 4.8 machine at home succumbed very quickly to this attack, while my Fedora Core 1 and Red Hat 8 machines both restricted the number of processes I could start (as non-root)....

[ more ] [ reply ]

Linux Kernel Security, Again 2005-03-29
Anonymous

Well, it is now 3/29/2005 and the kernel vulnerability count has risen to 47 for the year......

[ more ] [ reply ]

Linux Kernel Security, Again 2005-09-01
tcsh

This silly bugs only happen on the bash shell which is the default shell on almost all Linux distribution.
Try execute it on tcsh shell or another shell which is the default shell on BSD ,....

This is the proof on my system :

[royke@tigershark royke]$ tcsh
[royke@tigershark ~]$ :(){ :|:& };:...

[ more ] [ reply ]