Folks, can we please stop with the Badlock conspiracies? They are so far off base, I don't even know where to begin. With a little critical thought, you too can figure out that Metzmacher didn't create and then subsequently "discover" the vulnerability in SMB.
On Vulnerability Naming
In the infosec community in general, we dislike those who needlessly name vulnerabilities. But there's some value there too. Managers and decision makers remember names better than CVE numbers. When you factor in that Microsoft and other vendors use their own set of numbers to describe vulnerabilities (that already have CVE numbers) things get WAY more confusing.
Heartbleed and ShellShock probably deserved names - they were wide reaching vulnerabilities and needed media attention to ensure they were patched as quickly as possible. VENOM? Not so much. I struggled to find servers vulnerable to VENOM. And the pre-announcement publicity on that was a clown show getting people needlessly worried. GHOST? Don't even get me started. Just because it's a bug doesn't mean it's exploitable in the wild.
Does Badlock deserve a logo and a name? If it's as serious as Metzmacher makes it out to be, then maybe. But only maybe. Why maybe? The bug is in SMB. That makes it Windows and Samba specific. Sabma isn't embedded in nearly as many products as bash and it's not clear whether exploitation will require an esoteric option setting in Samba. If the result is Remote Code Execution (RCE) in all versions of Windows and Samba by default then it deserves a name. Otherwise, meh, it's primarily a Windows vulnerability.
On pre-disclosure announcements
Two words: douche move. I taught SEC760 for SANS in London a few weeks ago and we talked about vulnerability disclosure a little. At the time, I said that the two main types of disclosure were full disclosure and responsible disclosure. Metzmacher has officially added a third main type. I'm naming it douche disclosure.
What is douche dicslosure?
Douche disclosure occurs when you have coordinated a vulnerability disclosure with a vendor. The vendors agree on a patch release date. Then you, the researcher, begin talking about the vulnerability in the media weeks before the patch date. You get extra douche points for naming the vulnerability, creating a logo, and publicizing this. For maximum douche points, you ensure that the name of the vulnerability points other researchers to the location of the bug in the underlying protocol, weeks before patch release.
Back to "The Metzmacher Conspiracy"
I'll admit that Metzmacher is an easy guy to dislike. But the idea that he somehow introduced the bug - as suggested by some on Twitter - is ridiculous.
On Vulnerability Naming
In the infosec community in general, we dislike those who needlessly name vulnerabilities. But there's some value there too. Managers and decision makers remember names better than CVE numbers. When you factor in that Microsoft and other vendors use their own set of numbers to describe vulnerabilities (that already have CVE numbers) things get WAY more confusing.
Heartbleed and ShellShock probably deserved names - they were wide reaching vulnerabilities and needed media attention to ensure they were patched as quickly as possible. VENOM? Not so much. I struggled to find servers vulnerable to VENOM. And the pre-announcement publicity on that was a clown show getting people needlessly worried. GHOST? Don't even get me started. Just because it's a bug doesn't mean it's exploitable in the wild.
Does Badlock deserve a logo and a name? If it's as serious as Metzmacher makes it out to be, then maybe. But only maybe. Why maybe? The bug is in SMB. That makes it Windows and Samba specific. Sabma isn't embedded in nearly as many products as bash and it's not clear whether exploitation will require an esoteric option setting in Samba. If the result is Remote Code Execution (RCE) in all versions of Windows and Samba by default then it deserves a name. Otherwise, meh, it's primarily a Windows vulnerability.
On pre-disclosure announcements
Two words: douche move. I taught SEC760 for SANS in London a few weeks ago and we talked about vulnerability disclosure a little. At the time, I said that the two main types of disclosure were full disclosure and responsible disclosure. Metzmacher has officially added a third main type. I'm naming it douche disclosure.
What is douche dicslosure?
Douche disclosure occurs when you have coordinated a vulnerability disclosure with a vendor. The vendors agree on a patch release date. Then you, the researcher, begin talking about the vulnerability in the media weeks before the patch date. You get extra douche points for naming the vulnerability, creating a logo, and publicizing this. For maximum douche points, you ensure that the name of the vulnerability points other researchers to the location of the bug in the underlying protocol, weeks before patch release.
Back to "The Metzmacher Conspiracy"
I'll admit that Metzmacher is an easy guy to dislike. But the idea that he somehow introduced the bug - as suggested by some on Twitter - is ridiculous.
The thing people here need to remember is that Badlock reportedly also impacts Windows. Unless you are suggesting that MS is stealing code for SMB from the Samba project, then the vulnerability must have been introduced in Windows and ported to Samba. Not the other way around. Period.
The question then is this: knowing that the bug is out there, assuming that it is triggered through locks (possibly file locking?), and the patch is weeks away, can another attacker duplicate the vulnerability? I think so and I'm not alone.
Dave is a smart guy, but let's drop "if motivated" from his tweet. Attackers are of course motivated to discover this bug before the patch. If this is unauthenticated RCE over SMB, then this would be a seriously wormable vulnerability (like Conficker).
What should I do?
First and foremost, stop the hype. It's silly. When you are done speculating about what it might and might not be, think about your network segmentation. Early tweets on the vulnerability said everyone on the same LAN could have administrator privileges.
Don't allow SMB or NetBIOS where you don't need it. Layer 3 ACL's make a ton of sense here. So do client firewalls. Let's assume this will be written into a worm. If so, it's important that you block SMB leaving your network (TCP ports 135, 139, and 445 should all be blocked at your boundary firewall at a bare minimum).
What about private VLANs? We regularly recommend private VLANs to clients we work with at Rendition Infosec. While they can pose some initial configuration challenges in some environments, we find that those environments are usually poorly architected with workstations doing jobs much better suited to servers.
Finally, planning for the likelihood that this is more than hype, set aside some extra time to test and apply patches. Note, I said test. SMB runs in kernel space. A bad patch here will result in a blue screen. Period. Not a good place to be. Also, don't forget that you may have to patch more than once, especially if MS releases a rushed patch out of band because someone releases an exploit.
