Q & A
Is there a CVE for Badlock?
Yes. Badlock is referenced by CVE-2016-2118 (SAMR and LSA man in the middle attacks possible).
There are additional CVEs related to Badlock. Those are:
- CVE-2015-5370 (Multiple errors in DCE-RPC code)
- CVE-2016-2110 (Man in the middle attacks possible with NTLMSSP)
- CVE-2016-2111 (NETLOGON Spoofing Vulnerability)
- CVE-2016-2112 (LDAP client and server don’t enforce integrity)
- CVE-2016-2113 (Missing TLS certificate validation)
- CVE-2016-2114 ("server signing = mandatory" not enforced)
- CVE-2016-2115 (SMB IPC traffic is not integrity protected)
What can attackers gain?
The security vulnerabilities can be mostly categorised as man-in-the-middle or denial of service attacks.
- Man-in-the-middle (MITM) attacks:
There are several MITM attacks that can be performed against a variety of protocols used by Samba. These would permit execution of arbitrary Samba network calls using the context of the intercepted user.
Impact examples of intercepting administrator network traffic:
- Samba AD server – view or modify secrets within an AD database, including user password hashes, or shutdown critical services.
- standard Samba server – modify user permissions on files or directories.
- Denial-of-Service (DoS) attacks:
Samba services are vulnerable to a denial of service from an attacker with remote network connectivity to the Samba service.
Who is affected?
Affected versions of Samba are:
Earlier versions have not been assessed.
How can I fix my systems?
Please apply the patches provided by the Samba Team and SerNet for EnterpriseSAMBA / SAMBA+ immediately.
Patched versions are (both the interim and final security release have the patches):
- 4.2.10 / 4.2.11,
- 4.3.7 / 4.3.8,
- 4.4.1 / 4.4.2.
With the release of Samba 4.4.0 on March 22nd the 4.1 release branch has been marked DISCONTINUED (see Samba Release Planning ). Please be aware that Samba 4.1 and below are therefore out of support, even for security fixes. There will be no official security releases for Samba 4.1 and below published by the Samba Team or SerNet (for EnterpriseSAMBA). We strongly advise users to upgrade to a supported release.
Some vendors may choose to ship 4.4.1, 4.3.7, and 4.2.10 versions and add regression patches on top of them, due to wide scale and complexity of this release. Some may also just backport the patches to older releases. Please contact your Samba supplier for details.
What further improvements after patching are suggested?
- Mitigations for man-in-the-middle (MITM) attacks:
Network protections that could be used MITM attacks include DHCP snooping, ARP Inspection and 802.1x.
It is recommended that administrators set these additional options, if compatible with their network environment:
server signing = mandatory
ntlm auth = no
Without server signing = mandatory, Man in the Middle attacks are still possible against our file server and classic/NT4-like/Samba3 Domain controller. (It is now enforced on Samba’s AD DC.) Note that this has heavy impact on the file server performance, so you need to decide between performance and security. These man in the Middle attacks for smb file servers are well known for decades.
Without ‘ntlm auth = no’, there may still be clients not using NTLMv2, and these observed passwords may be brute-forced easily using cloud-computing resources or rainbow tables.
- Mitigations for denial-of-service (DoS) attack:
Apply firewall rules on the server to permit connectivity only from trusted addresses.
Will encryption protect against these attacks?
The SMB protocol, by default, only encrypts credentials and commands while files are transferred in plaintext. It is recommended that in security / privacy sensitive scenarios encryption is used to protect all communications.
Samba added encryption in version 3.2 in 2008, but only for Samba clients. Microsoft added SMB encryption support to SMB 3.0 in Windows 8 and Windows Server 2012. However, both of these types of encryption only protect communications, such a file transfers, after SMB negotiation and commands have been completed. It is this phase that contains the fixed vulnerabilities.
Samba/SMB encryption is good practice but is not sufficient for protection against these vulnerabilities. Network-level encryption, such as IPSec, is required for full protection as a workaround.
How bad is Badlock?
The severity of Badlock according to the Common Vulnerability Scoring System (CVSS):
CVSS:3.0/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H/E:P/RL:O/RC:CBase: 7.1 (High); Temporal: 6.4 (Medium)
Is this vulnerability exploited currently?
It may be possible since we already have several PoC (none of them will be released in the near future).
What does "Badlock" stand for?
"Badlock" was meant to be a rather generic name and does not point to any specifics.
Yet Another Bug With A Logo?
What branded bugs are able to achieve is best said with one word: Awareness. Furthermore names for bugs can serve as unique identifiers, other than different CVE/MS bug IDs.
It is a thin line between drawing attention to a severe vulnerability that should be taken seriously and overhyping it. This process didn’t start with the branding – it started a while ago with everyone working on fixes. The main goal of this announcement was to give a heads up. Vendors and distributors of Samba are being informed before a security fix is released in any case. This is part of any Samba security release process.
Who found the Badlock Bug?
Badlock was discovered by Stefan Metzmacher. He’s a member of the international Samba Core Team and works at SerNet on Samba. He reported the bug to Microsoft and has been working closely with them to fix the problem.
Where to find more information?
This page will get updates, check the samba.org page as well.
We are grateful to the Heartbleed team to use their template.
Last updated 2016-04-12 17:00 UCT.