Slashdot Mirror
Security Flaws In Linux SMBFS
An anonymous reader points out this SecurityFocus alert, which starts "The Linux kernel is reported susceptible to multiple remote vulnerabilities in the SMBFS network file system. These vulnerabilities may lead to the execution of attacker-supplied machine code, information disclosure of kernel memory, or kernel crashes, denying service to legitimate users. Versions of the kernel in both the 2.4, and the 2.6 series are reported susceptible to various issues."
you haven't emulated SMB unless you allow remote execution of code ;)
https://www.gnu.org/philosophy/free-sw.html
Does anybody know of some website or source that's been tracking these kinds of linux exploits, including the date and nature of both the exploits and the fixes?
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
does it allow ROOT?
The difference between spam and poop is that you don't have to dig through septic tanks looking for real food. -- Me
It should be clarified, that this is NOT to do with the smbd process aka Samba Project - but the kernel module smbfs.o
Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Not to sound like a flaimbait, and yes, I use and love linux, but this is some proof that micro$oft isn't the only place in the world that puts out code with security holes in it.
well ... windows file sharing is just that ... a security flaw
Makes me glad that I have an SMB block enforced on my rou32der324f[NO CARRIER]
Azh nazg durbataluk, azh nazg gimbatul, Azh nazg thrakataluk agh burzum ishi krimpatul! This sig blocked by Slashdot.
I'd like to point out that is a MS originated technology that only got put in Linux for compatibility with MS systems. Most Linux-only users use NFS, which does not have these security holes. Most 'secure' network environments don't even use SMB on windows machines due to security holes in the Windows implementation. My 2 cents, don't use it, its buggy and slow and suchs. On the other hand, many people need to use it in their home networks to share files between windows machines and Linux machines. My suggestion for those users is to set up a firewall which blocks SMB from the outside. And don't make samba shares on your firewall box.
If you like what I've said here, and want to read more, go to http://www.krillrblog.com
Major distributions will have patches available. Possibly even the main kernel tree.
tasks(723) drafts(105) languages(484) examples(29106)
It just seems a tad ironic that a part of the kernel that makes linux more compatable with MS Windows is again the root cause of more security problems. All the more reason to ban SMBFS from my home network.
I'll say this once, this is absolutely correct. We've known about this for a long time. SMBFS is deprecated. This is why CifsFS was written. CifsFS is a standard part of 2.6 and is available as patches for 2.4 from samba.org. CifsFS is faster, works with newer versions of Windows better, and is much more secure. More importantly, SMBFS is not being maintained. Critical bug fixes get made but that's only because it's in the kernel. Please don't use it unless you have to. Steve French is the author of CifsFS and has done a fantastic job with it.
This page gives a much better overview of what it is.
More information also here
http://www.derkeiler.com/Mailing-Lists/VulnWatch/2 004-11/0007.html
Any more details about this issue? Any backported patches to 2.4.27? Any idea if 2.4.28 is o.k. for sure or should we wait for 2.4.50?
Do You have any idea when can I stop upgrading the kernel every month ? This is the 5-9th kernel realease from November 2003 when the first-in-the-row (first of a burst...) kernel security holes began. I do not like to update kernels with all the patches neccessary to do that and all the fuzz with remote updating hosted stuff...
At last,
I do not like to reboot every month
SP2 users are unaffected.
Hasn't it already been mentioned that this has nothing to do with Samba?
One man's selflessness is another man's annoyance.
Here is the information you are looking for.
SecurityFocus says, "The vendor has released version 2.4.28 of the Linux kernel to address these issues."
Heh.
Not all of us here point and laugh every time Microsoft has an exploit.
I think that one of the major misunderstandings that many people have is that software will be absolutely perfect. It won't be. We deal with systems with many layers of complexity, and sometimes these things fall through the cracks.
If you want a perfectly secure system, you'll have to audit the code personally.
Now, I'm definitely not a Microsoft fan (see my sig), but does it strike anyone else as a little scary that it took 2 months to get this fixed properly? I mean isn't that one of the main benefits of open source is that it gets fixed faster?
Your Windows PC is my other computer.
SMBFS is for mounting SMB shares on a Linux machine. Samba is for sharing files on a Linux/Unix/BSD machine with windows machines (or Linux machines with SMBFS, but NFS is better suited to that).
BSOD screensaver
Just wondering if the SMBFS kernel option in EreeBSD has the same vulnerability
$FreeBSD: src/sys/fs/smbfs/smbfs.h,v 1.8 2003/02/08 05:48:04 tjr
To blog is sublime
Cb..
Based on the info http://www.securityfocus.com/archive/1/381420here, it took 53 days from initial contact to public release of the patch (and public notice of the vulnerability). How does this stack up against other OSes?
We apologize for the preceding message. All those responsible have been sacked.
Microsoft did NOT in fact invent/originate SMB. IBM did.
I found Linux firewalls to be a real PITA. Getting XFree86 3.3.6 working on my Thinkpad 760XL was a lot easier.
At least I don't need a firewall any more; I don't even have an Internet connection at home.
(Though pointers to tools to help out a networking novice would be nice.)
tasks(723) drafts(105) languages(484) examples(29106)
Comment removed based on user account deletion
It wasn't developed by Microsoft. It was originally an IBM protocol, which was....are you ready?....extended by Microsoft to get what we know today as SMB.
"City hall" in German is "Rathaus" Kinda explains a few things......
In what way? I've never had any trouble with them (at least since iptables came in). What did you need to do which made it complicated?
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Looking at their schedule, it is unclear what actually happened. Note that on 25 September 2004 they made their initial contact, but on 22 October 2004 they say they sent a second round of vulnerabilities in, followed by a set of patches on 27 October. The developers would then have to take all these patches, compare it to anything they may have come up with in the meantime, and make sure they didn't break anything else.
The public disclosure occured 17 November 2004, about 20 days later, after about a week's worth of testing time as 2.4.28-rc3. Personally, I would not have liked them to have announced on the first set of vulnerabilities if there was some knowledge between October and November that more issues were being found. Otherwise everyone and their kin would be combing the code looking for any issues missed in smbfs.
Absolutely correct. Well, probably. You see, if there are unseen holes in the protocol itself which make a secure implementation difficult, it's sorta like being parked on a busy freeway - yes, the guy who drove into your car is 100% at fault legally, but we all know that the technical/legal answer is far from the moral answer.
I'm not saying that MS is even morally at fault here. Just pointing out that, until we know the details (and we'll likely never know the details sufficiently), there is that possibility that we can still take out our flamethrowers and point in the Redmondly direction.
Who am I fooling - /. doesn't need the moral right to flame MS for /. to flame MS anyway...
Your drivers I mean.
Normally, I wouldn't bother to mention about this. But slashdot somehow thought someone mentioning that SP2 was worthless because it had compatibility problems was worth a major mod-up.
So I figure pointing out how Linux also bundles incompatibilities with security fixes should be very well received, right?
Isn't smbfs supposed to be the module used to _access_ a smb mount. How can an attacker use a module that is designed to connect _to another_ computer. It's not like smbfs opens a port or anything?? Or is there a counterpart vulnerability in the SAMBA server (contrary to above comments)? I always thought the server is what gets attacked.
I would appreciate it if someone who actually knows the code can clerify this.
Anton Markov
*** Linux - May the source be with you! ***
Your story is paradoxical.
...
A Linux developer can't exploit a Windows bug because that would make him a Windows developer and you said that a Windows developer does nothing until a Linux developer exploits it but he can't because
This is one reason a microkernel OS can be more secure and robust. When shit breaks loose the kernel is still isolated.
Engineering is the art of compromise.
Yup... was known as IBM Lan Manager back then. the LANMAN bit still appears in SMB packets today.
"You shouldn't have an internet server running SMB anyway"
But note that it's SMBFS that's flawed, _not_ the smbd daemon itself.
FP.
Also FatPhil on SoylentNews, id 863
The problem is, I don't really understand firewall implementations. (Though I think I understand some firewalls themselves just fine.)
tasks(723) drafts(105) languages(484) examples(29106)
Everyone may make mistakes from time to time, but it takes a /. mod to really shine in the stupidity
stakes.
hehe
Some dickwad fails to parse "and hundreds of programmers"; said dickwad subsequently laughs derisively at the GP; I accurately call the dickwad an idiot; *I* get modded Troll for pointing out the hard truth.
You just gotta love the babbling-monkey-moderators at Slashdot, eh?
"You can't fight in here, this is the war room!"
I'm switching back to Windows XP! Heck, Windows won't even allow users the choice of using all these insecure file systems! Now that is security!
"Freedom means freedom for everybody" -- Dick Cheney
After these minor changes that took me all of 3 minutes to make, I no longer have smbfs anywhere on this network.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
ERROR DETECTED
REASON - NFS used with in 10 words of the word secure.
RESULT - AHHHH!!!!
Someone should say 'there are lots of ways to comit suiside on slashdot, one of these it to suport Microsnot' face it, if you want impartial news goto TheRegister or BBC, slashdot is for FUDing it's self, I happen to enjoy it, but some people don't.
Total non-sequitur.
Linux developer finds linux bug, fixes bug 53 DAYS LATER. End of story.
I am very small, utmostly microscopic.
Only if you're fool enough to upgrade your entire kernel just to fix a security problem! Wait for your vendor to provide patches, then apt-get upgrade (or use whatever tool your system provides).
Filesystems by necessity have to be implemented to some extent in the kernel because they have to hook the VFS layer. However, you make a very good point that it does seem to be a big risk to implement the entirety of smbfs in kernel space.
Recent Linux kernels (I think 2.4 onward) have a mechanism for doing what are called user space filesystems. Basically, the kernel only knows enough to talk to a daemon which implements the filesystem and exposes it to the kernel. In this manner there is a very well defined interface between the kernel and user code which hopefully is bug free.
In some ways this is sort of a partial microkernel design. With that comes the inherent loss of speed having to do the context switches between kernel and user mode. In the normal filesystem case you have a context switch from user to kernel mode, the file is accessed, and then back to user mode. In the case of a filesystem implemented in user mode you have to switch from user mode to kernel mode, then to user mode in the FS daemon then back to kernel mode then back to user mode in the process trying to access the file. And that is the best case. Throw in a scheduler without the knowledge of which process is waiting for what and messaging between two user space processes through the kernel can be extremely costly!
In this case, yes, I think I probably would have recoded smbfs to use the user mode filesystem handler. But the code was already written years ago to live entirely in kernel space before there was really any sort of well defined standard for a user space file system. Given that this is as far as I can remember the only major bug in it one might say that it hasn't really been that bad having it in kernel space.
So the tradeoff becomes do you want to have it in user space (where it would still vulnerable to DoS in this case) and sacrifice some speed or do you want it to run in the kernel at full speed?
You seem to be reaching here. If implementing the protocol safely is beyond the ability of Linux developers, then they shouldn't do it.
More likely the truth is that smart developers for Linux and smart developers for MS make mistakes and will continue to do so. My only complaint is that there shouldn't be a double-standard.
Ummm... first off, that whole post wasn't comprehensible.
Secondly, there aren't "1000 or more" system calls. I quote /usr/src/linux/arch/i386/entry.S:
So, there are 284 syscalls. Hardly "1000 or more".All's true that is mistrusted
That's what RedHat Enterprise gives you. Unfortunately, the price point is designed for ... the enterprise. If you want a $70 pay once for x years updates, it looks like Suse is your best best. Or, go with Fedora Core for free, but be prepared to upgrade every year. There was also a company that sold RH7.x and RH9 updates for a few dollars a month - I can't remember the name. It was an example of a key business advantage of opensource. When the primary vendor abandons the product, another company can step up to the plate if there is a demand. A sibling post has a link to a volunteer update service for RH9.
Ummm... no. entry.S defines every system call in the kernel. system.map defines every symbol exported by the kernel. Your kernel exports 10104 symbols (which makes me think you compiled it with debugging turned on). Of those 10104 symbols, 190 (I think that's the magic number for 2.4) are system calls. The rest are just exported symbols.
They're just names for parts of memory that make linkers a little easier to write -- in your example, anything you could do with the symbol length_code you could do with the number c0343080.
All's true that is mistrusted
The reference to XFree86 3.3.6 makes me wonder if you were using the older ipchains instead of iptables. iptables, being stateful with good connection tracking for various protocols, is much easier.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
- Never trust your input data - always check it!
- Always check for array-bounds and function return codes.
- Document everything with comments and design documents.
- If you forget a semicolon or close-parentheses, the compiler will try to fix it, but it'll probably do it wrong.
- Always number your punch-cards so that you can resort them if you drop them.
One and a half of those things are no longer true, and most of the security holes seem to come from people ignoring the first two of these principles. I really really like the C Language, but people shouldn't use it for anything sensitive unless they're willing to be really careful, but there's too much badly written code out there.Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Sure, it's a Microsoft protocol, and an old funky one they mostly inherited. That means that if you implement it, you need to not only be careful in all the ways you're always supposed to be careful, like checking array bounds and checking for malicious input, but you need to think about assumptions that the protocol makes about problems that the MS file system or other OS parts would fix that you're going to have to handle for yourself (or that you can trust Unix to take care of for you), and threats that wouldn't have bothered Windows that might bother Linux, and features that Windows wants that you really shouldn't fix simply by running as root, etc.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
That sounds like the slashdot I've been reading for years.
Yes, but there's still no reason to run smbd on a net server :)
I'm still on kernel 2.2.16C37_III ! :) No seriously, I am.
Most modern systems can mount webdav to share just fine, you can server it from all kinds of systems and can work with it from just about any kind of system. With ssl you can make it secure enough. So you end up with something nice and fast and where you are free to change implementations at any time on client or server without breaking stuff.
Another option is sftp. I am not sure how easy that is to do under windows and osx but I expect someone has a vfs layer for it under those. Under kde and gnome sftp is transparent to work with and it should be very secure, that is the way I usually share files is with sftp.
The advantage of both of these is that they are entirely user space. Worrying about speed with these file sharing seems seems pretty silly in most cases. You have such vastly more cpu power available then the system needs for file sharing that trading security for speed which is what many of these systems is doing is ridiculous. We should be designing stuff for security first and speed second since who cares how fast a machine can be compromised is. As long as it is fast enough that is fine.
Another thing really needed is more use of safer libraries. Code is not an asset it is a LIABILITY the more of it you have the worse off you are. You need to offload as much stuff to common libraries, using higher level languages which have more safety features built in etc. In the end you will end up with safer and more reliable programs and strangely enough most of them will tend to be faster for many reasons.
Computer modeling for biotech drug manufacturing is HARD!
Unfortunately, CifsFS doesn't seem to support NT4. As NT4 is _still_ a significant part of the Windows user base, this appears to me to be a problem.
I'd be glad to be proved wrong, however.
FROM SECURITYFOCUS:
During an audit of the smb filesystem implementation within Linux
several vulnerabilities were discovered ranging from out of bounds
read accesses to kernel level buffer overflows.
To exploit any of these vulnerabilities an attacker needs control
over the answers of the connected smb server. This could be achieved
by man in the middle attacks or by taking over the smb server with
f.e. the recently disclosed vulnerability in Samba 3.x
While any of these vulnerabilities can be easily used as remote
denial of service exploits against Linux systems, it is unclear if
it is possible for a skilled local or remote attacker to use any of
the possible bufferoverflows for arbitrary code execution in kernel
space.
Gee, how often does Microsoft have unknown persons audit their code (besides the occasional code theft, of course.) I think that this exemplifies the power of open source. Some subtle exploits were turned up during an audit. As of now, securityfocus is reporting that there are no exploits developed for these errors. But vendors are already providing patches!
MS with it's Billions of dollars simply can't be as responsive. Er, well they could be, but they choose not to be.
The problems discovered require an a remotely mapped SAMBA share to be mounted (remotely! The lunacy!) and be subverted by a man-in-the-middle attack DURING a DOS.
Now, maybe www.sco.com could worry about this, but I just can't imaging too many linux admins leaving samba shares mapped remotely (especially DURING a DOS.) Joe-six-pack cannot set up a samba share without help. This is not something that is able to be exploited on just any-old default installation. You have to start SMB and have a mapped samba share! Is it any wonder that treating this code to a serious security review was a low priority?
I don't see how this is applying a double standard.
"God is dead." - Frederik Nietzsche
Yes it's been fixed and your machine has been secured from it for a few days. Good ol' up2date took care of me too :).
Regards,
Steve
thanks for the info. After reading the parent and your post I decided to switch, and I've successfully done so.
I had no idea this even existed, but indeed the switch was quite simple. The only problem I ran into was when mounting shares as a user but this was an easy fix (had to properly chown the mount dir, oops)
If you don't want someone to copy something, don't give it to anyone.
http://lists.insecure.org/lists/bugtraq/2004/Nov/0 223.html
Unofficial 3rd-party fix for slackware 10:
http://slacksec.info/update_12
that you can always just get the security patches of the kernel mailing list (or simply find the BK changesets) and apply them to your chosen kernel yourself -- sure you may have to fiddle a bit with the patches to get them to apply cleanly, but at least it's possible. This is not the case with closed source software.
HAND.
I can recommend shorewall. Very easy to set up and "secure by default" (ie. has built-in rules to prevent various forms of spoofing, denies incoming traffic by default, etc).
HAND.
i think there are serious bugs in the /. lameness filter aswell.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
Not during DOS attack. It has the potential to used as one, it doesn't need one to work.
Also it doesn't require a man-in-the-middle, that's just one way to do it. The other is if the other machine is malicious or compromised itself.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
True. I dismissed that initially as ridiculous, but I guess it is possible. Not likely, but yes, possible that someone would remotely mount a share from an untrusted host.
"God is dead." - Frederik Nietzsche
Having things run in the kernel space is just plain stupid.
Keep things out of the kernel and you are on to a winner.
The kernel is NOT the place to be handling remote file systems, it's just plain silly.
Unix (likes) are dead. Not only that they are beginning to really smell.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I have no SMB shares -- I even compiled my kernel without SMBFS support. Honestly, I really don't see the point with SMBFS. All the machines on my LAN have NFS support compiled in, and the ones with printers attached are running CUPS. That seems to work fine.
If I actually wanted to run a Windows box for some reason, I'd probably just run open-source NFS and CUPS clients on that. A non-secret, non-proprietary protocol is always going to be inherently more secure than a secret, proprietary one; because there is a proper distinction between what really needs to be kept secret for security reasons, and what can't be kept secret because the source code is available to all.
Je fume. Tu fumes. Nous fûmes!
There is always `rm smbfs.o` That might help.
No, I was using iptables.
tasks(723) drafts(105) languages(484) examples(29106)
As I wrote in a comment just above this one, I had similar difficulties with cifsfs. I agree it isn't mature yet.
don't make samba shares on your firewall box
Don't put a harddisk in your firewall box.
CC.
TaijiQuan (Huang, 5 loosenings)
OMG! How can we find a way to blame Microsoft?!!?
"Gee, how often does Microsoft have unknown persons audit their code (besides the occasional code theft, of course.)"
I'm not sure what you mean by "unknown" here. I'm sure in the last few years individuals within MS who didn't write the code are auditing it for security.
"MS with it's Billions of dollars simply can't be as responsive. Er, well they could be, but they choose not to be."
Well, the number of different programs running on Windows is probably an order of magnitude greater than on Linux so more care is required to make sure a patch will not mess things up. The Linux community can always fall back on the excuse that "it's free so you shouldn't complain". Obviously MS can't.
"I don't see how this is applying a double standard"
I don't see much interest on Slashdot on breaking down a Windows security bug to see how difficult it would be to exploit, but there's always someone who will provide excuses for Linux here.
Can we start blaming Microsoft for bugs in Linux now?
Not that I'm a fan of M$ but you can probably blame IBM too as they are the ones who wrote the first version of SMB
I have this exact discussion quite often. The argument often boils down to this: putting a network file system in userspace would increase kernel stability and make it easier to write at the cost of performance. It would be very difficult to expose a stable user-level API for the necessary VM tweaks to put a network file system to it's performance limits.
> > that it's normal to have this kinds of flaws.
> Total non-sequitur.
I think he means reverse engineered, or at least that's what he should have meant. The smbfs module is a reimplementation of the SMB protocol client, which has nothing to do with emulation. There's no simulation of another hardware architecture, and there's no api translation. Parts of the protocol are poorly documented, though. I don't know if that's only an issue for the server team or if the client documenation is incomplete as well. If the the protocol documentation is poor for the client, then it might excuse poor or incomplete interoperability with MS products, but it's still not clear to me that it would make it difficult or impossible to write a secure implementation.
Mike
The problem is that the dollars go to marketing, not betatesting, and the programmers work on adding features, not fixing bugs.
Fixing bugs allows you to release a new minor version; it brings not a single cent in. Adding features allows you to release a new major version and hype it with marketing, for a nice profit. Therefore, it makes sense for companies to ignore bugs (or combine bugfixes with features into the new release, to provide added incentive for buying the same product again) than to have their programmers hunt for bugs or fix known ones.
Obviously, there's expections; if, for example, your business strategy is to sell added content for the core package, it makes sense to make that core program as bugless as possible, to keep the customers from escaping to competing products.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
LRC, the best-read libertarian site on the web
When did I say that the security flaw was Microsoft's fault? I don't believe I even inferred that.
All I was doing was correcting the person who said it was a Microsoft-designed protocol.
It's not.
It was extended by Microsoft, which has absolutely jack shit to do with the security flaw in the Linux kernel.
Don't be so damned touchy....
"City hall" in German is "Rathaus" Kinda explains a few things......
Actually I was thinking DoS in that with the file system running as a process you could still crash that process with this exploit. However, you are right, the Linux OOM killer BLOWS. I use spamass-milter on the mail servers here which tags both inbound and outbound mail. Got a call one night that the mail server was down; came in and found all of the processes had died but had no clue what the hell was going on. Rebooted it and it all seemed normal. Came in the next morning to find it had crashed again in the middle of the night.
Well it turns out that someone sent a 500 MB attachment out of here which caused spamass-milter and SpamAssassin to eat up all the RAM and swap on the server at which point the Linux kernel killed every process. Since then I now have a 50 or 100 MB limit on e-mails because obviously if someone inside could do it by accident someone outside could do it on purpose and kill the server. Of course, the interfaces would still be up but no ssh. I also took care to run a null modem between it and another server with a getty running. The getty will be refired by init if it gets killed so if for some reason something similar to this happens again I can at least fix it remotely.
Pissed me off too, the night that it happened I had been drinking quite heavily at the local bar and wound up coming in to work at 11 pm totally plowed. On the bright side some ugly chick had been hitting on me so it gave me a good excuse to get the hell out of there. :-)
Try http://www.debian.org/security/. It's more than just a line in your sources.list.
and the fixes?
Yep, that's there too. For example, this page about an xpdf problem has date reported, links to the bug track which document the problem, the CVE page, itself what you are looking for, and packages to fix the problem. XPDF? Bummer, I had no idea, but I'm glad it got fixed in the upgrade last week.
Practically, you drop the appropriate line into your /etc/apt/sources.list file:
deb http://security.debian.org stable/updates main contrib non-free
deb http://security.debian.org testing/updates main contrib non-free
and security update will happen at every apt-get update, apt-get upgrade you do. Asking to add this line has been part of the installation for a long time. It may be the only thing you need for your sources.list file.
The Sarge net install CD gets all of it's packages straight off the web and does so before starting services that might be exploited. This makes every install as current as it can be and the whole process relatively secure. That's the bottom line, right?
Compare that to the typical Windoze wipe and reload with the "orignial" years old CD that came with the computer and M$'s aging codebase and you start to see how the free software development and distribution methods are vastly superior to closed source.
Friends don't help friends install M$ junk.
I'm not sure what you mean by "unknown" here. I'm sure in the last few years individuals within MS who didn't write the code are auditing it for security.
/.? :-)
Fair enough. What I meant by "unknown" was partly as you point out, some parties not directly involved in code development. But the beauty of this particular Linux SMB audit is that it apparently did not originate from the same organization that developed it. A truly independent audit, with no financial incentive for pulling punches. Internal Microsoft audit results never get publicized (with interim work-arounds) until a patch is ready.
"MS with it's Billions of dollars simply can't be as responsive. Er, well they could be, but they choose not to be."
Well, the number of different programs running on Windows is probably an order of magnitude greater than on Linux so more care is required to make sure a patch will not mess things up. The Linux community can always fall back on the excuse that "it's free so you shouldn't complain". Obviously MS can't.
I disagree with your assessment on orders of magnitude. The variety that exists in the open source world is much more complicated than the Microsoft world. You imply that Linux patches are 100% untested - that is absurd. Also, not all Linux is free (as in beer.) Microsoft delays patch roll outs inexplicably.
I don't see much interest on Slashdot on breaking down a Windows security bug to see how difficult it would be to exploit,
WHOA! Are we reading the same
but there's always someone who will provide excuses for Linux here.
Now that is a loaded statement! Was I providing excuses? Are you now going to turn your statement on its head and say you mean "someone" but not me? {Sigh.}
No no, it's not excuses for Linux; it's more of an opportunity to bash Microsoft for having poor disclosure (even though that seems to be finally changing) and poor patch timeliness.
"God is dead." - Frederik Nietzsche
"I disagree with your assessment on orders of magnitude. The variety that exists in the open source world is much more complicated than the Microsoft world."
I'm not sure what you mean by the variety being more complicated. Given that MS has about 90% of the desktop market it makes perfect sense that there are many more programs written for Windows than Linux.
"You imply that Linux patches are 100% untested - that is absurd."
I implied nothing of the sort. I do doubt however, that any significant testing effort is performed to insure a patch won't affect other programs (which is quite different from tesing whether the patch successfully handles the bug). As far as my comment on "it's free so you shouldn't complain" its something I learned from the open/free source community. You're not seriously going to suggest that it's not a common attitude are you?
"Now that is a loaded statement! Was I providing excuses? Are you now going to turn your statement on its head and say you mean "someone" but not me? {Sigh.}"
I'm sure you're a fast typist but I wouldn't claim that all Linux excuse posting on Slashdot was done by you. Thus using the word "someone" seemed quite appropriate.
Fortunately, it is possible to disable the OOM killer. The tradeoff is that it is then possible for poorly-written programs (such as spamassassin) to exhaust memory and then not terminate; depending on the programmer's level of ineptness, they will either continue blithely on after a failed malloc producing unpredictable results, or sit there and spin forever waiting for the malloc to succeed.
I guess the only real solution is to run programs which are well written and nice to your system by design. I had an idea once about taking priority into account when in a OOM situation, but never wrote any code. The idea would be that lower priority processes would be killed in preference to higher priority ones. That way, if you know you have a misbehaving app like spamassassin, you can just nice it to 10 or something - that way it is harder to DoS the system, and it becomes the first choice for the OOM killer.
Yeah, I know that feeling. Fortunately I'm not employed as a sysadmin right nowLRC, the best-read libertarian site on the web
A lot of otherwise smart, and sometimes tech savy, people do things that seem rather stupid from a security standpoint. It's usually a matter of social engineering.
Though in this case the odds do seem a bit lower because anyone going to all the trouble to figure out and setup a Linux box for mounting remote windows shares is having to do more work than a few simple click in most cases, the thought and effort one must go through should create a greater inertia to impulse thinking that social engineering often relies on.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
There are about 200 Linux distributions (last time I checked.) You don't understand that 200 separate vendors is inherently more complicated than a single vendor? So you change the subject to an irrelevant questionable factoid?
You certainly did, in your earlier post. Go back and read it again.
Cute. But I wasn't excusing Linux for anything. Perhaps all the other "excuses" you see posted are merely accurate respresentation of facts, and you are twisting them with your skewed perspective?
To your original post, I still don't see how there is any double standard here. The open source model allowed a preemptive approach to be taken here. That fact alone is a tremendous acheivement of the open source model.
If Microsoft could be as responsive, perhaps attitudes would be different. But I don't see how they ever can be, with their current closed source approach.
"God is dead." - Frederik Nietzsche
"There are about 200 Linux distributions (last time I checked.) You don't understand that 200 separate vendors is inherently more complicated than a single vendor?"
Well, if you're claiming that these 200 Linux distrubtions are so incompatible that they make the complexity of dealing with 10-100 times more applications on Windows trivial by comparison, then you're making a really good argument against adopting Linux.
I don't think the Linux world is really that grim. I suspect that Linus and the core Linux developers don't give a rat's ass about the 195 Linux distributions that probably make up less than 1% of the Linux "market" and make no special effort whatsoever to make sure a patch doesn't mess them up.
"You certainly did, in your earlier post. Go back and read it again."
I have read it. The fact that you don't quote the part of my post that you claim implies "that Linux patches are 100% untested" is pretty clear evidence that you can't find one. Why not just admit you were wrong and move on.
Thanks for changing the subject AGAIN. Thanks for partial quoting again.
Something you imply isn't something to be directly quoted. What you imply is the gestalt of your post(s), and that certainly was your implication.
IHBT. Ouch.
"God is dead." - Frederik Nietzsche
"Thanks for changing the subject AGAIN."
Care to be more specific about what you mean?
"Thanks for partial quoting again."
"Something you imply isn't something to be directly quoted. What you imply is the gestalt of your post(s), and that certainly was your implication."
Let me get this straight. I'm being critized for partial quoting (whatever that means) but it's OK for you to derive my intent from my "gestalt" without quoting me at all. You don't find your critera a bit inconsistent?
"IHBT"
So I'm a troll now. OK, calling troll is always the last argument of the incompetent on Slashdot.