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
A Microsoft exploit notice.... Wow.
Major distributions will have patches available. Possibly even the main kernel tree.
tasks(723) drafts(105) languages(484) examples(29106)
A security flaw in the implementation of a protocol developed by Microsoft? Naw... Couldn't be! Microsoft's stuff is built to last. There's no such thing as a security vulnerability in Windows.
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.
"not vulnerableLinux kernel 2.4.28"
In your face, 2.4/6.* 2.4.28 Rules!
the website hardly explains it at all, it seems. Am I missing something? Is there some hidden link I need to click?
"Software is like sex, it's better when it's free." Linus Torvalds
Quick, everyone consider switching to windows because this linux thing is obviously flawed and buggy!!
:)
Seriously, this is bad (haven't RTFA yet of course), but not that bad. You shouldn't have an internet server running SMB anyway, and while it'll probably be on your desktop system (for those who run linux on the desktop), but a good little linux hacker will have a firewall running anyway, right?
Though I'm sure people like scoble will "mention" this in pointed ways
NOT!
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
... I'm using Debian!
All those people around here who whine about it being old and crap for having 2.2 can no wipe those smiles of their faces.
So there.
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
Pardon my ignorance.... What is the smbfs doing in kernel space? Shouldn't that be the domain of Samba?
No, no funny for you.
1) You used only 1 $ which is good but you lack enthusiasm.
2) Winblows simply doesn't make up for your former mishap.
3) Uppercase dammit !!!
SP2 users are unaffected.
"...denying service to legitimate users..."
HAHA! that could never happen to me. I feel sorry for the losers that are gonna get hit by th*&$^)### (connection lost)
This sig contains repetition and redundancy.
A bug in SMBFS implementation? Are you sure it's not just a really finely crafted Windows RPC emulator?
/* this needs more testing but the fsckin deadlines were due */
/* who the heck knows why this even works */
/* what the hell is a buffer overrun anyway? */
Speaking of a Windows emulator...these bugs are purely theoretical, which means until we're even convinced that they're exploitable (oh you mean they are?) um until we're convinced that there's exploit code out in the wild and there's immediate danger (hehe, that should stall 'em for a bit) we'll put the feature enhancement in testing for a week or three.
Internally, I bet it's easy to fix those bugs -- they just need to do a pattern check for
or maybe
or
SecurityFocus says, "The vendor has released version 2.4.28 of the Linux kernel to address these issues."
..the vulnerable code! We'll destroy it in Mt Doom!
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
Next they'll find exploits in WineX. And VMware.
There is a pattern. Don't bother looking for it until you have the motivation to go looking for it.
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.
Linux developer finds linux bug, fixes bug. End of story.
Windows developer finds bug, does nothing until said linux developer finds said bug and procedes to exploit at will. Windows developer frantically attempts to realease patch after millions lost to clients from said exploit.
#1 It'll get fixed real soon... probably already is given that I've had two kernel updates within a few days on my FC2 machine.
#2 Unless you're a complete fool and are using the protocol openly on the internet, the chances are good that you're relatively safe from exploit since you're on a private network. (It would take someone hacking through your router just to exploit something on your internal network. Possible but low on the order of things.)
In any case, It's an important bug and it must be fixed and I have all the faith that it will be quickly.
Microsoft did NOT in fact invent/originate SMB. IBM did.
... And who implemented SMB in the Linux kernel? Microsoft? Get real. Linux developers implemented SMB in the Linux kernel.
:)
That implementation now has a major security vulnerability in it. MS blame: 0%. Linux developer blame: 100%.
No use arguing.
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
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...
Simple to set up and will run on any old machine you have lying around.
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! ***
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.
mod article down
Now I'm the grandest Tiger in the Jungle!
"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)
SecurityFocus have this down as a "Design Error". Is that in the design of the implementation, or the design of the protocol? Can we start blaming Microsoft for bugs in Linux now?
As we all know, Windows is a closed-source operating system, which offers documentation for all their apps and apis. The SMB Filesystem had to be developed without seeing the source code of the original fs. Remember, this is an emulation which means that it's normal to have this kinds of flaws.
Does anybody know if Pat is well enough to work on a ptch for this?
GETPKG - Package Management for Slackware
It is amazing how many posts in this article have comments and have no fucking ideas what the the hell smbfs is even for or what it does. As noted by the comparisions to smbd which is the samba daemon.
Guess I should migrate to Windows.
Good thing I use OS X and NetBSD. Hahahahaha.
You got served.
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
...Or Would You Rather Be A Fish?
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.
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).
From now, the GREAT SOLUTION is to use a microkernel OS as Mach, Hurd and Darwin.
open4free ©
This is Slashdot, where all that is OSS is good and all that is Microsoft is bad. To rationalize through your statement properly, you need to place yourself in the shoes of a Slashbot, which means thinking that way. You have to adopt the attitude that major, embarrassing flaws like this in the OSS world are just kind of glossed over while minor, user-run executable attachment worms are a "new M$ hole!"
I love it. It's a kernel driver written by OSS guys that has a security flaw (smbfs.o) in the Linux kernel, but now suddenly it's Microsoft's fault because they extended the protocol once, despite that not having anything to do with the security flaws of the OSS driver.
What has happened to Slashdot?
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.
(you always are inside of the TCP/IP system).
(your peer always is inside of the Internet system).
The microkernel too is to move the HUGE TCP/IP source code from the kernel space to user space and the hackers of the evil system can't penetrate to your peer
(they can remotely execute inside of the vulnerable complex TCP/IP clients but they can't execute code from your trusted microkernel & other clients processes)
open4free © : design OS expert
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.
Sure, I run Linux. I only used SMB when connecting to a local machine that the company I was working for at the time had me take home. It was mostly useless, running the latest M$ OS (yippee). Everything ran behind a firewall with (among other things) ports 137, 138 and 139 blocked. There was *very* much more worry (for good reason) for keeping lots and lots of virus software on the Microsoft box. Once every couple of years I run a root-kit checker on the Linux box. I haven't ever gotten anything, and don't expect anything, but I've gotten emails about the manual virus for Linux: 1. create a shell script with: cd /;rm -Rf ./*; change permissions to executable, and change ownership to root, then run it, and call it 'manual virus'.
http://shit.slashdot.org/article.pl?sid=04/11/22/2 351238
Duh. Nintendo made Super Mario Bros. in 1985. Kids these days....
Windows is crap no matter what platform you implement it on.
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
Yes, but there's still no reason to run smbd on a net server :)
It's still wrong. Plenty of companies have millions of dollars and hundreds of programmers.
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
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.
For many of you, this is still Microsoft's fault. Jeez, you poor bastards will blame the Apocalypse on MS when it happens.
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
Look at these , this makes Linux as a network system not to be trusted. Im shocked to see this, especially the unpatched items, which are quite servere.
;)
http://secunia.com/product/2719/
Anyone know if the ac-patches addres these things.
How do Suse and Fedora handle this, or don't they?
It raises some serious questions with i gues.
Im going on a patch hunt
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
Everyone here knows you don't get security holes in teh linux.
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!
You're talking nonsense. Any decent Linux vendor (Redhat, Suse, etc) will supply kernels that are compatible with previous versions. That's their whole reason for existence; to make things like that smoother.
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
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.
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.
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.