Badlock Security flaw in Samba - CVE-2016-2118

Status
Resolved
Impact
Important
Red Hat Product Security has been made aware of a protocol flaw in the DCE/RPC-based SAMR and LSA protocols used in the Microsoft Windows Active Directory infrastructure. This issue has been assigned CVE-2016-2118 and is rated as Important. Other related vulnerabilities, ranging from Moderate to Critical and described in Critical Security Flaws in Samba Released on April 12 2016 , have also been made public.
Note: This is a protocol issue and affects all applications implementing this protocol, including Samba - CVE-2016-2118 , and Microsoft Windows - CVE-2016-0128.

Background Information

DCE/RPC is the specification for a remote procedure call mechanism that defines both APIs and an over-the-network protocol. The Security Account Manager (SAM) Remote Protocol (Client-to-Server) provides management functionality for an account store or directory containing users and groups. The protocol exposes the "account database" for both local and remote Microsoft Active Directory domains. The Local Security Authority (Domain Policy) Remote Protocol is used to manage various machine and domain security policies. This protocol, with minor exceptions, enables remote policy-management scenarios. Both SAMR and LSA protocols are based on the DCE 1.1 RPC protocol.
These protocols are typically available to all Windows installations, as well as every Samba server. They are used to maintain the Security Account Manager database. This applies to all roles (for example, standalone, domain controller, or domain member).

Acknowledgments

Red Hat would like to thank the Samba project for reporting this issue. Upstream acknowledges Stefan Metzmacher (SerNet) as the original reporter.

Impacted Products

This issue has been rated as having Important security impact by Red Hat Product Security. Other related vulnerabilities, ranging from Moderate to Critical and described in Critical Security Flaws in Samba Released on April 12 2016 , have also been made public. Additional information on Badlock can be found in Badlock: SAMR and LSA protocol man-in-the-middle attack against Samba (CVE-2016-2118) .

The following Red Hat Product versions are impacted:

  • Red Hat Enterprise Linux 4*
  • Red Hat Enterprise Linux 5
  • Red Hat Enterprise Linux 6
  • Red Hat Enterprise Linux 7
  • Red Hat Gluster Storage 3
All versions of Samba packages shipped with Red Hat Enterprise Linux server and Red Hat Gluster Storage are affected by this flaw.

*An active ELS subscription is required for access to this patch in RHEL 4. Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.

What is the Red Hat Enterprise Linux Extended Life Cycle Support Add-On (ELS)?

Attack Description and Impact

Any authenticated DCE/RPC connection that a client initiates against a server could be used by a man-in-the-middle attacker to impersonate the authenticated user against the SAMR or LSA service on the server. As a result, the attacker would be able to get read/write access to the Security Account Manager database, which could reveal all passwords and any other potentially sensitive information.
The client-chosen application protocol, authentication type (for example, Kerberos or NTLMSSP), and authentication level (NONE, CONNECT, SIGN, or SEAL) do not matter in this case. A man-in-the-middle attacker could downgrade the authentication level to CONNECT and take over the connection. The Badlock issue is fixed along with a series of CVEs as documented here:

Understanding Exposure

For customers using Samba as a domain member in AD environment:

  • How to detect: 'security = ads' in the smb.conf file
    • We recommend migrating to samba3x (3.6) on RHEL5 or migrating to RHEL6/samba (3.6), or migrating to RHEL7/samba (4.2)
    • Migration is not automatic, it needs to be planned, particularly around IDMAP as there were changes in 3.0 -> 3.6 and 3.6 -> 4.x

For customers using Samba as a domain member in NT environment:

  • How to detect: 'security = domain' in the smb.conf file
    • We recommend migrating to samba3x (3.6) on RHEL5 or migrating to RHEL6/samba (3.6), or migrating to RHEL7/samba (4.2)
    • Migration is not automatic, it needs to be planned, particularly around IDMAP as there were changes in 3.0 -> 3.6 and 3.6 -> 4.x

For customers using Samba as a file server:

  • How to detect: 'security = user' or 'security = ads' or 'security = domain', or 'security = standalone' and shares defined in the smb.conf file
    • We recommend migrating to samba3x (3.6) on RHEL5 or migrating to RHEL6/samba (3.6), or migrating to RHEL7/samba (4.2)
    • Migration is not automatic, it needs to be planned, particularly around IDMAP as there were changes in 3.0 -> 3.6 and 3.6 -> 4.x

Frequently Asked Questions

  1. I have updated my Samba servers and clients, do I need to restart anything?
    • No, when the update is applied on your system, the smb service will be restarted automatically.
  2. Do I need to patch both the Samba servers and Samba clients in my infrastructure?
    • At the very least, Samba servers should be updated. Because Badlock is a protocol flaw, both the servers and clients may be affected, depending on the configuration of the Samba infrastructure. Red Hat Product Security advises customers to update both servers and clients.
  3. Will the updated patches break my existing clients running older versions of Samba?
    • This security advisory tightens some of the security options used to configure Samba. This may break configurations when a Samba server is updated but the client is not. It is possible to roll back to older insecure options to continue interoperatibilty, (for example by setting allow dcerpc auth level connect = yes in the smb.conf file), but Red Hat Product Security highly recommends not to do so, since it re-introduces some of the attack vectors.
  4. My Samba server instances are not connected to any Windows Domains, am I still affected?
    • Yes, if an admin user communicates with a Samba server using a non-secure client, or uses a secure client to communicate to an insecure Samba server, a man-in-the-middle attacker could potentially use this to exploit this flaw.
  5. Will encryption protect me against this MITM attack?
    • The SMB protocol, by default, only encrypts credentials and commands while files are transferred in plain text. It is recommended that in security and privacy sensitive scenarios encryption is used to protect all communications. Encryption was added to Samba in version 3.2, 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 vulnerability highlighted above. Samba/SMB encryption is a good practice but is not sufficient for protection against this vulnerability.
  6. What version of Samba are fixed?
    • Red Hat is updating packages (samba, samba3x, samba4) for Samba versions 4.2, 4.1, 4.0, 3.6, & 3.0 across all currently supported products, including dependencies where required such as IPA, OpenChange, and libraries libtalloc, libtdb and libevent.

Affected Configurations

An Active Directory infrastructure with a Samba server as a domain member is vulnerable to this flaw. A man-in-the-middle attacker could intercept DCE/RPC traffic between the domain member and the domain controller to impersonate the client and get the same privileges as the authenticated user account.
Any Samba server configured as a file or print server is also vulnerable to this flaw.

Updates for Affected Products

Red Hat Enterprise Linux 4 - Extended Lifecycle Support* samba (v3.0) RHSA-2016:0625
Red Hat Enterprise Linux 5 samba (v3.0) RHSA-2016:0621
Red Hat Enterprise Linux 5 samba3x (v3.6) RHSA-2016:0613
Red Hat Enterprise Linux 5.6 Long Life samba (v3.0) RHSA-2016:0623
Red Hat Enterprise Linux 5.6 Long Life samba3x (v3.6) RHSA-2016:0624
Red Hat Enterprise Linux 5.9 Long Life samba (v3.0) RHSA-2016:0623
Red Hat Enterprise Linux 5.9 Long Life samba3x (v3.6) RHSA-2016:0624
Red Hat Enterprise Linux 6 samba (v3.6) RHSA-2016:0611
Red Hat Enterprise Linux 6 samba4 (v4.0) RHSA-2016:0612
Red Hat Enterprise Linux 6.2 Advanced Update Support** samba (v3.6) RHSA-2016:0619
Red Hat Enterprise Linux 6.2 Advanced Update Support** samba4 (v4.0) RHSA-2016:0620
Red Hat Enterprise Linux 6.4 Advanced Update Support** samba (v3.6) RHSA-2016:0619
Red Hat Enterprise Linux 6.4 Advanced Update Support** samba4 (v4.0) RHSA-2016:0620
Red Hat Enterprise Linux 6.5 Advanced Update Support** samba (v3.6) RHSA-2016:0619
Red Hat Enterprise Linux 6.5 Advanced Update Support** samba4 (v4.0) RHSA-2016:0620
Red Hat Enterprise Linux 6.6 Extended Update Support samba (v3.6) RHSA-2016:0619
Red Hat Enterprise Linux 6.6 Extended Update Support samba4 (v4.0) RHSA-2016:0620
Red Hat Enterprise Linux 7 samba (v4.2) RHSA-2016:0612
Red Hat Enterprise Linux 7.1 Extended Update Support samba (v4.1) RHSA-2016:0618
Red Hat Gluster Storage 3 (EL6) samba (v4.2) RHSA-2016:0614
Red Hat Gluster Storage 3 (EL7) samba (v4.2) RHSA-2016:0614

*An active ELS subscription is required for access to this patch in RHEL 4. Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.

What is the Red Hat Enterprise Linux Extended Life Cycle Support Add-On (ELS)?

**An active AUS subscription is required for access to this patch in RHEL 6.X AUS.

Mitigation

Risk can be reduced by not using privileged accounts to access SMB/CIFS services until a package containing a fix has been applied. Restrict administrative access to physical hardware (console, server), so that authentication does not involve any network communication.

Resolution

New smb.conf configuration option
This update introduces the following new smb.conf file configuration option:
allow dcerpc auth level connect (G)
This option controls whether DCE/RPC services can be used with DCERPC_AUTH_LEVEL_CONNECT, which provides authentication, but no per-message integrity (SIGN) nor privacy protection (SEAL).
Some interfaces like SAMR, LSARPC, and netlogon have a hardcoded default of no; epmapper, mgmt, and rpcecho have a hardcoded default of yes.
The behavior can be overwritten per interface name (for example, lsarpc, netlogon, samr, srvsvc, winreg, or wkssvc) by specifying 'allow dcerpc auth level connect:interface = yes'.
This option yields precedence to any implementation-specific restrictions. For example:
  • The drsuapi and backupkey protocols require DCERPC_AUTH_LEVEL_PRIVACY;
  • The dnsserver protocol requires DCERPC_AUTH_LEVEL_INTEGRITY.
Default: allow dcerpc auth level connect = no
Example: allow dcerpc auth level connect = yes

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In

19 Comments

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In

I noticed the updated packages are available from CentOS repos, but do not yet seem to be available in the rhel-6-server-rpms repo - when can we expect this to be available?

To clarify, I'm referring to RHEL6, using subscription manager as Zareh is.

Well, just unsubscribed and re-registered a server with RHN rather than continuing to wait for this to be resolved.

Updated packages for 6.7 are available that way now.

I can download the updates via RHN Classic, but not when subscribed through the subscription manager. This works fine for RHEL 6, but our RHEL 7 systems systems are still vulnerable. When will the update packages be available through the subscription manager. Are they available in a specific repo?

On RHEL7 did you run "yum makecache fast" before checking for the update. I've noticed RHEL7 often won't show you latest package in repositories because it is reading from the cache you got the last time you did an update. The makecache updates the cache so it is reading current info.

On checking just now:

yum list samba

Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager

Repodata is over 2 weeks old. Install yum-cron? Or run: yum makecache fast

Available Packages

samba.x86_64 4.2.3-11.el7_2 rhel-7-server-eus-rpms

I then ran "yum makecache fast" and reran and it shows newer package:

yum list samba

Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager

Available Packages

samba.x86_64 4.2.3-12.el7_2 rhel-7-server-eus-rpms

Will it be quicker for me to download and distribute the rpms manually, or wait for them to be in the RHEL repos?

I really hope Red Hat fixes the [known] CDN issue once and for all. Critical updates like these need to get distributed as soon as possible.

I am also running into an issue with RHEL 6.7 not showing the new samba packages as being available. I tried updating the cache using "yum makecache fast" but that did not solve the issue.

Also, just to clarify. It looks like this is only exploitable if the Samba instance is an AD domain member. Can someone please verify that?

Thanks!

What about RHEL4. I have redhat4 severs on Extended Life support, the badlock-test.sh does not check for RHEL4. I do know that on a couple of servers I have samba-client-3.0.28-0.el4.9 and the latest should be samba-client-3.0.33-3.37.el4.i386.rpm,

but all i found was samba-client-3.0.33-0.35.el4.i386.rpm did i overlook the rpm

Updated packages not yet present on access.redhat.com for those without a satellite configured (example libsmbclient-3.6.23-30).

Clarify: you need the full package name "libsmbclient-3.6.23-30.el6-7.x86_64" to get a package shown on the search function.

We started trying to download the rpm's yesterday morning (about 4 hours after the last notification from RH about this bug). Didn't work. Thought we had problems on our end, trying lots of things. Finally concluded there must be CDN problems or so. Opened a case at RedHat in the meantime and finally yesterday evening got this reply: "In case of bug like BadLock it can happen that the push of the rpms to the repositories can take a while and BadLock bug was discovered and fixed less than 24 hours ago." At least some notification about this would be nice...

I honnestly didn't get what excatly should be installed/updated -:(

I just listed the available samba packages and I got following:

[root@cq-xxxxx ~]# yum list samba Loaded plugins: product-id, refresh-packagekit, rhnplugin, security This system is receiving updates from RHN Classic or RHN Satellite. Installed Packages samba.x86_64 3.6.23-25.el6_7 @rhel-x86_64-server-6 Available Packages samba.x86_64 3.6.23-30.el6_7 rhel-x86_64-server-6

is this what should be installed or are there more packages to be installed/updated?

Latest samba package is not yet available in RHEL 6 Yum repository. It says 'No Packages marked for Update'. It is still showing old version 3.6.23-25 as only available version. Doesn't make any sense at all.

Yeah, last reply I got from support, about 3 hours ago: "Maybe the CDN still synchronizes the packages."

We are not using Samba services for anything (file server, AD authenitcation etc). I am not running any smb services on my Linux hosts; and in many of the hosts only client packages are installed.

Do we still need to upgrade the samba packages in this case as well?

As of now the patches still aren't available for the servers we pay for support for. The CentOS servers with no support have been patched for 24 hours. Given that RH thought this patch was important enough to send me an email directing me to this page, that seems incredibly irresponsible. It makes me question my decision to have support contracts on my servers.

The updates appear to break smbclient access - https://bugzilla.redhat.com/show_bug.cgi?id=1327216

We have a Windows 2008 server exporting folders to two of our RHEL 6 clients. We applied the badlock fix to the two RHEL 6 clients. We've found that after applying the fix occasionally the clients cannot access the exported folders and "mount -a" needs to be executed on the clients to re-establish access. Anyone else out there experiencing this?

I don't see RHEL4 test commands under badlock-test.sh. Is there anyway update the script and include RHEL4 servers also? We have ELS channels on our satellite servers and we need to validate and then if needed will remediate this security flaw.