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."
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.
That is no reason why the same should be true of Linux. Or any other OS for that matter.
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?
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
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
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.
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.
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
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.
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...
"It was a report on how a fork bomb can take down default Linux installs,"
Yes, and? I don't care about fork bombs, since I don't run them on my PC... being able to run as many processes as I choose on that PC is a feature, not a flaw. I do care about having scumware remotely installed on my PC through security holes in applications and the operating system, which is a flaw, not a feature.
Seriously, if you're letting people log onto your PC and run fork bombs, you have far greater problems than a lack of resource limits in the default install.
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.
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.
The biggest security problems come from the inside. Other employees can't be trusted just because they work for the same company.
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?
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.
*Any* local exploit is *also* a potential remote exploit (just like the IRC conversation shows). I had someone nearly pwn a box of mine by using an exploit in a buggy PHP script, then trying to elevate privileges through a local exploit.
Had I not considered local exploits important, I'd have had one nicely hacked box.
Oolite: Elite-like game. For Mac, Linux and Windows
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?
You'll get OMM killed faster, than you can read the line "welcome to linux".
Two things: 1. Just because you don't care doesn't mean other people won't care. A lot of people (especially in a business environment) do have more than one person logging. 2. The article is trying to point out something that Linux installs could improve on. That is all.
"No one likes working in a hamster wheel, and your shop smells of cedar shavings from here." - TaleSpinner
What about a poorly written program run by you with an unintentional bug that ends up causing this? What about a remote exploit which allows abitrary code execution? Do you inspect every line of code in programs that you use to make sure this isn't going to happen?
User land programs should not be able to bing an entire system to it's knees. Come on, when I first started with Linux, Slashdotters made fun of Win98 because a single program could crush the machine.
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.
A fork bomb doesn't necessarily have to be due to a purposeful attack. A software bug can easily cause a fork bomb by going into an endless loop launching new processes. Should this take your system completely down?
Admittedly, you probably shouldn't bee seeing such a serious bug in any release software. But what if you're a developer, and have code that is forking in a loop which, due to logic problems, never exits? Should you be forced to reboot your system?
I can think of a lot of such instances where a runaway process might start forking -- and personally, I'd prefer to be able to kill the process instead of being forced to reboot. I doubt if I'm ever going to purposefully spawn 5000 simultaneous processes. I think you'd have a valid complaint if the OS was limiting you to 50 processes, but there is a realistic upper limit of the number of processes a given hardware configuration is going to be able to reliably handle -- why shouldn't the kernel prevent the system from surpassing such a limit? Do you really want to be able to open enough processes to kill your system so badly the only way out is a reboot?
Yaz.
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
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.
OpenBSD does not install wu-ftpd. Instead, they have their own ftpd, called ftpd-BSD (which has been ported to Linux as well, look it up on rpmfind or something). It is wu-ftpd that has a reputation of being buggy.
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.
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.
With Windows XP Starter Edition, trojans run you!
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.
Except this isn't a fault. "Safety researchers discovered that cars today can exceed the speed limit of 65 MPH. This is a serious breach of safety protocols that can potentially cause serious bodily injury and possibly death."
I mean, really, "Linux lets me shoot myself in the foot". Good to know. DON'T SHOOT YOURSELF IN THE FOOT.
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
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.