Linux Kernel Security. forkbomb havoc

[Bazoukas]

http://www.securityfocus.com/columnists/308?ref=rssdebia



The cracker and the attacked IRC chat
http://www.securityfocus.com/archive/75/393292

[muzzy]

Vulnerability to forkbombs isn't the only stupid weakness of linux, although it's a damn obvious one. Further, on some systems where forkbomb doesn't do damage, forkmallocbomb still will.

[Calum]

this cropped up a good while ago on void main's forums, the solution is to use ulimit to prevent it:

http://voidmain.is-a-geek.net/forums/viewtopic.php?t=447

some vendors of course do not have this set by default at a sensible value

[Calum]

the second comment on the above article is this, i have broken it up to actually mention my thoughts on it:

Yes, you can use ulimit. By why should the sysadmin have to bother to do more work to lock a box down?

what else is the system admin doing? this is the admin's job.

After an install the box should be "secure".

who says? that'd be ideal, but if it's your system, it's also your responsibility to ensure its security.

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 makes no sense.

This is about sane defaults. The Debian team got it right in this case; most other distributions did not.

fair comment, and this is true, but you cannot rely on the vendor to solve your problems for you.

[WMD]

This is easy to fix: ulimit -u 100

That's what mine is now.  The Slackware default was 4095.

Add this to /etc/profile and you're ok.

EDIT: I ran a test with -u 45.  It starts up like six processes, and the computer lags.  I've decided to lower my limit to that.

[muzzy]

Oh my, oh my! So, it's ok for linux box to suck after install and then it's admin's job to set it up properly, but same doesn't apply for windows?

[muzzy]

Also, /etc/profile is only executed for login shells. So, this doesn't solve the problem.

[WMD]

Everything starts at a login shell.  My desktop comes from the shell that I typed "startx" from.

If it doesn't, then just where WOULD you have that command?

[muzzy]

hint: What starts the login shell? And what started that process? What other processes are started in similar fashion?

There's a lot of choices for exploitation.

[Calum]

muzzy, your accusation of double standards isn't actually aimed at any comment in particular that i could find. who are you accusing of making this comparison?

i would say the vendor is responsible for the shortcomings of their product. so: microsoft is responsible for the shortcomings of mswindows, mandrakesoft are responsible for the shortcomings of mandrake linux and so on. slackware, debian and so on are organisations, so their output is not "product" as such, but, yes, they are still responsible for their output, although of course with their stuff their licences more or less say "use at your own risk". the fact people continue to use slack and debian shows how good a job they're doing of living up to their commercial counterparts. linux is not to blame, the vendor of a specific system where a problem exists is to blame, to the extent that they make certain claims that their software will work, in the EULA and elsewhere.

in fact the GNU GPL has a clause specifying that the software is not guaranteed to be useful for any purpose, and i do not think microsoft has this in their EULA (check it out if you like, i have some of their EULAs archived at http://www.polytheism.org.uk/openopen/files/licences/ but can't be bothered to check right now). while this is not an excuse, it does mean that microsoft make more claims about the "quality" of their software than any GPL software does, not to imply that any entire "linux" distribution is GPL software, but you get the idea i am sure.

re: the ulimit setting, i would put it into rc.local to be honest. fair enough, this probably isn't the "right" place for it, but it will work. i might mention (since we mentioned the slack /etc/profile) that that file also, by default, adds ./ to the $PATH for the root user! this is a really stupid move in my opinion, i think for more than abvious reasons, and the first thing i do on a slack installation is edit the /etc/profile and get rid of this.

but the main point is that certain people still do not realise who is responsible for an end product such as a complete operating system. it is the vendor/distributor of that system, ie: the organisation responsible for putting it together in the first place. Once it is installed, a specific installation of that system becomes the responsibility of that system's administrator. i would say this is a fair model and is true to life, anyway.

[muzzy]

I was going through other threads to find what I'm referencing to, but there's just too much text to read through it all again. I see that you're saying in another thread it's the administrator's job to keep the system secure. Some other people were bitching about how it's unfair that I compare properly configured (and thus, administrated) windows to a linux system.

I'm getting a little tired of arguing with multiple people without remembering whose stance was exactly what. You all seem to have different opinions, yet you all argue with me and not amongst each others.

Anyway, the rc scripts differ from system to system, and there's no rc.local in every system. Even then, you aren't guaranteed secure because services you run might set the hard limits up again... There are kernel patches which provide better solutions, but again, these would need to be applied.

Also, putting too much responsibility on the administrator is just screwed. If the vendor doesn't fix security holes, is it the admin's responsibility to write binary patches? Well, obviously nobody else is going to do it, but whose responsibility is it really? If you're taking the stance that it indeed is administrator's responsibility to keep the thing secure, no matter what, then we're back to square one regarding my stance on windows and its security.

[Calum]

I was going through other threads to find what I'm referencing to, but there's just too much text to read through it all again. I see that you're saying in another thread it's the administrator's job to keep the system secure. Some other people were bitching about how it's unfair that I compare properly configured (and thus, administrated) windows to a linux system.

yes X11 said this (ak! sorry, he is now called kintaro on this board), and to a point he was correct. if you want to do tests to compare one with the other, it's meaningless unless the things you are comparing are on a level field. comparing two systems that are administered properly, using the tools available to the administrator is fair, and comparing two systems brand new, as is, out of the box is also fair, so long as in both situations, people know what the comparison is. comparing one system that is administered well by somebody who knows the system with another system that is badly administered for any reason is not fair, and the results are meaningless.

I'm getting a little tired of arguing with multiple people without remembering whose stance was exactly what. You all seem to have different opinions, yet you all argue with me and not amongst each others.

this sounds pretty paranoid, and in fact it is untrue. there is more than one member i have had recent disagreements with, though you might not be too lucky finding them since they haven't been all in one thread, or nearly so public facing as the "get rid of shit in windows" thread, or whatever it was called. people will have differing opinions, and if you can't remember who said something, don't just claim that the nearest respondent had those opinions which are contrary to your own. perhaps this assumption leads  you to believe that people are always against you here? the fact is i think most people consider you to be knowledgeable and fairly understandable (which is pretty good for these boards!)

Anyway, the rc scripts differ from system to system, and there's no rc.local in every system.

yes this is true. i think now that i have looked a little on my home system, that on an LSB compliant system, the right file to modify would be /etc/init.d/boot.local (but correct me if i am wrong folks!) since this script gets executed on any LSB compliant system before we enter our default runlevel or allow anybody to log in.

Even then, you aren't guaranteed secure because services you run might set the hard limits up again...

well of course you can just set those hard limits in that file, can't you? or have i missed something here about who is allowed to do what?

There are kernel patches which provide better solutions, but again, these would need to be applied.

yup, or accepted into the actual kernel source. i have no idea what the situation is with this or if these solutions are indeed better than ulimit, or what the arguments are, so i can't comment at all here.

Also, putting too much responsibility on the administrator is just screwed. If the vendor doesn't fix security holes, is it the admin's responsibility to write binary patches?

ok, i see your point, there's a line to be drawn, and you reckon setting a reasonable ulimit value falls on the vendor side of the line, while i don't agree. fair enough. i would say that anything that can be done in readable config files or using a GUI that comes with the system, should be the admin's responsibility and anything else is the vendor's. how's that? not all vendors agree. like the whole RHN thing. if i install red hat, the first  thing i do is remove that, because i want to use apt to do my own software upgrades/installs, but red hat doesn't give you the option not to install it at install time, because it assumes that it's red hat's responsibility to have rhn warn you to upgrade things.

Well, obviously nobody else is going to do it, but whose responsibility is it really? If you're taking the stance that it indeed is administrator's responsibility to keep the thing secure, no matter what, then we're back to square one regarding my stance on windows and its security.

yep, i think i mention where i would personally draw the line above, but you're kind of suggesting a model where there's a problem and *no* solution, whereas usually with the open source stuff i find that if a problem arises there are usually *several* solutions, and this is something people complain about too sometimes. remember when people moaned that linux had no native journaling filesystem? very quickly several appeared, ext3, jfs, xfs, reiserfs and so on. some distros chose different ones to use as default, and as a result the default filesystem for one linux might not be supported by default, by another linux system. This is the downside of choice, if you are given a choice (as a system administrator, user. or software distributor), you have to make a choice, and people will make different choices. this can be seen as a good or bad thing depending on what your priorities are.

[muzzy]

Privileged processes can set hard limits to anything they want, unprivileged and only lower their hard limit. This is why ulimit in /etc/profile works for loginshells in the first place. The user can limit the shell, but not unlimit. Same isn't true for privileged processes, see setrlimit(2) manpage for the implementation of the resource limits. What I'm saying, is theoretically apache or cron or whatever daemon could just set the limits back to some horribly large one, and then processes spawned by it would inherit those values. You just couldn't be sure.

Further, setting the limits for init, even if it works, doesn't solve the problem. The user can still bring down the system, and as long as the forkbomb process lives nobody else can make new processes. I don't have a linux box to test this behaviour, but either this happens or it isn't effective in the first place. The system will remain responsive, but as no new processes can be spawned, it's pretty much useless.

Many kernel patches indeed provide better solutions, such as per-user accounting for all the process resources. This way the user wont be able to escape hard limits, since they're enforced by the kernel and per-uid. I believe grsec does this, for example.

[muzzy]

What comes to having choices, it's indeed both good and bad. The real problem is that most casual users (who have been forced to be administrators, by having a computer at home) won't have enough knowledge to make informed decisions. For this reason, it's a good thing that the vendor does the decisions for the administrators. For this reason, vendors should have responsibility for the security and performance and functionality of the system. Administrators these days just can't be expected to have enough arcane knowledge about internals of the system to be able to make good decisions. Otherwise you get people putting ulimits into rc scripts and login profiles...

[Calum]

i cannot agree with that last post on two counts.

firstly you more or less say that vendors are responsible for the security and stability of the systems they vend, because administrators are too dumb. with logic like this it is clear to see why you prefer windows over other OSs. no doubt using windows  and talking to windows users is what brings you to this conclusion in the first place.

secondly, once again you criticise potential solutions without yourself explaining the answer. by suggesting that people are idiots for suggesting the ulimit line be put in one script or another you are attempting to stifle discussion about this issue. also, you do not clarify where  the correct location for such a line might be, which is something you should be doing if you are so staunch about how wrong everybody else's solutions are.