Stop Microsoft
Operating Systems => Linux and UNIX => Topic started by: Bazoukas on 22 March 2005, 22:59
-
http://www.securityfocus.com/columnists/308?ref=rssdebia
The cracker and the attacked IRC chat
http://www.securityfocus.com/archive/75/393292
-
Vulnerability to forkbombs isn't the only stupid weakness of linux, although it's a damn obvious one. Further, on some systems where forkbomb doesn't do damage, forkmallocbomb still will.
-
this cropped up a good while ago on void main's forums, the solution is to use ulimit to prevent it:
http://voidmain.is-a-geek.net/forums/viewtopic.php?t=447
some vendors of course do not have this set by default at a sensible value
-
the second comment on the above article is this, i have broken it up to actually mention my thoughts on it:
Yes, you can use ulimit. By why should the sysadmin have to bother to do more work to lock a box down?
what else is the system admin doing? this is the admin's job. After an install the box should be "secure".
who says? that'd be ideal, but if it's your system, it's also your responsibility to ensure its security. It shouldn't be necessary to do things to make it secure: that's what Microsoft did in the past and look where it got them.
this makes no sense.
This is about sane defaults. The Debian team got it right in this case; most other distributions did not.
fair comment, and this is true, but you cannot rely on the vendor to solve your problems for you.
-
This is easy to fix: ulimit -u 100
That's what mine is now. The Slackware default was 4095.
Add this to /etc/profile and you're ok.
EDIT: I ran a test with -u 45. It starts up like six processes, and the computer lags. I've decided to lower my limit to that.
-
Oh my, oh my! So, it's ok for linux box to suck after install and then it's admin's job to set it up properly, but same doesn't apply for windows?
-
Also, /etc/profile is only executed for login shells. So, this doesn't solve the problem. :)
-
Everything starts at a login shell. My desktop comes from the shell that I typed "startx" from.
If it doesn't, then just where WOULD you have that command?
-
hint: What starts the login shell? And what started that process? What other processes are started in similar fashion?
There's a lot of choices for exploitation. :)
-
muzzy, your accusation of double standards isn't actually aimed at any comment in particular that i could find. who are you accusing of making this comparison?
i would say the vendor is responsible for the shortcomings of their product. so: microsoft is responsible for the shortcomings of mswindows, mandrakesoft are responsible for the shortcomings of mandrake linux and so on. slackware, debian and so on are organisations, so their output is not "product" as such, but, yes, they are still responsible for their output, although of course with their stuff their licences more or less say "use at your own risk". the fact people continue to use slack and debian shows how good a job they're doing of living up to their commercial counterparts. linux is not to blame, the vendor of a specific system where a problem exists is to blame, to the extent that they make certain claims that their software will work, in the EULA and elsewhere.
in fact the GNU GPL has a clause specifying that the software is not guaranteed to be useful for any purpose, and i do not think microsoft has this in their EULA (check it out if you like, i have some of their EULAs archived at http://www.polytheism.org.uk/openopen/files/licences/ but can't be bothered to check right now). while this is not an excuse, it does mean that microsoft make more claims about the "quality" of their software than any GPL software does, not to imply that any entire "linux" distribution is GPL software, but you get the idea i am sure.
re: the ulimit setting, i would put it into rc.local to be honest. fair enough, this probably isn't the "right" place for it, but it will work. i might mention (since we mentioned the slack /etc/profile) that that file also, by default, adds ./ to the $PATH for the root user! this is a really stupid move in my opinion, i think for more than abvious reasons, and the first thing i do on a slack installation is edit the /etc/profile and get rid of this.
but the main point is that certain people still do not realise who is responsible for an end product such as a complete operating system. it is the vendor/distributor of that system, ie: the organisation responsible for putting it together in the first place. Once it is installed, a specific installation of that system becomes the responsibility of that system's administrator. i would say this is a fair model and is true to life, anyway.
-
I was going through other threads to find what I'm referencing to, but there's just too much text to read through it all again. I see that you're saying in another thread it's the administrator's job to keep the system secure. Some other people were bitching about how it's unfair that I compare properly configured (and thus, administrated) windows to a linux system.
I'm getting a little tired of arguing with multiple people without remembering whose stance was exactly what. You all seem to have different opinions, yet you all argue with me and not amongst each others.
Anyway, the rc scripts differ from system to system, and there's no rc.local in every system. Even then, you aren't guaranteed secure because services you run might set the hard limits up again... There are kernel patches which provide better solutions, but again, these would need to be applied.
Also, putting too much responsibility on the administrator is just screwed. If the vendor doesn't fix security holes, is it the admin's responsibility to write binary patches? Well, obviously nobody else is going to do it, but whose responsibility is it really? If you're taking the stance that it indeed is administrator's responsibility to keep the thing secure, no matter what, then we're back to square one regarding my stance on windows and its security.
-
I was going through other threads to find what I'm referencing to, but there's just too much text to read through it all again. I see that you're saying in another thread it's the administrator's job to keep the system secure. Some other people were bitching about how it's unfair that I compare properly configured (and thus, administrated) windows to a linux system.
yes X11 said this (ak! sorry, he is now called kintaro on this board), and to a point he was correct. if you want to do tests to compare one with the other, it's meaningless unless the things you are comparing are on a level field. comparing two systems that are administered properly, using the tools available to the administrator is fair, and comparing two systems brand new, as is, out of the box is also fair, so long as in both situations, people know what the comparison is. comparing one system that is administered well by somebody who knows the system with another system that is badly administered for any reason is not fair, and the results are meaningless.
I'm getting a little tired of arguing with multiple people without remembering whose stance was exactly what. You all seem to have different opinions, yet you all argue with me and not amongst each others.
this sounds pretty paranoid, and in fact it is untrue. there is more than one member i have had recent disagreements with, though you might not be too lucky finding them since they haven't been all in one thread, or nearly so public facing as the "get rid of shit in windows" thread, or whatever it was called. people will have differing opinions, and if you can't remember who said something, don't just claim that the nearest respondent had those opinions which are contrary to your own. perhaps this assumption leads you to believe that people are always against you here? the fact is i think most people consider you to be knowledgeable and fairly understandable (which is pretty good for these boards!)
Anyway, the rc scripts differ from system to system, and there's no rc.local in every system.
yes this is true. i think now that i have looked a little on my home system, that on an LSB compliant system, the right file to modify would be /etc/init.d/boot.local (but correct me if i am wrong folks!) since this script gets executed on any LSB compliant system before we enter our default runlevel or allow anybody to log in. Even then, you aren't guaranteed secure because services you run might set the hard limits up again...
well of course you can just set those hard limits in that file, can't you? or have i missed something here about who is allowed to do what? There are kernel patches which provide better solutions, but again, these would need to be applied.
yup, or accepted into the actual kernel source. i have no idea what the situation is with this or if these solutions are indeed better than ulimit, or what the arguments are, so i can't comment at all here.
Also, putting too much responsibility on the administrator is just screwed. If the vendor doesn't fix security holes, is it the admin's responsibility to write binary patches?
ok, i see your point, there's a line to be drawn, and you reckon setting a reasonable ulimit value falls on the vendor side of the line, while i don't agree. fair enough. i would say that anything that can be done in readable config files or using a GUI that comes with the system, should be the admin's responsibility and anything else is the vendor's. how's that? not all vendors agree. like the whole RHN thing. if i install red hat, the first thing i do is remove that, because i want to use apt to do my own software upgrades/installs, but red hat doesn't give you the option not to install it at install time, because it assumes that it's red hat's responsibility to have rhn warn you to upgrade things. Well, obviously nobody else is going to do it, but whose responsibility is it really? If you're taking the stance that it indeed is administrator's responsibility to keep the thing secure, no matter what, then we're back to square one regarding my stance on windows and its security.
yep, i think i mention where i would personally draw the line above, but you're kind of suggesting a model where there's a problem and *no* solution, whereas usually with the open source stuff i find that if a problem arises there are usually *several* solutions, and this is something people complain about too sometimes. remember when people moaned that linux had no native journaling filesystem? very quickly several appeared, ext3, jfs, xfs, reiserfs and so on. some distros chose different ones to use as default, and as a result the default filesystem for one linux might not be supported by default, by another linux system. This is the downside of choice, if you are given a choice (as a system administrator, user. or software distributor), you have to make a choice, and people will make different choices. this can be seen as a good or bad thing depending on what your priorities are.
-
Privileged processes can set hard limits to anything they want, unprivileged and only lower their hard limit. This is why ulimit in /etc/profile works for loginshells in the first place. The user can limit the shell, but not unlimit. Same isn't true for privileged processes, see setrlimit(2) manpage for the implementation of the resource limits. What I'm saying, is theoretically apache or cron or whatever daemon could just set the limits back to some horribly large one, and then processes spawned by it would inherit those values. You just couldn't be sure.
Further, setting the limits for init, even if it works, doesn't solve the problem. The user can still bring down the system, and as long as the forkbomb process lives nobody else can make new processes. I don't have a linux box to test this behaviour, but either this happens or it isn't effective in the first place. The system will remain responsive, but as no new processes can be spawned, it's pretty much useless.
Many kernel patches indeed provide better solutions, such as per-user accounting for all the process resources. This way the user wont be able to escape hard limits, since they're enforced by the kernel and per-uid. I believe grsec does this, for example.
-
What comes to having choices, it's indeed both good and bad. The real problem is that most casual users (who have been forced to be administrators, by having a computer at home) won't have enough knowledge to make informed decisions. For this reason, it's a good thing that the vendor does the decisions for the administrators. For this reason, vendors should have responsibility for the security and performance and functionality of the system. Administrators these days just can't be expected to have enough arcane knowledge about internals of the system to be able to make good decisions. Otherwise you get people putting ulimits into rc scripts and login profiles... ;)
-
i cannot agree with that last post on two counts.
firstly you more or less say that vendors are responsible for the security and stability of the systems they vend, because administrators are too dumb. with logic like this it is clear to see why you prefer windows over other OSs. no doubt using windows and talking to windows users is what brings you to this conclusion in the first place.
secondly, once again you criticise potential solutions without yourself explaining the answer. by suggesting that people are idiots for suggesting the ulimit line be put in one script or another you are attempting to stifle discussion about this issue. also, you do not clarify where the correct location for such a line might be, which is something you should be doing if you are so staunch about how wrong everybody else's solutions are.
-
I'm not implying that all administrators are "too dumb", I mean to say that among all administrators, there will be those that are not knowledgeable about the exact effects of what they're doing. I also mean to say that it shouldn't be expected for all administrators to understand the systems they administrate. Admins should have the knowledge required to administrate the system, not the knowledge that was required to implement the system.
I didn't suggest that people are idiots over the ulimit issue. I was using it as an example that well meaning administrators trying to solve an issue, can come up with a solution that seems to work but doesn't. Implementation of forkbomb protection is not something that should be left for the administrator, it's something the vendor should do, because they're responsible for implementation and functionality of the system.
I'm not saying where to put the line, because in my opinion, it's not a solution at all. In profile, it might prevent accidental forkbombs. I don't see any proper way to use the ulimit command to provide an actual solution against forkbombs. It needs a kernel patch to properly implement it, no way around that.
-
...so we come full circle. Muzzy, for what it's worth, I feel I should let you know that I've administered both types of systems. I've run XP, 2k, 98, and about a dozen Linux distros. My dad's shared box still uses XP, because he prefers it and I don't deny my (paying!) client's request. I dare you to find a hole in it. Still, I use Linux on my personal boxes. Sure, you can remove MSIE and IIS, and use third-party applications to replace those.
I still prefer Linux. Do you know why? Because crap like this, if it in fact exists on Microsoft systems, is still - to this day - undetected. It's not because the system is secure. I can't verify that for myself, and I *don't* like leaving my users vulnerable to some unknown nasty that could ruin them in a day. At least the Linux equivalent has fixes, in addition to patches by certain distribution maintainers. I could check the kernel for holes myself if I had enough time. Yet I can't do this with Windows. Why is that? That's right, because Microsoft works off of one assumption: the user is incompetent. God forbid I should verify that the key component running my system is error-free, I might fuck something up. They still feel this way, despite the fact that crackers are working as hard (if not harder) to decompile the kernel as they are to check it. Maybe I just like to have more eyes checking the code, more hands fixing it. Or maybe I'm just a lunatic for such backwards thinking.
-
Why can't you check windows? Because you don't know x86 asm? Oh my. Most users don't know C and can't check linux kernel. There have been countless holes in linux and it's still full of bugs. Check any changelog to see for yourself. You can't know your linux systems are secure for sure. I bet you must remember the openssh holes and how it gained the nickname of "Super Security Hole"? Yeah. Hole after hole, again and again. In source that was available for everyone to read... And this was a source that people were interested in reading. Yet, it always took some time for the next exploit to come around. Security holes aren't always obvious in the source, they require some damn skilled people to find them. Microsoft has damn skilled people.
I don't quite get your point anyway. You say windows has undetected issues, and then say linux equivalent has fixes and patches. To undetected issues? How do you fix an undetected issue? If your immediate response is "my thoughts exactly" or similar, we're going nowhere as this has nothing to do with windows anymore.
If you were however still referring to forkbombs, the issues aren't undetected in windows. Just because you are ignorant about them doesn't make them unknown to others. Windows has a lot of issues regarding resource management and such, to great extent because windows systems are rarely used as multiuser interactive shells. The kernel has support for per-process quotas for resources, but you don't typically see these used on your usual windows systems. I'm not sure if there's per-user accounting for these resource quotas, though. I'd have to do some research.
If someone has experience administrating a windows server and knows about the resource quotas, I'd like to know. I really haven't used windows as a multiuser server setup for untrusted binaries, and thus am not confident about all the aspects related to it.
-
Why can't you check windows? Because you don't know x86 asm? Oh my. Most users don't know C and can't check linux kernel.
As was said earlier, you're quite adept at comparing apples to toasters. You're trying to tell me how sparse documentation and debugger output are all you need to fix the source. You're out of your mind - you HAVE to have access to a compiler and the sources in order to modify the kernel. At least with Linux, I have full and ready access to both from the get-go. Last I checked, you had to shell out a few c-notes to guarantee the functionality of a Windows system, and that's not something I - nor any sysop for that matter - should feel compelled to do.
There have been countless holes in linux and it's still full of bugs. Check any changelog to see for yourself.
Et tu? Can you count how many of those were negligible? Last time I checked, every Windows exploit was system-level or better.
You can't know your linux systems are secure for sure.
Fair enough, but at least I can try.
I bet you must remember the openssh holes and how it gained the nickname of "Super Security Hole"? Yeah. Hole after hole, again and again. In source that was available for everyone to read... And this was a source that people were interested in reading. Yet, it always took some time for the next exploit to come around.
Okay, while we're on the topic of "old and oft-exploited avenues of attack," how about ActiveX? Is Downloader.Ject patched yet, or are IE users who dare use Microsoft's "wunderkind" applet code still subject to this malicious misuse of a potentially decent language? Even you yourself admit to not running MSIE with Java enabled, that would suggest to me that you're somewhat less-than-confident about Microsoft's ability to maintain a functional browser. Then again, they haven't done that since they acquired it from Mosaic way back when.
Security holes aren't always obvious in the source, they require some damn skilled people to find them. Microsoft has damn skilled people.
...who still can't make THEIR OWN APPLETS secure. Why should I trust the company - and by connection, its products - if I can't trust its output?
I don't quite get your point anyway. You say windows has undetected issues, and then say linux equivalent has fixes and patches. To undetected issues? How do you fix an undetected issue? If your immediate response is "my thoughts exactly" or similar, we're going nowhere as this has nothing to do with windows anymore.
This has everything to do with Windows, and I congratulate your effort to dilute the issue. The issue here is that, if this vulnerability exists in Windows, nobody has noticed it yet. That doesn't mean it doesn't exist; as I said in an earlier analogy: just because the door is closed, that doesn't mean the house is secure. At least in Linux, this issue has been noticed and recommendations provided for treating it.
If you were however still referring to forkbombs, the issues aren't undetected in windows. Just because you are ignorant about them doesn't make them unknown to others.
My congratulations on the ad hominem above, but that doesn't work as readily as you might think.
Windows has a lot of issues regarding resource management and such, to great extent because windows systems are rarely used as multiuser interactive shells. The kernel has support for per-process quotas for resources, but you don't typically see these used on your usual windows systems. I'm not sure if there's per-user accounting for these resource quotas, though. I'd have to do some research.
I fail to see what disk management has to do with core vulnerabilities. Way to toss out a red herring to me there, though.
If someone has experience administrating a windows server and knows about the resource quotas, I'd like to know. I really haven't used windows as a multiuser server setup for untrusted binaries, and thus am not confident about all the aspects related to it.
I have, so don't go thinking you're talking to some pseudo-intellectual the next time you formulate a reply. I've tried the quotas, and found them to be - at the least - ineffectual; at the most, a persistent annoyance to my primary users. I also don't use IIS or any of the similar technologies. I suspect that I, like you, am intelligent enough to use UNIX-emulating server technologies, which makes for a nice level of confusion amongst those attempting to exploit the shared box.
The difference lies at the point where I noticed that maybe, just maybe, software designed for a server OS might actually run better - natively, one might say - on a kernel designed to replicate the functions of that OS. If I have to explain the differences between "emulated" and "native" then there's been a breakdown of communication and we need to start this conversation anew.
-
I spoke of checking windows, not modifying. Modifying is possible with just asm and debugger, but it's annoying to do stubbing. Checking for implementation validity is still possible.
I don't run Java, ActiveX or active scripting because I don't need any of it, and yes, because I don't trust them. It's unnecessary functionality and a platform that's widely targeted by attackers. The download.ject vulnerability has been patched already.
I have no FSCKing idea why you're ranting about applets here. Also, you do not seem to know what quota means. It doesn't always refer to disk quota.
You also didn't seem to get my point on your flawed logic regarding undetected vulnerabilities. If we're talking about a very specific issue here, you cannot it's undetected. If you say something is undetected, you can't say there is a fix for it. You're trying to say that windows has issues that aren't known, and then it sucks because solutions aren't provided for these "yet to be found" problems. Huh?
-
Damnit, I have to take some back regarding the quotas. I can only find memory quotas and disk quotas being implemented, nothing else so far...
-
Reading quickly (or how long did that take?) through disassemblies of the related kernel functions, I can't see anything to do process creation limiting. Windows seems to be vulnerable to "fork bombing" issues with no real solutions (other than third party kernel patches). Tough luck. :)
OTOH, there seems to be a lowlevel hooking mechanism for process creation which could perhaps be used to implement "nproc" quotas. This might be trouble, though, since it's called in middle of process initialization and killing the process there might not be supported. I'd have to research more into this to say for sure and I'm not really that greatly interested.
-
Oh my, oh my! So, it's ok for linux box to suck after install and then it's admin's job to set it up properly, but same doesn't apply for windows?
Did anyone actually say that?
Feodora ships with a healthy setting...
[x11@kintaro ~]$ ulimit
unlimited
:S
-
that's not the value we're talking about, do "ulimit -a" to see the full list of values that ulimit can change. or "ulimit -u" to see how many user processes are allowed (which is what we're discussing).
-
[root@kintaro ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
pending signals (-i) 1024
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 3838
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
PS. no, that doesn't mean i 0wned his box. he pasted that himself earlier in private as we had a short chat about random things related to system resources :)
-
You can also hard limit NPROC in /etc/security/limits.conf
-
Yea, someone has to break into my system to forkbomb it in the first place, I don't think that will happen though.
-
You can also hard limit NPROC in /etc/security/limits.conf
AFAIK that's read in by PAM, so you're still screwed and vulnerable in same way you're vulnerable in the /etc/profile case.
-
AFAIK that's read in by PAM, so you're still screwed and vulnerable in same way you're vulnerable in the /etc/profile case.
Correct, but i'm still wondering how you suppose this can be comprimised if the limits are imposed before the user even logs in?
-
Correct, but i'm still wondering how you suppose this can be comprimised if the limits are imposed before the user even logs in?
Through any process that launches stuff on its own, for the user. These include webserver and cgi scripts, cron, and any other daemons that are spawned by init and not by a login shell.
Also, user could be a bitch and spawn multiple connections inside the box to get a new clean login process, although the attack would not be as straightforward as it was anymore.
-
Yea, someone has to break into my system to forkbomb it in the first place, I don't think that will happen though.
this misses the point.
on a system with many users (say at a university) where you don't know or trust the users, you still need to be able to impose these sorts of restrictions effectively.
a lot of these security issues do not apply if you use linux on your home laptop or whatever, but *ix is supposed to be a fully functional multi-user networking environment.
-
Yea, well in that case they better set a good process limit.
-
on a system with many users (say at a university) where you don't know or trust the users, you still need to be able to impose these sorts of restrictions effectively.
Just hoping for best seems to work in practice, at least in my university (cs.helsinki.fi)
nikki@melkki:~$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 32755
virtual memory (kbytes, -v) unlimited
I'd also like to mention the network has 3 terabytes of diskspace without quotas. As long as everyone acts nice, things work fine :)
-
Holy fuck.
Im enrolling.
-
Holy fuck.
Im enrolling.
I'd also like to mention the network connectivity is blazing fast, and they give access to hundreds of linux boxes all over the university network. (every computer in every classroom)
Yeah, and it's practically free, except they're currently thinking about making it more expensive for foreigners. I think I spend more to living expenses per month than the university makes me pay per year. It's absolutely fantastic :)
Someday I'll regain my motivation to do some studying too, I feel a little guilty for using the university account as a glorified website hosting service ;D
-
Holy shit, im going there or canada, thats for sure, here in australia University costs more then the average house.
-
Yea, I hear education is expensive abroad. Here, it's damned cheap. Students get cheap housing too. Helsinki University of Technology (hut.fi) has a student village, for example, with 100M net throughout the place. As added bonus, the rent is cheaper than in the public sector. Sounds wonderful, huh?
Finland kicks ass :)
-
yeah, we have finland to thank for linux of course. it originates in helsinki.
-
We have thousands and thousands of people to thank for GNU/Linux/xorg/mozdev/and more and more, millions in fact if we include the people who brought them up.