Slashdot Mirror
Some Linux Distros Found Vulnerable By Default
TuringTest writes "Security Focus carries an article about a security compromise found on several major distros due to bad default settings in the Linux kernel. 'It's a sad day when an ancient fork bomb attack can still take down most of the latest Linux distributions', says the writer. The attack was performed by spawning lots of processes from a normal user shell. Is interesting to note that Debian was not among the distros that fell to the attack. The writer also praises the OpenBSD policy of Secure by Default."
Kittens are vulnerable to forks by default as well - you can easily get at the kernel if you just - oh, hang on, a different kind of fork, you say?
Thank god I use Windows, I'm safe!
Let's see how long it will take before someone says the study is invalid...
Sorry but the ability for a non-privileged user to run as many programs as the like is a feature, not a bug. Inability to turn that feature off would be a bug, but given that few modern Linux boxes are actually used as multi-user remote-login accounts, it's a completely unecessary overhead.
And if you are administrating a true multi-user old-style-Unix type server, you should know enough to stop people fork bombing you (i.e. quotas).
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
So?
There are lots of ways a normal user can take down a system. I don't think that there is any reasonable way of preventing all of them
That is no reason why the same should be true of Linux. Or any other OS for that matter.
So what would a good limit to the number of processes spawned be?
I mean what can say what is good for everyone?
Saying that if you think the fork bomb is good grep bombs are more fun and particularly good for silincing the mass of Quake 3 players in an undergraduate lab:
'grep foo
Oh hang on did i just discover a new exploit
So what? Anybody in their right mind would have locked down their box if they're letting third parties access it remotely.
Running around screaming "FORKBOMB! FORKBOMB! The sky's falling in!" seems to be a common pattern every few years. If you know what you're doing, it's trivial to prevent and if you don't know what you're doing, why are you running a public box?
Fork bombs only work if you can log into the system in question. This is a bit lower priority than your usual vulnerabilities which allow outside attacks.
"I'm a leaf on the wind. Watch how I soar."
-Hoban Washburn
Sorry, but this article seems pretty retarded to me. Windows is insecure because people can use IE bugs to install scumware that takes over your entire machine... Linux is insecure because ordinary users who are legitimately logged into your machine can fork off as many processes as they want? Huh?
Sure, maybe if you're running a server that allows remote logins, you want to restrict how many processes a user can run. But as a single-user system, I want to be able to run as many processes as I choose, not be restricted by the distribution author's ideas of what's good for me.
I really wonder what kind of Debian installation he runs. Just a couple of weeks ago I had to reboot my Debian box after some experimenting with an obfuscated fork bomb. Won't work again now that I set some ulimits, but they're not there by default.
:(){ :&:;};:
In case anyone is interested, here's the obfuscated fork bomb:
Which other ones were not affected? Why aren't they noteworthy and interesting?
A forkbomb is just a relatively simplistic way to mount a resource exhaustion attack. I would be extremely wary of anyone who claims that their UNIX class operating system is immune to resource exhaustion from a local user. There's just too many resources that can be commandeered, and to lock them all down would leave you with a system that's so restricted as to be nearly useless as a general computing platform.
/. if they're reporting this as news.
It must be a slow day on
script kiddy admits to fork bombing... http://www.securityfocus.com/archive/75/393292/
No, I understand the article. I just couldn't resist the jab. The fact is that GNU/Linux ought to be the best it can be in and of itself. That some distributions are screwing that up and making very poor defaults is not to be forgiven. Not at all. Especially when it isn't difficult to do better.
How to use coral cache: http://slashdot.org.nyud.net:8090/~oscartheduck
User - Give me a gun I want to shoot my foot off.
...[BSOD] fatel exception
*NIX - Sure here it the gun it's loaded
Windows 9* - Are you
Windows NT - Are you sure?
- Sure your sure?
- Oh by the way sorry your only admin,
not the SYSTEM account so I can't let
you do that.
I know it's a bit trollish, but I like the ability to over rule what the OS thinks is best for me.
And as previously mentioned you can turn this option on easily enough.
On the 3 distros listed as vulnerable, the default settings would stop any remote person from having a chance of getting a shell open on the box to perform the fork attack in the first place.
If a person has enough access to the machine to be able to "forkbomb" it, then there's plenty of other nasty things you could do to it.
Doesn't OpenBSD still install 'ftpd' by default? Although it is not turned 'on', the fact is it is still on the file system ready for exploit and requires rigoriously patched unless you take steps to remove it. Doesn't this seem like a dubious definition?
I'm all for making special install kernels and distros "out of the box" to be as hardened as possible. I would love see many distros do a "paranoid" configuration. There are plenty of things OpenBSD does right but that does not excuse OpenBSD. Just like Linux and every other operating system out there, they can still strive to do better.
Unprivileged user can take down entire system by unplugging machine from power socket.
... some birds fly south for the winter, my belly sometimes makes gurgling noises and jam tastes nice on toast.
So what? Publish the vunerabilities, patch them, move on. Sheesh..
"So there he is, risen from the dead. Like that fella, E. T." - Father Ted Crilly
:(){ :|:&};:
All my servers have multiple users. Those users are system accounts to run different software, and I do not want any of them to be able to cause a problem to the entire server. Reasonable limits should be in place by default, and those of us who actually need higher limits for certain users, can raise those limits.
Even on a single user desktop machine, its nice to have limits so shitty software can't take down my entire machine. With limits I can just log in on another terminal and kill the offending program, without limits you get to reboot, and lose any work you were doing.
I bet that one of them is Suse. I installed it on a family box trying to ultimetly getting my family to use slack10 by the time i move to college(in june). Suse looks nice but they just had that damn box keep poping up saying update this update that. The "non comercial" distros like Slack, gentoo and debian are perty secure, but its Suse, mandrake nad Red Hat(a lesser extent) which are less sceure and more updating (thats just my personal expericence and listening to other)
This is getting modded as funny? Are you joking? It's a clear troll. Replace "windows" with "linux" and it would have been modded down faster than GNAA.
Free of Flash! Free of Flash!
This is unacceptable. However before microsoft uses this in one of their ad campagnes I would like to mention the LAND attack
You were running bash then :p
:) .login or .bash_rc files.
I recognise that one... which is always good
just don't leave your box unlocked and have some "funny" person drop it in your
Looks like everyone out there on slashdot think this is not really a problem. Remember when it was discovered that you could get into a xp installation locally with a win 2000 boot cd? Oh, the howling that was heard.
Here is a issue that can be done remotely with only a user account.
Humor from a Genetically Molested Mind
I came up with the idea of a ping/fork DoS attack (mostly as a joke)
:)
In pseudocode:
while (true) {
ping(target)
fork()
}
I seriously thought of posting this to a few script kiddie sites, so the kiddies could crash themselves long before the pinging does any damage
--buddy
Why is the word on in quotes? Yes, ftpd is part of the system. No, it is not running. No, it is not ready for exploit since as mentioned, its not running, and also, what vulnerabilities does it have? That likes saying openbsd is bad because it ships with popa3d. Its right there waiting to be exploited, if you are root, and start it up, and someone finds an exploit for it.
If you don't upgrade your system sufficiently before giving our shell accounts, you're an idiot. If you are joe schmoe and using it as a desktop - you're not giving out user accounts.
Yes, it may be sad to find - but honestly people, local shell exploits exist 'out of the box' - period. It's *pretty much* unavoidable even after proper sandboxes and restrictions have been configured.
And, as a Debian user - I am both insulted and disgusted that it was arbitrarily singled out, I assume this was because of its 'speedy' release cycle. If it was the only one of lots of major versions, then I retract the comment.
cyn, free software and *nix operating systems enthusiast.
The Windows holes aren't in the FRIGGING KERNEL.
As I said many times, comparing Windows security and Linux security is like comparing the San Fransisco 49ers and the Arizona Cardinals football teams, two of the worst teams in the NFL.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
I was apparently getting a new mplayer with every frame or something. Have to quickly VNC from another machine to do a shutdown.
It's funny, isn't it, that on the same day we have a story about Linux distros being insecure by default, EXCEPT Debian, we have another story where Debian is being criticized for not releasing updates more often.
Maybe, and here's a thought, just maybe, it's wise to take a decent, stable distro and perfect it, instead of taking a distro and submerging it in a state of perpetual flux with constant updates.
Just a thought. I might be biased because it's a Debian-based distro that finally put a working Linux on my laptop. But you know what? Every now and then the bias is there for a reason...
Most linux systems are used as desktops, if you use them as a server you don't use the defaults. Now a user being able to crash his own system is nothing new. It ain't nice but as long as it is the user doing it then no problem. Now if this fork could be used to make apache explode and bring down the system THAT would be a boo boo.
Ideally yes the system should not do things that bring it coming crashing down but this is close to blaming a car for allowing me to plow into a wall. Not sure if I want a car/computer telling me what I can and cannot do.
As to how to set the limits on the number of forks. Maybe I got this completly wrong but could it be that this depends entirely on your hardware? Perhaps the latest IBM mainframe can handle a few more then an ancient 386? How the hell is the distro supposed to know what I got?
Security is other people doing stuff on my computer that I don't want and or know about. Me screwing stuff up is my business.
BSD is very solid, this is known. It is also known that BSD has been along long before linux and but has been sucking it exhaust fumes ever since it arrived. For every story about how much more secure BSD is there are a dozen stories about linux actually making a mark on the world. So good. Your BSD survived a forkbomb. But why exactly was the author running a linux desktop then if BSD is so much better?
Another non-story on /. Is the internet going to the way of tv?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
A good vm should do enough accoutning to allow you to log back in and kill those.
So, try this in FreeBSD, and be amazed, now try it in any 2.4 or 2.6 linux kernel, and be disgusted.
You can limit users to using less than 100% of your resources, and those users can still do things. Its still a very usable system. I have this even on my laptop where I am the only user, so poorly written software or random mistakes don't result in me having to reboot my machine. Just the other day I messed up a pike script and it used up all my RAM. But my ulimit was set to 128MB of RAM, so pike just got an out of memory error and exited. Without ulimit it would have sucked up all my RAM and swap and I would have to reboot.
This kind of uninformed and ignorant attitude seems quite common in the linux world now that most users aren't experiences unix admins. It would be a good idea to learn about something before claiming to know how it should be setup.
stop saying lol . jesus wept! i will kill you for saying lol so much! why - o - why. jesus wept (again) oh bloody fuck fuck shit wankstain bastard think of something else, like a proper repliy. Aaaaaaaaaaaaaaah!
Linux users don't know what accounting is yet, because they haven't realised what *BSD is (except maybe that "OpenBSD is really secure, innit, i'm going to use it for a firewall ain't I").
No. I've played with fork bombs in Windows with SFU or Cygwin, and they didn't bring down the system. Seems like there was a sane ulimit on processes.
:|:& };:" (without the quotes) on your bash prompt to see if you are vulnerable.
Try ":(){
Lots of (and the term "lots" is relative) exploits and vulnerabilites being posted these days about Linux distros.
And yet, I haven't seen any real-world problems, unlike the *endless* (and daily it seems) ones aimed squarely at MS.
So, do Linux users run across the same kinds of problems Windows users encounter on a (near-)daily basis, or is all this just theoretical?
So rise up, all ye lost ones, as one, we'll claw the clouds.
Try a WinExec bomb instead. You can bring down the system in 2-3 minutes.
... where gentoo had a default kernel
(can we PLEASE not bring genkernel into this? it sucks.)
Karma: Negative (Mostly affected by dorm trolling)
Mandrake is a user distribution. Often, the user will be running as non-root, but will want many non-root settings (like ulimits). On the other hand, Debian is not mainly a desktop distribution.
The author goes on to praise the BSDs, not bothering to check and see exactly where the "default kernel settings" come from, or that they are "default" at all.
I agree, the kernel developers do not take security seriously (sometimes not even making a new release!). But this is a bad article that should not be on securityfocus or slashdot.
#include
main() {
die:
malloc(9999);
printf("welcome to linux\n");
fork();
goto die;
}
Pretty simple, and will bring most boxes down.
Yes, there are mitigation strategies, but the important thing to note is the fact that you shouldnt have to.
Are some distros more fault tolerant than others?
I have a laptop with a flaky power connector and a totally useless battery. Every now and then the power fails if someone moves it or bumps the table. I started out with Mandrake 9.1 which got pretty trashed after each incident. In the process of getting it back I used a Knoppix cd. I liked it and installed it as my os. (Knoppix is Debian under the hood.) Now a power failure is a nusance but is relatively easy to recover from.
So the question is: Is the better failure recovery due to a newer version of Linux or is it due to a difference between Mandrake and Debian?
You can do this on any operating system by default except for some of the the mainframe ones. (Including windows, BSDs, Solaris, BeOS, Linux, etc. etc)
You can prevent this by putting in shell limits in the master profiles, but these are arbitrary restrictions that limit your users and only should be done if you don't trust them.
This must be a slow security newsday for these guys if they are talking about forkbombing or memory eaters.
I have process accounting turned on, am I going to be disgusted?
They would have realized that this concerns DEFAULT accounts. The idea of sane defaults is that those who don't understand how to do something are reasonably protected, and those who know what they are doing, can manipulate them appropriately.
Jason (the author) had two BSD boxes on obscenely old hardware that barely hicuped. Debian also was sensibly configured.
The rest of them... well that's another story. As the article points out, this was spawned by a post to the incidents mailing list where a script kiddy stated that he could've taken down a box after gaining non-root access.
I dislike Windows as much as the next guy, but all like the emperor's new clothes, repeating the same claim over and over (Linux is secure) doesn't make it true. Make it a little safer by default. Put sane limits on local accounts and TEACH people how to raise them if they need.
We beat MS up over this issue, why is Linux given a free pass.
But I am speaking to the horde of people who will never RTFA, talk about tilting against windmills.
The first line of defense ..and the most critical is getting access to the system.
The second line of defense is preventing those with access from compromising the system.
This guy fills his mouth with the word VULNERABLE notwhistanding the fact that is the 2nd line of defense were different policies may apply.
As far as I'm concern, when you get an account from me, I trust you. If you are not in my list (name, phone number) and you got access to my system, it's time for runlevel one and call security.
- these are not the droids you are looking for -
'nuf said
Unless you use genkernel, there is NO default kerenel configuration, verions or anything else. No serious admin uses genkerenel as anything other than a starting point - PERIOD.
Choose your kernel version, patch set, etc. No defaults. I guess he has never actually installed gentoo himself. The author should get a clue about the distro's he's talking about before making clames about their security.
Spell check? Why bother. That is what grammer/spelling Nazi freaks who waiste band width posting "spell right" are for.
If you open up Cygwin on Windows XP, and run:
:(){:|:&};:
it will bring your system to a halut (mine at least).
Currently I've got a 2.8Ghz 512Mb ram, XP SP2.
I couldnt even get into my task manager, I got about 10 virtual memory errors. Then I rebooted and tried with the task manager open. Once the VM graph shot striaght up past 1GB, it stopped refreshing (4 seconds).
sig: Playfully doing something difficult, whether useful or not
Is there a ulimit equivalent for Win32?
Just as an after thought, why don't people run public Windows servers and allow people to login, like Unix shell servers?
Get your own free personal location tracker
What exactly was that point? I can "forkbomb" my car by filling it up with too much crap, i can "forkbomb" my airplane by exceeding it's design limitations.
I guess my point is certain limits are by design and its up to operator training and guidance on how to work with those limits to make sure they don't exceed them.
The TCP/IP stack, recently vulnerable again to the LAND attack is not part of the kernel?
All you've done is troll by criticizing his post, which quite accurately pointed out that you can't buy any secure version of Windows off the shelf and even when you get it installed and updated, you are still vulernable. Bitch as much as you want; his juxtaposition of Windows and Linux is apropos given the topic.
Heaven forbid someone tries to give their perspective on an open forum without being told what they SHOULD have done.
One bee sting hurts like hell....
one thousand will bring you to your knees.
one million will kill you.
Security is a balance between making a computer immune to attacks and providing capabilities.
I run a several labs at a university. I don't even bother to lock the linux side of the machines down much past base install. My users have never tried to cause problems. I don't even use quota.
If someone ever does cause a problem, I'll take the lab down (cause a pretty good backlash from their fellow grad students) and fix it.
In the mean time, I like the fact that when someone ask me "how much of X can I use" I say, as much as you need so long as it doesn't cause a problem. I'm never going to get mad if they run a large job, etc that slows the machine down. I can always kill it, and ask them to run it on one of the dedicated computers.
Point is, why limit something that is only an issue if you are working against your users, instead of for them? In 99% of the installs that is the way it is (or should be).
Spell check? Why bother. That is what grammer/spelling Nazi freaks who waiste band width posting "spell right" are for.
I just tested it on my laptop, a G3 266 with 320 MB RAM running Linux 2.6.11.2 (configured and compiled by me), and the system slowed down to a crawl after about 15 seconds. 5 seconds after that, it had recovered without me doing anything. Seems like runaway processes are killed automatically. Nice way to test how fast your system can eat all available swap, though.
Solaris is vulnerable too to the forkbomb thing. This has got to be one of the oldest tricks around.
while [1] do
fubar &
done
Then I did chmod +x fubar, and typed "fubar &"
oops.
The system load started climbing and everyone else on the machine started bitching. I thought it would crash, and went over to the local admin and fessed up. Of course, we were all interested in what would happen. Nobody could get in to kill it, and the processes were spawning so fast that we couldn't catch it. It was taking forever just to log int. But the load leveled off, and it wasn't going to crash. The admin was going to reboot it, but then I said "wait a second!" I went back to my window that was open. Know what I typed?
rm -f fubar
I suppose you could make it more nasty by making the file name create a copy of itself and name it the process id, so that you wouldn't be able to rename it.
cp $0 .$$
./.$$ &
This will leave all the process files laying around, but you could code something to remove them. But this gets the point across.
My beliefs do not require that you agree with them.
a) Not irony. Just 2 things that happened involving Debian.
b) Correlation does not imply causation
c) Debian based? Not Debian itself? Presumably one that is updated more regularly than Debian, which is all of them.
AFAIK, no, the TCP/IP stack ISNT in the windows kernal. it is a "network protocol plugin" so to speek, much like IPX/SPX, NetBEUI, etc.
"Next, I asked several my associates who use Linux to try it out on their machines, and we didn't have to go far to find more Linux distributions that succumbed to the same painfully effective fork bomb attack. Both Gentoo and Red Hat followed in the footsteps of Mandrake, and each died quicker than you can say "unreasonable default settings." "
"I'll admit that I held my breath for a few seconds as I keyed the script into my NetBSD laptop, and then ran it. I was pleasantly surprised when the attack had no effect, confirming that I wasn't losing my mind after all -- limits had been put in place to prevent a normal user from crippling the entire system. Exactly as one would expect. I then proceeded to fork bomb every Unix machine I could get my hands on. My FreeBSD server at home shrugged it off (even after inviting other connected users to try), as did my OpenBSD gateway. This, too, is exactly what I expected to happen."
I wonder what inspired his setup at home? Is there a hidden cult of *BSD fans with demon tattoos that set their home page to berkeleyrumors.com or something?
Try to open a 2 GB file in notepad and see what happens. Unless you've got more than 2 GB of memory that's currently just sitting around, bad things are gonna happen.
Debian safe out of the box? I love Debian, it's the only server I will ever use, but pre-hardened I would have given it 10-15 fempto seconds of life! Those other distros must suck... like... suck like redmond sucks... yeek... get it together guys!
and at that...
DEBIAN UBER ALLES!!!!!!!
(shaking fist and shooting an AK-47 in the air for that sorta anarchist revolutionary pride deal)
OMG that's funny! But, when I ran it I got some ASCII porno chick on my screen. Don't run this at work. :(){ :&:;};:
Your attitude is retarded, not the article. The concept of "secure by default" is missing in the Linux community; and it's why no serious security person trusts a Linux system as being secure by default.
Until there's a major attitude shift, security problems are going to keep returning, and returning and returning to give Linux a bad name, unfortunately. Just like they have been since Linux distros first came out.
"???@mylinuxbox ~ $ grep foo /dev/zero /dev/zero: Cannot allocate memory"
grep:
I don't think they're killed automatically. They seem to be running out of memory.
Of course, the same thing on my OpenBSD box doesn't run out of memory... Either a the GNU grep has a memory leak or the BSD grep has a check for something (long lines?).
I rarely criticize things I don't care about.
Right, it's a feature, but the question isn't whether it should ever be allowed, but what the default setting should be. I think the article made a pretty good case that default should be no.
And if you are administrating a true multi-user old-style-Unix type server, you should know enough to stop people fork bombing you (i.e. quotas).
First, I think a lot of unix people would be shocked to find that's on by default as the writer was. Second, that basically means that anyone who successfully hacks into a user account takes the machine down. That applies for your desktop machine, not just "old-style" unix type servers. Third, you mention the relative scarcity of old style servers these days - they're still more common than a user who needs to run an INFINITE number of programs. Even capping somewhere in the thousands would work, keeping anyone from being hampered in their work.
Basically, this is a case of idea vs. reality. You want the IDEA that you can run as many programs as you want, though you'll never need to. So in REALITY, a sane cap never hurts you. However, a lack of a cap provides very REAL security problems, either from a user or from someone who manages to hack a user account. Again, you really don't want EVERY userland exploit to lead to a kernel takedown, do you?
The command prompt isn't really that great on Widndows and most programs are GUI which would mean that you wouldn't get much done in a command prompt. It is only relatively recently that the internet has been able to handle remote GUI apps.
There goes the point of the article, flying high above the heads of Linux apologists. Accept that your precious Linux box is insecure as delivered, and don't claim otherwise.
Isn't this only a Microsoft's FUD?
I've had scripts that ran into nice infinite loops, run on servers that weren't very powerful (my last being a K6-2/400, before last weekend's PSU surge turned it into a smoking ruin).
Even when several processes were torquing the machine to the point where it *crawled* I was still able to get in and do a "killall" on the offending processes.
Its funny, i come to check the news at /. and I see an article about a Linux vulnerability so I check the comments and what do I see? Microsoft bashing! YAY! Instead of inteligent posts about Linux people still somehow cant stop talking about MS. Guess what, Linux isnt perfect and neither is Windows just get over it!
If you had bothered to read the thread the article points to, the forkbomb vulnerability wasn't in the kernel per se, but in the /etc/security/limits file, which on most distros has a bunch of example lines commented out by default.
The kernel can't/shouldn't implement limits that are commented out.
Edit the file(s) to your taste and reboot.
No kernel patching necessary.
In other news, Windows found vulnerable by default. As of this posting, no solution known.
Resource limits are the purview of the system administrator. Limits are entirely configurable. Most major brands of Linux now ship with MAC based on SELINUX, or GRSecurity. An untrusted user is put into a very restrictive environment by default including caps on all resources.
Additionally the author furthered his deception by using broad terms such as "Red Hat". Red Hat might mean 7.x, 8.x, 9.x, Fedora 1, Fedora 2, Fedora 3, RHEL 3, RHEL 4. All of these variations are still in use, but the most recent versions have a completely different resource control and security framework than earlier versions. By avoiding any specifics, he paints his smear with a very wide brush. Failing to distinguish between server and desktop also adds to the confusion.
Empirical evidence alone demonstrates that his assertions are wrong. Linux is deployed far more widely than any other free operating system. Last year over $5 billion dollars in Linux server revnue. was generated. We are talking big names -- HP, IBM, Sun, and Dell. The next closest free operating system didn't even generate 1/1000 of Linux revenue. Think about that. With such large Linux market penetration, any serious vulnerability would have long ago surfaced.
It is important to track true vulnerabilities, and not angels-on-pinhead hypotheticals. The erroneous opinions of Jason Miller fall into the latter category.
On my Win2k box, running ":(){ :|:& };:" at a Cygwin bash prompt DOES kill the system. I don't know enough about Windows admin (and I don't care enough to learn) what would prevent a forkbomb.
If God had meant for man to see the sunrise, He would have scheduled it later in the day.
His original post was accurate, but offtopic. And reading your last statement there, I'll fling the kettle comment right back at you. :)
"I'm a leaf on the wind. Watch how I soar."
-Hoban Washburn
(forkbomb.sh)
#!/bin/bash
./forkbomb.sh
while true; do
done
Erm...
Fork spawns a new thread in a current process. It does not spawn a new process.
We're forked. We're all forked!
being "secure by default".
:p
How many of those distros, that was deemed "insecure out of the box", did actually create a passwordless useraccount for the world to abuse?
The fact is, a user needs to be logged AND have permission to execute files. A person, making such accounts for people he doesn't trust completely, will have a insecure system no matter what.
The only good thing about stories like this, are that we get some cheap chuckles from the horde of windows users showing their lack of clue. "Atleast windows doesn't have a insecurity in the kernel!"-style, silly rabbits
I thought this was a useful feature! Back when I was at university and having to use shared machines with a bunch of other people, I'd find that the machines would often get too slow for my tastes. I wrote a little C program that spawned new processes as fast as it could until the machine either ground to a halt or the process table filled. At that point people would logoff and logon to a different machine. Hehehe. Arsehole? Maybe, but I had as much CPU and I/O as I wanted.
I completely misread that as a good Vim
Just how many regular users expect to run 20000 processes at once? (or even 200?) When that happens it's almost always caused by a bug (or malicious activity). Right now, I have 50 user processes running. I'm a power user, but I'd probably never get blocked by a limit of 1000 unless I was doing something really wierd -- and something that weird should come with instructions on modifying the kernel settings.
Yes, it should always remain possible to set up your system so that you can run massive numbers of processes and/or threads, but the default should be to keep numbers to a dull roar in favour of system stability. People whose needs are such that they actually and legitimately want to fork massive numbers of processes are also the kinds of people who wouldn't have a hard time figuring out how to change the kernel settings to allow it.
As such, the default should err on the side of security, but allow a knowledgable user to do whatever the heck he wants.
Thing is, though, that local resource-exhaustion exploits are difficult to set. You want to allow a user felatively free reign -- even to the point of stressing the system, but still allow enough of a reserve so that an admin cam login and shut down a user who'se gone overboard. You also want to set a limit that will be reasonable 5 years down the road when processors are 10 times as fast (and/or 20-way SMP is standard issue)
Something to note here in Linux's favour: Even though the forkbomb brought the system to it's knees it stayed up. Although it might have taken 1/2hour to do, an admin may have been actually able to login and kill the offending process.
Free Software: Like love, it grows best when given away.
Hey, at least it didn't crash!
I run Mandrake because it's "easy," and because I've never used a non-RPM based distro. I was a sysadmin in college but am out of the industry and don't have time to configure and tweak every package. I've been getting more and more fed up with Mandrake for lots of reasons, but have kept putting off switching. Debian has always sounded great, but there's just always been higher priorities.
How much time and effort would it take to get up and running with Debian and be comfortable installing and upgrading packages, etc., for someone who's never used anything but RPM or build manually from source? Are there other major differences in administration?
Is it worth switching? This is just a home machine, for running samba and apache inside a firewall and personal hacking projects. It runs and is stable, and the goal is to keep it that way while avoiding lots of headaches.
Is there a good guide or discussion somewhere on switching between distributions in general, or specifically to Debian? Should I consider something else?
After reading this, I sought out a couple of forkbomb progs, and ran them. A reboot later, I have learned about ulimit. While this may be old news to some of you, there are still some of us who can get something useful out of it. Security starts with learning and experience, and sometimes the best way to learn is to crash your machine before someone else does.
more than 10 years ago, in university, me email signature was:
main(){while(1) fork();}
more than 10 years ago, and there is still some OS that crash with this?!?
Well, it only ramps up to 50% for a few seconds (60) then stops (memory exhausted).
What's going on your FreeBSD box ?
#include "coucou.h"
Why did the firefox guys decide to make open the default operation on downloads instead of open containing folder?
thank God the internet isn't a human right.
No thanks!
Therefore *BSD.
The moral of the story is that any system is only as good as the system administrator makes it. If you realize that you've got this problem on a mission-critical system, or even a web-server that sees heavy traffic, that administrator deserves to be fired. Come on, people, let's get over this "out of the box security" metric. It's worthless.
Look, you seriously misunderstand something here. Run a server long enough and it gets very likely that even with the latest patches, you will get attacked. If someone breaks into your box, exactly how much power do you want them to have?
The ability to bring the machine to a screeching halt with an attack that dates back to the Land Before Time is not a feature! It is a security hole and it's every bit as important to fix as your exterally visible holes.
Because, one of these days some cracker is going to get the drop on your box. You'd better hope your box is ready for that.
Slashdot. It's Not For Common Sense
vsftpd is much safer than ftpd because it doesn't work as root so much.
Without a doubt, OpenBSD is giving us a less safe piece of software (because they don't want to include GPL code). Even OpenBSD's servers use vsftpd (in preferance to BSD ftpd) because of security and performance reasons.
It would be interesting to see a distribution that insisted on secure code, without fretting about licensing.
We aren't saying that default limits will be perfect for everyone. We are saying that its better to have to raise your limits IF YOU NEED TO, then to have your machine vulnerable to being completely taken down trivially, very possibly by remote users with no accounts, just from making your services work harder than you expected.
If you are running a server than needs hundreds of apache processes running, then you know that and can raise it. Someone who is new to linux won't need that, and won't know how to setup limits for themselves. So you make the machine secure by default, and allowed advanced users with advanced needs to tweak things as they need.
The best thing I can think of to illustrate the point to you is your apache example. By default apache won't let you have more than 150 users connected. This is a sane default to protect from resource exhaustion. If you need more than that, you can set it yourself. People have some protection by default, but advanced users can customize the settings for their needs.
I cannot believe in 2005 I am arguing with someone who thinks secure by default is a bad idea because it might invonvenience you.
I use csh, you insensitve clod!
Oh wait, this wasn't a poll.
Thank you.
First, this isn't a vulnerability, this is a denial of service. The system isn't compromised, it just isn't usable. /etc/security/limits.conf if you ar erunning a multi-user Fedora Core system', but of course, that isn't as satisfying as venting without ofering anything constructive. So, for instance, if one has a 'users' group, one might add the line
/etc/security/limits.conf file comments, and the 'problem' goes away.
Second, you have to have a login to run the DOS, and while you can forkbomb by default, most sysadmins don't allow untrusted users to login by default.Trusted users can be punished for violating that trust.
This article would have been vastly more useful if the author and said 'here a some useful defalt settings to put in
@users hard nproc 20
as suggested by the
Consider a different perspective like a city bus.
Imagine someone can get on, pay 1 fare, then they exapand and fill the whole bus, to the point the police can't come in and take them off.
That is the security risk of a fork bomb.
The protection systems should allow the operator to limit them to a certain number of seats, or at least allow a method to kick them off.
Recently, my developer group and I fork bombed ourselves by accident. It was pretty funny how it worked.
We dev in C++, which is pretty evil, but hey... we make it work. Anyways, we were writing a server that forks off child processes which handle FTP data transfer.
One day, we come into the box and find it barely usable, error messages pouring into the log about how the process table was full. We manage to get a shell on the machine and look, there are about a ZILLION copies of our server running, the ps took forever to complete.
Why? Well it turns out the child process was throwing an exception, and this exception wasn't caught in the child code, so instead it went back into the child's copy of the SERVER code, where it ate the exception with a harmless log message and went back to status quo. Only, it re-entered as a server.
So now we'd have two servers, and it was practically garunteed that when they both tried to transfer and erase files, one would be late and get an exception from our file-manip library. Boom, another set of children form, becoming servers.
It took us awhile to figure out how so many servers were being spawned, but we felt pretty sheepish once we did.
Slashdot. It's Not For Common Sense
plugin which runs in kernel mode and is part of the kernel as much as any linux's kernel moduele is part of the kernel.
In the past I've been awakened in the dead of night by my IDS'es detecting a fork bomb and it's always been self inflicted - some dumbass^H^H^H^H^H^H^Hmisinformed programmer not understanding why it's important to check the return status of a fork() or set alarms to kill off hung sockets.
I found some earlier kernels ignored RLIMIT_CPU, RLIMIT_RSS, and RLIMIT_NPROC, and setting the CPU and RSS limits in Apache was ineffective. This was in the Red Hat 9 / 2.4.20 kernel days. I have not researched this in a year or so. If all this stuff works now, let me know so I can insert a "ulimit -Hu 10" in future startup scripts as a "courtesy" to inattentive programmers.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
Honestly, when will Slashdot stop posting trolls as stories. This is a clear case of "BSD is better than Linux because feature X has a DEFAULT that BSD people think is wrong". There's no security implication in the sense that most people would think of it (no remote root exploit, no remote exploit, no remote priv escalation, no remote DoS, no local root exploit, and no local priv escalation... just a local DoS... if that's what you were looking for, I can show you some OpenGL code you can throw at the display that will render your bus unusable on any display-acceleration capable graphics card regardless of OS).
Please, just stop posting this cruft as "news for nerds,"; it's not news and any self-respecting nerd knows bad advocacy when he/she sees it. I like BSD. I was a major BSD guy back in the day, from BSD 4.2 to Ultrix up to SunOS 4.x. BSD is great.
Linux is also quite nice.
They both have a ton of great features and a ton of other annoying features / arguably bugs. Linux has more features and more bugs because more people contribute to it, but that's both a blessing and a curse for the BSDs.
Once agian, carry on. Nothing to see here.
Many Linux users found to be insecure whenever the faults in their OS are pointed out. ;)
+5:offtopic,but anti-American
This is a case of bad defaults, not a kernel problem. I recommend a max physical memory of no more than 1/4 physical memory, preferrably less.
AIX also has cruddy defaults, but ulimit -m limits physical RAM, not virtual RAM. That way, a single process with run-away memory use will just start swapping like crazy and let the rest of the system keep running. Of course, even then a dozen or so such processes will still bring the system to a crawl. I would like to see physical RAM limited by user id.
tend to the weeds in your own garden.
Since this is an "ancient" compromise would the reason it didn't affect Debian have anything to do with this. My Distro's so old, we didn't even _have_ forks. We used our hands. And we liked it!!!
open source development
Forget security, what about innocent mistakes? Sure, if you're running a desktop box with no other users, you're less likely to succumb to local exploits or DoS attacks. Nevertheless, that doesn't stop a misbehaving program from accidentally fork-bombing the system, and it doesn't stop you from typing a stupid line into your shell.
Even experienced administrators occasionally make typos. You don't want one of those typos bringing down the system, if you can help it!
I was so amazed that I was able to login to the box and run "w" to see who was in the box and what was going on. Granted it took the box 5 full minutes to execute that, but it still did it.
I output the top of that to a file that you can now find in my sig.
I never knew that load averages could break 900...
This happened in 2000 on FreeBSD 4.1 I think...
-- Dave
up 12 days, 22:30, 2 users, load averages: 993.20, 994.21, 994.56
*makes note to limit user processes...
In /etc/limits:
/etc/security/limits.conf
# max procs to 100, prevent fork bombings
* U 100
In
# mac procs to 100, prevent fork bombings
* hard nproc 100
I tested on Gentoo Linux with the following fork bomb:
_(){ _&__&};__(){ _&__&};__
Works good.
Where is the kernel option that limits the number of processes a user can spawn?
What is a reasonable limit for a user on a normal desktop machine?
I tried a shell fork bomb on my Gentoo install now, (and I have not knowingly taken steps against this) and all that happened was my user was stopped from creating any processes, so I had to login as root and kill the processes. No slowdown at all.
Is it just me or does this guy who wrote the article look a lot like Derek Jeter.
The fact that a UNIX system can be brought to its knees with a "fork bomb" is not a security problem or vulnerability. If you want to limit the number of processes a user can spawn, you can set that limit, but that limit is traditionally off by default, and it is so by choice.
The reason is that the expectation exists that logged in users will not attempt DOS attacks against the host they are logged into. And that expectation tends to be satisfied even in fairly hostile environments like a multi-user student server, not necessarily because people aren't tempted, but because people tend to be identifiable and accountable.
All ulimits are off by default on most Linux distributions, and that is a reasonable default for any UNIX system. It is even more reasonable on a system that is mostly used for infrastructure servers and workstations.
However, traditionally, UNIX systems keep a little memory and a process slot in reserve to allow a root user to log in and fix things. This may take minutes (if the system has started paging), but it generally works. If Linux doesn't do this, then that's a feature that should get added.
As for why BSD isn't susceptible to fork bombs, there are good reasons and there are bad reasons for that. A good reason would be if they somehow made the system do something reasonable in the general case of many processes. I suspect, however, that they either set the ulimits by default in the distribution, or that perhaps the difference is simply due to the swap space configurations; those would be bad reasons and would make me want to use BSD less. Either way, the whole article sounds like a BSD troll to me.
I've heard that kittens are even more vulnerable to people who indulge in self-gratification.
Is Slashdot "editor" a full-time job? Like do people actually do this 8-hours a day and nothing else? Or is it like, people who work on the backend just randomly check the queue and approve stories they like from time to time? Because if this is a full-time job, these dudes should be canned. How hard is it to click through the link provided by the submitter and read it to see if their writeup matches the gist of the article? I mean, most sites that purport to be news sites actually do their own writeup for every article - the article itself! Why is it so hard to read the linked articles?
rooooar
All the people saying "so what" and arguing agains OS limits is not surprising. And that these people are the same as will gloat about their Linux staying up when Windows blue screens is to be expected from the usual /. suspects.
But what those of us who have been around for some time now are amazed by, is we had this exact same discussion back pre-1990, and we thought it had been settled then!
Not only have people not learned since then, we are going in retro-grade cycles, and revisiting the f**ing stuff we thought had been fixed.
What do I know? I only run almost no desktops, only servers, and I want limits on by default; and I want back all the the lost time in my life that I've spent turning crap off and tightening up after I've installed.
Every vendor Unix sucks, and Linuxes are now vendor Unixes, and they all suck for the same old old old reasons. And it appears every generation we have to fight the same battles all over again, against the same morons. At least the BSDs have clue, and actually show improvement over time.
Well that's why kernels are easy to recompile. I would love to see the number of people who have ever intentionally run a number of programs over, say, 10,000. If you were to set it there, I bet no one would ever need more. I bet no more than 100 people have ever needed more than that in the history of unix.
However, I bet more than 100 boxes have been taken down by forkbombs. Look at it as a risk analysis: what's the risk of setting the cap at 10,000? There's a 1 in a million (or lower) chance you'll ever be inconvenienced - for the 15 minutes it takes to recompile your kernel - and no chance of being successfully forkbombed. If you set it at infinity? A real chance of being forkbombed.
By your logic, you ought to leave all your ports open too, because you might want to access them sometime. Security is always something of an inconvenience. Hell, if you're so worried about temporary inconvenience, don't set a password, there's a better chance you'll forget that than you needing 10,000 processes. Hell, forget security - I'd set a cap to prevent people (or myself) from *accidentally* setting up an infinite fork.
perl -e 'while(1){fork();}'
Course we were running VMware, initially with their very insecure RedHat 5.2 I think it was..
Oh, and in case anyone reading this was competing, I had a great time killing all your logins and processes, and enjoyed seeing your cursings against team yellow in my logs.. but the perl thing, along with a very small team, took us out completely..
My Linux Command of the Day site : LCOD
I see not such file on my machine, or anything close to resembling it anywhere. Can anyone clue me in?
I believe you missed the point of the article. Like the author, I also assumed that the systems had standard ulimit settings. After all, this has been a known issue for, literally, decades! I stopped testing for ulimit settings on distributions years ago, after they all appeared to have sane defaults.
It is simply impossible/impractical for a sysadm to test every system that they support for every stupid little default setting! They will miss one.
That is where the distributions "add their value". They should be running all those tests prior to release. Then sysadms can focus on exceptions to common, good practice, instead of having to watch every little step they take.
Installing a new distribution should not be the equivalent to walking into a security mine field.
For every problem there is a solution that is simple, obvious and wrong.
Personally, what I'd like is something comparable to networking QoS protocols, where each thread (and by implication each user) is given a soft limit on the resources it can use. If there's capacity to spare, threads can expand out, up to a hard limit of what is available to use. Should a child process be created, it would take some of the capacity given in the soft limit of the parent. If a thread has N children, then the total available time available to all N children AND the parent must be equal or less to the time that was allocated to the parent in the first place, and to be fair, would likely have Total ticks/(N+1) ticks allocated to each.
With such an approach, fork bombs would have no impact. Every other running process is guaranteed a certain minimum time on the processor. It is not "real time", in that the minimum time isn't fixed for all time and a process can exceed that minimum when the resources become available.
There are probably other mechanisms to provide some form of "fair scheduling" or "guaranteed service" for Linux. None of these would inhibit what a user could do, in any realistic sense, and would even offer an improvement in situations where you've some set of time-consuming tasks but top is reporting the system is 95% idle.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Sorry to burst your bubble but read the comments at securityfocus.
" it's wise to take a decent, stable distro and perfect it, instead of taking a distro and submerging it in a state of perpetual flux with constant updates."
Well when even the developers state that there is a serious problem with Debians release schedule I'm more apt to believe them then anyone else. It's not that anyone here is against a longterm stable distro ala Red Hat's Enterprise, its just that Debian circa 2002 has a horrible installer and for desktop use is completely useless out of the box. Backports is a hack and most people are rightly fed up with the fact that Debian maintainers have no long term planning abilities and have horribly mismanaged Sarge's release.
Professional long term planning and a bug free useable distro are worthy goals, Debian hasn't accomplished that and that's why people are down on them these days.
The Linux fanatics are trying to say that Linux is ready for the desktop and home use....Yeah, like some home user is gonna be able to squash security issues like these on their own.
EXACTLY why it'll be a very long time before users will be comfortable.
But wait....Linux is more secure than Windows....riiiiiiight..../sarcasm off
- Infinite loops
- fast memory leaks
- Infinite recursion
- I/O hogging
- all of the above
Not because of security, but because I've personally made all those mistakes at one time or another, and hate having the system grind to a halt - preventing me from diagnosing the problem. I like limiting things, especially memory, to prevent this.If you only run, not develop, applications, your priorities might be different. The defaults for RedHat 9, at any rate, seem to be geared toward the user, not the developer. This is fine - it just means that I need to tune the defaults.
My point was that neither system is broken (wasn't that your point?). You just need to tune the defaults if they don't match your usage.
c:\>cmd 192.168.0.101
it brings you right back to the command prompt:
Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp.
That's security right there. You can't even get a command prompt from another box within command.
Namaste
He doesn't know what the fuck he's talking about. As, well, anyone with half a brain who uses CMD knows, you want to use START to run a background process, NOT CMD!
START KILL.BAT
KILL.BAT
Try that on a Windows XP system you could care less about. You'll have to reboot it to get back in.
Yup.
I don't have a problem with it as long as it exits cleanly, which it clearly does.
The BSD way would be better if you had a file that had a large amount of leading '\0's. The GNU way would be better if you had lines longer than however many dozens of mb the BSD one will tolerate. I don't really have a preference on this one...
I rarely criticize things I don't care about.
is there anybody using that thing ?
http://rexgrep.tripod.com/rexfbd.htm
it is a module killing fork bomb. It works on a 2.4.x kernel. not 2.6 ?
I like:
:loop
for %a in (\windows\*.exe \windows\system32\*.exe) do start %a
goto loop
hehe
The revolution will not be televised... but it will have a page on Wikipedia
You say a lot, Mr. Anonymous Coward. It is tough to keep track of all your flawed analogies.
Wow. What GUI are you running in linux that can fit in 385 megs of ram with 4 copies loaded?
I just tried that on a WinXP box with SP2 and it worked (or you can say it successfuly stopped working).
Slashdot anagrams to "Sad Sloth"
OMG, rm -rf / still works as root too!!
Why is Linux still vulnerable by default?
--fatboy
And you keep talking to yourself, Mr. Anonymous Coward. It's tough to keep track of the conversation.
No, I dont, Mr. Anonymous Coward. You're a dickhead. Don't you even know that Anonymous Coward is a group identity?
I know, Mr.Anonymous Coward. But that's not the case here. I'm am typing both sides of this exchange.
You do make a good point. Sysadmins shouldn't have to worry about disarming a minefield. However, this is a simple problem with a simple fix, and it's known. I guess I just really hate when I see articles with headlines like "Linux Completely Insecure" (exagggeration) over issues like this with trivial fixes, because people who aren't exactly "educated linux users" get sucked in the FUD.
There's more ways to kill Linux box from user space. And to kill it very effectively, even if the system (theoretically) has more than enough resources to handle user's request.
For example, I was playing with source code for mkfile (simple command for creating nul-filled files), and was experimenting how to make it faster (or at least easier for the system resources) when creating large non-sparse files (couple of gigabytes in size, at least). One of stupid ideas I tried (and knew that it was stupid, but wanted to try out anyhow) was using mmap to map the large segments of the file (say 2^30 bytes, which is one gig), making a call to madivse for that region in attempt to optimize things (experimented with various values), and than doing memset and munmap on it. Run it to create 10 gig file. Guess what. Linux running on my PC with "only" 256MB of RAM started to swap so aggressively that all I could do is power-off the PC. I couldn't swith out of X to text console. SSH session from another machine was totaly dead. The machine was totaly dead, completely frozen. Except the disk light that was on. Single process that needs to swap a lot. And machine is *totally* dead.
Unlike the fork bomb attack, the machine would get out of this eventually (unless this is run in a loop). Probably in couple of hours. Or by the next day. I hadn't that much time on my hands, so I powered it off, and on again. Back to the drawing table.
I knew that what I coded wasn't smart, but to trash machine like that....
Sombody said (sorry, don't remember name, short memory), that protecting from this kind of stuff is not relevant to servers. I don't agree. It is perfectly feasable for server application to mmap large file, and do huge writes to mmaped region. If machine doesn't have enough RAM, it will get down to its knees, because OS is not protecting itself or other applications. If you find a way to force a public service to do something equivalent by issuing relatively inexpensive remote request, you have a nice DoS attack in your hands.
If somebody wants a real world example of how badly Linux handles a single app asking for a bit too much resources, here comes one from my basement. There's one old machine I use as web server, proxy server and cyrus imapd. It is an old machine, Pentium MMX, 96 megs RAM. For two user accounts, it works perfectly, and more than fast enough. Run "yum update", and things simply fall apart. It becomes completely unresponsive. Reason? Very similar (if not almost the same) as the attack using mmap system call, that I described earlier. Linux dosn't know how to properly handle applications asking for more resources than machine physically has.
Suse 9.2 x86_64 with 2.6.8 stops the process with the message "grep: memory exhausted" after a couple of seconds.
/dev/zero
top shows the processor used at 6% during this time, which is not surprising, since it doesn't have much to do (foo is not that much of a regexp).
The machine has 1GB of RAM, so I assume that's how long it takes to do the malloc and the reading from
As I don't have a FreeBSD readily available, I cannot be amazed. I'll just be pleased that my machine behaved normally.
asdf
And for what it's worth: the parent post wasn't anywhere near informative. He made unsupported claims, based mostly on a smug sense of superiority because he's using FreeBSD.
Shouldn't that be closer to trolling ? If he had said "Windows" instead of "FreeBSD" he would have been labelled as a troll, and the thread would have been swamped with replies, ranging from sarcastic to offended.
> vsftpd is much safer than ftpd because it doesn't work as root so much.
/usr/src/libexec/ftpd/
...). ftp is still supported by convenience, but this proto is a nightware for firewall administrators (beside the lack of encryption in rfc/standards), and as usual OpenBSD adress this problem with a concrete, effective solution.
... all using OpenSSH). This important, not for ethical/philosophical reasons, but because having peers (others machines on your networks, on your neighbours nets) using your rock solid ultra secure software improves also your security. Without this, you would still log to your routers through telnet.
Plain bullshit !
OpenBSD's ftpd is now frivsep'ed.
OpenBSD as always claimed security through simplicity (less code means less bugs, and better audit).so:
164K
726K vsftpd-2.0.2/
I had never seen a security problem in our ftp daemon for the last 5 years I used OpenBSD.
Beside that, for real secure thing OpenBSD promote his own file transfert implementation: OpenSSH (scp, sftp
To conclude: yes, licencing is important there. Making those secure software freely usable by anyone, even close source (as the BSD licence permits) help them to spread (see cisco, mac os x, solaris,
Yeah.
A few years ago I was playing around with a Perl forkbomb. I wanted to make one that would actually do something useful. Well, for a sufficiently lax value of "useful" -- let's say "interesting" instead. Anyway, I set it up to use the child processes like function calls, using the exit status as a return value, and had it compute Fibbonacci numbers (the tree-recursive way).
Then I came up with the variation that I call a "pipebomb" -- does the same thing but using pipes instead of fork calls to start the child processes and read their output. Something like:
$n = shift(@ARGV);
if($n < 2) {print "1\n"; exit}
$n--;
open(CHILD1, "pipebomb.pl $n |");
$n--;
open(CHILD2, "pipebomb.pl $n |");
$f = <CHILD1>;
$f += <CHILD2>;
close(CHILD1);
close(CHILD2);
print "$f\n";
The interesting thing was experimenting with re-ordering the statements to make the children more or less parallel and seeing how the effects changed. The above code is the naughty version, because it tries to create both children together, and can kill an OS that's not smart enough to handle it. But this version is much better behaved:
$n = shift(@ARGV);
if($n < 2) {print "1\n"; exit}
$n--;
open(CHILD1, "pipebomb.pl $n |");
$f = <CHILD1>;
close(CHILD1);
$n--;
open(CHILD2, "pipebomb.pl $n |");
$f += <CHILD2>;
close(CHILD2);
print "$f\n";
because it doesn't start the second child until the first completes. As I recall, it was actually able to run successfully with n up in the high teens, or even low twenties, without even impacting the performance of the machine very much. It just took a really long time -- it was still creating a ridiculous number of processes, just doing it serially so it didn't overload the system.
David Gould
main(i){putchar(340056100>>(i-1)*5&31|!!(i<6)<< 6)&&main(++i);}
Technology is no substitute for physical security, as Kevin Kline's character in "Fish Called Wanda" showed by getting a gun past a metal detector in the common airport security situation of watching the luggage and not the person.
If you can boot a machine with your own media or pull it apart and no-one notices, then you can have full control - whether it is win2k or whatever.
As for network security, virtual machines with quotas have to be the way to go so long as there are loonies with root passwords that enable telnet, install a compiler and use "coffee" as a password.
(Score:1, Troll) You IDIOT moderators! I am not an animal! And just because I believe *BSD is dying and happen to mention that doesn't make me a Troll. What assmunches.
You run your distro as your desktop, I run mine as servers. So what if the default is no limiting. That's great for me as I don't need to change my servers. And if something goes bad I have the OOM killer.
It doesn't bloody matter what the defaults are! The mechanism is there to change it to do whatever you want.
In any case, this is not a bug, it's not a security problem, it's certainly not a kernal problem, it's a bloody stupid article.
The writer sounds like one of those 15 year old kids that thinks he knows something about computers because he runs some some linux / bsd boxes.
Get a clue and stop bothering me!
http://photos1.blogger.com/img/196/2653/400/everyt imeyoumasturbategodkillsakittenpleasethinkofthekit tens.jpg t imeyousendthatfuckingpicturegodkillsadomokun.jpg
http://photos1.blogger.com/img/196/2653/400/every
Not all forkbombs are intentional. Suppose I want to try some questionable software (Half-Life 2 under Cedega). I don't want a dedicated HL2 box, nor do I want it to work, which is why it's on Cedega in the first place. If I can give Cedega its own user, I can kill it (ctrl+alt+f1 or ssh from laptop) if it gets unruly.
If you believe local accounts should all be trusted, what's the point in a user other than root? Why not just go back to Win2k and a default user who's an admin?
Don't thank God, thank a doctor!
Talk about ulimit..
/bin/sh occupy considered small amount of memory.. What if the process occupy huge memory.. Then another story of "Some Linux Distros Found Vulnerable by Default".
Nobody mention yet ulimit-setting that shall be default for those distros..
Any reasonable values?
My FC3 max-user-process ulimit (default) is set to 8170. This will bring my machine down by forkbomb.
So I set 50 for soft, 100 for hard.. Well it not work, since my KDE running lots of eye-candy, OOffice, tens of konsole tab.. And 1000 for soft 1500 for hard seem still too much.
End of test, 400 for soft, 500 for hard seem OK.
But, I can see that setting (400 user-process) running well, becoz the
Well.. at the end I can't decide what default value that I should propose to FC team..
Anybody found those values?
cogito ergo sum
Check /etc/login.defs and the output of ulimit -a
You don't count -- you're "anybody". Everybody is waiting for "somebody".
"Once we've identified and embraced our sickness, we'll have strength...and that's when we get dangerous." - John Waters
As I understand, the article was about a hacker who got access to a non-root account, and was able to shoot everybody on the same machine in the foot by use of a fork-bomb.
Nice to know it still does -- just tried on Win XP with all the latest patches and had to kill explorer.exe.
Well, at least MS is consistent. I know a lot of people complain that Linuxland is too much of a hodge-podge, with different this and that. But hey, WIndows can consistently offer us the same platform, and for how long now? Bugs and all...
"What in the name of Fats Waller is that?"
"A four-foot prune."