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!
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 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.
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:
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.
Let's see how long it will take before someone says the study is invalid...
The study is invalid!!!
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.
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.
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
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.
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 ":(){
... where gentoo had a default kernel
(can we PLEASE not bring genkernel into this? it sucks.)
Karma: Negative (Mostly affected by dorm trolling)
The difference being that a default install of *anything*, except possibly OpenBSD, should be in a situation where there might be users on it that you don't trust completely. For my personal use of linux, all I need is a box that is secure from hackers, not users.
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 -
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?
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.
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.
"???@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?
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.
If you're administering a server with multiple users that are potentially malicious (or at least pranksters), then this is a real issue. If you use Linux on your desktop, then it's mostly theoretical - at worst, it could be an extra puzzle piece that allows another exploit to have a bigger effect.
quidquid latine dictum sit altum videtur.
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.
You'll get OMM killed faster, than you can read the line "welcome to linux".
(forkbomb.sh)
#!/bin/bash
./forkbomb.sh
while true; do
done
And the answer is:
5 minutes.
... whenever a text is transmitted, variation occurs. This is because human beings are careless, fallible, and occasiona
No, on Unix fork() creates a new process that, usually temporarily, shares a (usually copy-on-write) memory space, file descriptors and other things with it's parent. Threads are created via the pthread_create() call (or thr_create() on Solaris).
Now underneath, some popular OSes implement threads as full processes which happen to share a page table and system resources with their parent process, but you still don't create them with fork().
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.
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.
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.
open source development
It's a shame I don't have a couple of hundred processors in my desktop PC, else I would have folded the fuck out of some proteins :)
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
That's what job limits are for. Shameless plug: get jobprc, a GPL'd command-line job creator (written by me) here.
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
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.
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
OMG, rm -rf / still works as root too!!
Why is Linux still vulnerable by default?
--fatboy
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.
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.