Operating Systems > Linux and UNIX
Linux Kernel Security. forkbomb havoc
muzzy:
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.
Orethrius:
...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.
muzzy:
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.
Orethrius:
--- Quote from: muzzy ---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.
--- End quote ---
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.
--- Quote ---There have been countless holes in linux and it's still full of bugs. Check any changelog to see for yourself.
--- End quote ---
Et tu? Can you count how many of those were negligible? Last time I checked, every Windows exploit was system-level or better.
--- Quote ---You can't know your linux systems are secure for sure.
--- End quote ---
Fair enough, but at least I can try.
--- Quote ---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.
--- End quote ---
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.
--- Quote ---Security holes aren't always obvious in the source, they require some damn skilled people to find them. Microsoft has damn skilled people.
--- End quote ---
...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?
--- Quote ---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.
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
My congratulations on the ad hominem above, but that doesn't work as readily as you might think.
--- Quote ---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.
--- End quote ---
I fail to see what disk management has to do with core vulnerabilities. Way to toss out a red herring to me there, though.
--- Quote ---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.
--- End quote ---
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.
muzzy:
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version