Badlock Bug(badlock.org)
badlock.org
Badlock Bug
http://badlock.org/
8 comments
is it just me or a lot more exploits are getting dedicated websites, names and press releases these days? It reminds me of the weather channel naming snow storms like hurricanes.
Heartbleed was the first one to do that: they gave it a suitably scary name, dedicated website, and logo. The result is that the media went wild over it, and people have been trying to replicate that reaction ever since.
And they didn't go wild over the next one because as far as anyone not involved in the technical end, nothing happened. It looked like everyone cried wolf.
Generating hype by marketing issues doesn't work.
Generating hype by marketing issues doesn't work.
If it got people to update, then it worked.
Except that there's some analogue of 'outrage fatigue' ('security fatigue'?). If the publicity is too successful in averting the problem, then there's a danger that, rather than correctly deducing "the loud publicity worked", some will deduce "the loud publicity is unnecessary"—and so future warnings will be ignored under the impression that they are 'crying wolf'.
Not a bad thing IMO. It brings more attention to security issues which is good for public awareness.
Also makes it easier for IT to pitch the downtime to execs if it's something the execs have heard of or can visit a website for with a simple description of the threat.
Also makes it easier for IT to pitch the downtime to execs if it's something the execs have heard of or can visit a website for with a simple description of the threat.
The problem is that it can generate vulerability fatigue, especially when some of the named vulns turn out not to actually be that serious.
After the first 10 or 20 people will see it as de rigeur and stop paying attention again...
After the first 10 or 20 people will see it as de rigeur and stop paying attention again...
Doesn't the law of diminishing returns start to kick in quickly? Correct me if I'm wrong but this exploit doesn't seem to be close to the potential impact as heartbleed.
Branding works
Can anyone explain to me the need to release the exploit information the same day as the patches?
Usually it's other way around: patches are released on the day of the disclosure.
Without firm date, companies have little to no incentive to fix the bug sooner (cough Adobe cough).
People would be able to reverse engineer the patches anyway.
Some people even managed to figure it out before the patches; doesn't mean we should expedite the release of exploits. Its gonna take more than a day for everyone to get patched.
It makes the "hair on fire" nature of critical security vulnerabilities unavoidable. It's much easier to sell an outage to management if you can more easily demonstrate that anyone could have this exploit (which is true regardless).
"Bad Lock" - maybe there's a clue
Yep, sounds like a clue to me.
"windows and samba" is a bigger clue. (See https://news.ycombinator.com/item?id=11337626 and/or the badlock website itself, first sentence...)
As I see it, there are a couple options here...
One: the bug is in the SMB protocol itself.
Two: the bug is in some library code that is common to both Windows and Samba.
(One and two could be the same thing, but they need not be.)
Either way, coupled with the 'badlock' hint, I will be watching for some bright/lucky soul to find it before 20160412.
"windows and samba" is a bigger clue. (See https://news.ycombinator.com/item?id=11337626 and/or the badlock website itself, first sentence...)
As I see it, there are a couple options here...
One: the bug is in the SMB protocol itself.
Two: the bug is in some library code that is common to both Windows and Samba.
(One and two could be the same thing, but they need not be.)
Either way, coupled with the 'badlock' hint, I will be watching for some bright/lucky soul to find it before 20160412.
No. As an admin I'd rather have the details so I can make sure even my non-standard, non-patchable, fleet is safe. (Where I might need to implement custom firewall rules to inspect data for bad patterns, etc.) Once my coworkers and I protected our ISP's customers against a worm at the external boundary. If we'd only had the patch and some sanitized information to work from that would have rattled around our system for months until we'd harassed every customer to update and would have caused tons of harm in the meantime.
I understand that in a make-believe scenario it'd be good to make sure bad-guys don't hear the info, but in a real-world scenario where you don't get to choose it's far better that the good guys have all the info even if a few more bad guys do to. And I say a few more because it's almost 100% certain that for every bug found there were attackers who knew about it beforehand.
Also, as others have mentioned, for anyone skilled a patch reads like a changelog. When I see security patches I often read the patched code or do a bindiff/disassemble and try to spot the issue and I'm only a hobbyist. We might as well level the field and give everyone the info, not just the reverse-engineers. (Who disproportionally are on the "other" side.)
I understand that in a make-believe scenario it'd be good to make sure bad-guys don't hear the info, but in a real-world scenario where you don't get to choose it's far better that the good guys have all the info even if a few more bad guys do to. And I say a few more because it's almost 100% certain that for every bug found there were attackers who knew about it beforehand.
Also, as others have mentioned, for anyone skilled a patch reads like a changelog. When I see security patches I often read the patched code or do a bindiff/disassemble and try to spot the issue and I'm only a hobbyist. We might as well level the field and give everyone the info, not just the reverse-engineers. (Who disproportionally are on the "other" side.)
Ok, that is scary enough. If Windows and Samba are both affected, it might be something to do with the SMB protocol itself. But is it also a critical issue if SMB is not accessible from the outside world (i.e. LAN only)?
According to a deleted tweet by someone in the know; everyone on the LAN would be able to get admin rights.
http://www.csoonline.com/article/3047221/techology-business/...
http://www.csoonline.com/article/3047221/techology-business/...
> But is it also a critical issue if SMB is not accessible from the outside world (i.e. LAN only)?
It can be. As we've seen with ransomware, it only takes a single user within the private network to expose everyone. If this somehow allowed a user to steal a token and elevate their permissions things like ransomware could become more effective/dangerous.
It can be. As we've seen with ransomware, it only takes a single user within the private network to expose everyone. If this somehow allowed a user to steal a token and elevate their permissions things like ransomware could become more effective/dangerous.
[deleted]
Is a CVE published yet?
No, although I'm sure they reserved a CVE number, although with a website and all - I think they're more riding on the hype rather than a CVE number.
Use the time you spend patching to ask yourself why you're using SMB/CIFS in 2016. Be really, really sure that's something you want to continue.
Once you've arrived at a decision, use the remaining time to write an angry letter to the IT community, demanding they stop using security disclosures as PR fodder.
Once you've arrived at a decision, use the remaining time to write an angry letter to the IT community, demanding they stop using security disclosures as PR fodder.
Windows' enterprise infrastructure relies heavily on CIFS. It isn't practical to operate a AD environment without it.
So the real question isn't even about CIFS, it is about AD and why that is so popular, and that boils down to maturity, vendor support, staff knowledge, and few alternatives (with Windows clients). Even Samba uses CIFS.
So if you have a working alternative to CIFS I'd like to read about it.
So the real question isn't even about CIFS, it is about AD and why that is so popular, and that boils down to maturity, vendor support, staff knowledge, and few alternatives (with Windows clients). Even Samba uses CIFS.
So if you have a working alternative to CIFS I'd like to read about it.
>Even Samba uses CIFS.
That caused my brain to skip for a moment. Since the entire point of Samba was to make it possible for *nix systems to interoperate with Windows systems there is no choice here. It is very possible that the people who work on Samba don't actually think that CIFS is a good idea.
That caused my brain to skip for a moment. Since the entire point of Samba was to make it possible for *nix systems to interoperate with Windows systems there is no choice here. It is very possible that the people who work on Samba don't actually think that CIFS is a good idea.
I dropped that in because if I didn't then someone would name Samba as an alternative. The statement is accurate, just redundant.
What does AD means?
Active Directory
Active Directory
https://en.wikipedia.org/wiki/Active_Directory
Windows' enterprise infrastructure relies heavily on CIFS.
I'm pretty sure the number of enterprises deploying CIFS is basically 0. It was last used for NT 4.0, and was superseded by SMB1 in windows 2000, SMB2 in Windows 2008, and SMB3 in Windows 2012[0].
[0] - https://blogs.technet.microsoft.com/josebda/2013/10/02/windo...
I'm pretty sure the number of enterprises deploying CIFS is basically 0. It was last used for NT 4.0, and was superseded by SMB1 in windows 2000, SMB2 in Windows 2008, and SMB3 in Windows 2012[0].
[0] - https://blogs.technet.microsoft.com/josebda/2013/10/02/windo...
If I had used "SMB" instead of "CIFS" someone would have criticised that too. Cannot win. There's a pedant around every corner waiting to pounce on inane detail.
If you have a point to make that actually contributes to the conversation I'd happily answer that. I won't address, beyond here, these petty corrections.
If you have a point to make that actually contributes to the conversation I'd happily answer that. I won't address, beyond here, these petty corrections.
criticised that too.
There is no criticism in my statement that CIFS is not likely deployed in any enterprise. Indeed, I had hoped that it would be an interesting fact for anyone not intimately familiar with SMB's history.
Cannot win.
Seems like you can't lose with an argument that is "Windows AD requires SMB", which is almost tautologically true. I (obviously) agree with that since it's clearly true. So since there is no reasonable "conversation" to be had about that, then what is the harm in providing some CIFS/SMB history since we're talking about it.
There is no criticism in my statement that CIFS is not likely deployed in any enterprise. Indeed, I had hoped that it would be an interesting fact for anyone not intimately familiar with SMB's history.
Cannot win.
Seems like you can't lose with an argument that is "Windows AD requires SMB", which is almost tautologically true. I (obviously) agree with that since it's clearly true. So since there is no reasonable "conversation" to be had about that, then what is the harm in providing some CIFS/SMB history since we're talking about it.
Be correct or go home.
potato potatoe, ssl tls, cifs smb... old names tend to stick around.
True enough. It seems weird since SMB has been in continuous use from about 1990-1992 until today (24-26 years), but CIFS was only in use from about 1996 to 2000, so about 4 years of CIFS and 22 years of SMB, or about 15% of SMB's lifetime. Whereas SSL was in use from 1995 to 2014/2015, almost a full 20 years, and about 95% of SSL/TLS's lifetime. So it's obvious why SSL is still used during the transition, but less so why CIFS, which was just small blip in SMB's history, is used.
I have plenty of working alternatives to CIFS; listing them isn't my point with the original post. Since Samba is explicitly a CIFS implementation, originally named after SMB, I think it's pretty obvious that "even Samba" would use CIFS.
The point is this is not the first time there have been protocol-level SNAFUs with this specific approach. Nowadays maturity, vendor support, and Windows clients are all available from lots of places (I don't know what "staff knowledge" means other than "we're used to this tool").
It's always worthwhile to spend time evaluating your infrastructure and investigating if there might be other solutions that have arisen. It's not a Windows-only world any more, even at the enterprise level, and active directory is no longer the unassailable fortress of big ops that it once was.
It's just a reminder to keep an open mind, that's all.
The point is this is not the first time there have been protocol-level SNAFUs with this specific approach. Nowadays maturity, vendor support, and Windows clients are all available from lots of places (I don't know what "staff knowledge" means other than "we're used to this tool").
It's always worthwhile to spend time evaluating your infrastructure and investigating if there might be other solutions that have arisen. It's not a Windows-only world any more, even at the enterprise level, and active directory is no longer the unassailable fortress of big ops that it once was.
It's just a reminder to keep an open mind, that's all.
> It's not a Windows-only world any more, even at the enterprise level, and active directory is no longer the unassailable fortress of big ops that it once was.
Then name the alternative.
Or tell us how to run AD without CIFS. If you cannot do either then your point about "evaluating your infrastructure" is a waste of time. You can evaluate it until you're blue in the face, but if there are no alternatives then there are no alternatives.
Heck just name a real alternative to GPO? A lot of people seem to think you can just slot in a Mac or Linux machine without any real grasp of how enterprise looks today. IBM are no doubt working on Linux deployment, but we're still likely years away, and Apple has focused more on iPads than Macs in the enterprise.
You don't want people using CIFS, but in 2016 that just isn't possible. It is mandatory for any AD environment and AD is more or less the only large scale enterprise solution. Therefore unless Microsoft redesign AD to use something other than CIFS, it isn't going away.
Then name the alternative.
Or tell us how to run AD without CIFS. If you cannot do either then your point about "evaluating your infrastructure" is a waste of time. You can evaluate it until you're blue in the face, but if there are no alternatives then there are no alternatives.
Heck just name a real alternative to GPO? A lot of people seem to think you can just slot in a Mac or Linux machine without any real grasp of how enterprise looks today. IBM are no doubt working on Linux deployment, but we're still likely years away, and Apple has focused more on iPads than Macs in the enterprise.
You don't want people using CIFS, but in 2016 that just isn't possible. It is mandatory for any AD environment and AD is more or less the only large scale enterprise solution. Therefore unless Microsoft redesign AD to use something other than CIFS, it isn't going away.
I'm not really interested in setting up a series of straw men for you to knock down. I'm not looking to get into an internet argument about minutiae.
Nowhere did I say "I don't want people using CIFS." I said it's worth deciding if CIFS is crucial to your business. This is always the case, for any technology, especially older, network-facing solutions that are basically propped up by lock-in and tradition. BIND is another great example of software that should provoke some introspection.
If you don't know anything or are unable to implement anything better than AD, then use AD. Meanwhile, AD is certainly not "the only large scale enterprise solution." I have hundreds of thousands of users and no AD, GPO, CIFS, or any other MSCE topic involved in my network. Please try not to take offense at this situation. I'm sorry that the mere suggestion of alternatives enrages you to this degree, but I'm not interested in this "prove it / no that won't work" meme.
Nowhere did I say "I don't want people using CIFS." I said it's worth deciding if CIFS is crucial to your business. This is always the case, for any technology, especially older, network-facing solutions that are basically propped up by lock-in and tradition. BIND is another great example of software that should provoke some introspection.
If you don't know anything or are unable to implement anything better than AD, then use AD. Meanwhile, AD is certainly not "the only large scale enterprise solution." I have hundreds of thousands of users and no AD, GPO, CIFS, or any other MSCE topic involved in my network. Please try not to take offense at this situation. I'm sorry that the mere suggestion of alternatives enrages you to this degree, but I'm not interested in this "prove it / no that won't work" meme.
> I'm not really interested in setting up a series of straw men for you to knock down. I'm not looking to get into an internet argument about minutiae.
This isn't minutiae. This is the core point of your entire post. You broadly criticise people for their continued use of CIFS and suggest people evaluate alternatives.
> I said it's worth deciding if CIFS is crucial to your business.
In enterprise, yes, it is crucial to businesses. There is no supported alternative.
> Meanwhile, AD is certainly not "the only large scale enterprise solution." I have hundreds of thousands of users and no AD, GPO, CIFS, or any other MSCE topic involved in my network.
Using what? I just asked you to tell us what the alternatives are. Even now you still haven't.
This isn't minutiae. This is the core point of your entire post. You broadly criticise people for their continued use of CIFS and suggest people evaluate alternatives.
> I said it's worth deciding if CIFS is crucial to your business.
In enterprise, yes, it is crucial to businesses. There is no supported alternative.
> Meanwhile, AD is certainly not "the only large scale enterprise solution." I have hundreds of thousands of users and no AD, GPO, CIFS, or any other MSCE topic involved in my network.
Using what? I just asked you to tell us what the alternatives are. Even now you still haven't.
Could you tell us a bit about the alternative you are using? Do you have Windows and Mac client machines?
I, for one, would be interested in a practical AD alternative.
I, for one, would be interested in a practical AD alternative.
> I have plenty of working alternatives to CIFS
Can you please list those? I have been working on CIFS for over 5years and haven't come across any alternative for CIFS in AD environment. Are you thinking of LDAP?
Pretend for a second you're on windows, and not the enterprise version. There's no native NFS. What do you do?
> ask yourself why you're using SMB/CIFS in 2016
Because the annoying WD NAS you have is incapable of doing NFS reliably.
Because the annoying WD NAS you have is incapable of doing NFS reliably.
And even if it did... most folks don't have the time or expertise to deploy a Kerberos realm to get encrypted NFS.
Remember that classic NFS uses IP addresses to manage access, with no concept of passwords. And all traffic is sent in cleartext.
(And that's also ignoring the fact you don't get NFS support on Windows 10 unless you're lucky enough to have access to the enterprise edition.)
Given the choice, I'd rather run SMB than non-Kerberized NFS.
Remember that classic NFS uses IP addresses to manage access, with no concept of passwords. And all traffic is sent in cleartext.
(And that's also ignoring the fact you don't get NFS support on Windows 10 unless you're lucky enough to have access to the enterprise edition.)
Given the choice, I'd rather run SMB than non-Kerberized NFS.
I have found that user permissions are a lot easier to sort out between mismatched users using SMB than NFS (which generally boils down to "chmod -R 777" in desperation)
What would you propose as a replacement in a mixed operating system environment?
NFSv4 has an unfortunate side effect in small workgroups where the local behavior of the filesystem is not congruent with the mounted share behavior as far as security ACLs are concerned.
NFSv4 has an unfortunate side effect in small workgroups where the local behavior of the filesystem is not congruent with the mounted share behavior as far as security ACLs are concerned.
....versus what? NFS? AFS? sshfs?
Is OSX affected?
Very well may be, at least for some people. SMB protocol (which "Samba" is named for) is the second standard option for file sharing in OS X after Apple's AFP.
I'm not sure if smb daemons are on all the time or not, but any Mac that has served files to a Windows machine may be affected.
I'm not sure if smb daemons are on all the time or not, but any Mac that has served files to a Windows machine may be affected.
SMB is the standard on recent versions of OSX, AFP is deprecated.
Apple did a ground up rewrite of their SMB services after SAMBA changed to GPLv3... so their code base is completely separate. Depending on the exact nature of the vulnerability, it's possible that OS X isn't vulnerable even though Windows and SAMBA (oddly) both are. Or it's possible that Apple didn't want to be part of the PR move ...
I predict there will be exploits within a week from now, now that they've told people where to look and given a clue with the name "Badlock".