12 April 2016

Samba 4.4.2, 4.3.8 and 4.2.11 Security Releases Available for Download

These are Security Releases in order to address CVE-2015-5370, CVE-2016-2110, CVE-2016-2111, CVE-2016-2112, CVE-2016-2113, CVE-2016-2114, CVE-2016-2115 and CVE-2016-2118.

Affected Versions: 3.6.x, 4.0.x, 4.1.x, 4.2.0-4.2.9, 4.3.0-4.3.6, 4.4.0 (earlier versions have not been assessed)

Patched Versions: 4.2.10 / 4.2.11, 4.3.7 / 4.3.8 and 4.4.1 / 4.4.2 (both the interim and final security release have the patches).

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.

Pre 4.2 versions have been discontinued (see Release Planning). Upgrading to a supported version is recommended. Some vendors have backported the patches to earlier versions.

Summary:

These releases fix multiple security vulnerabilities in the software and change the default behavior for some protocols.

The security vulnerabilities can be mostly categorised as man in the middle or denial of service attacks.

1. 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.

   To execute a man in the middle attack requires an attacker to manipulate network traffic in the local network segment of the client or server.

   Mitigations:

   Network protections that could be used MITM attacks include DHCP snooping, ARP Inspection and 802.1x.

   Suggested further improvements after patching:

   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.

2. Denial of Service (DoS)

   Samba services are vulnerable to a denial of service from an attacker with remote network connectivity to the Samba service.

   Mitigation:

   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.

New Options and Defaults:

The number of changes are rather huge for a security release, compared to typical security releases.

Given the number of problems and the fact that they are all related to man in the middle attacks we decided to fix them all at once instead of splitting them.

The security updates include new smb.conf options and a number of stricter behaviors to prevent man in the middle attacks on our network services, as a client and as a server.

Between these changes, compatibility with a large number of older software versions has been lost in the default configuration.

See the release notes for more information.

Here are some additional hints how to work around the new stricter default behaviors:

• As an AD DC server, only Windows 2000 and Samba 3.6 and above as a domain member are supported out of the box. Other smb file servers as domain members are also fine out of the box.

• As an AD DC server, with default setting of "ldap server require strong auth", LDAP clients connecting over ldaps:// or START_TLS will be allowed to perform simple LDAP bind only.

  The preferred configuration for LDAP clients is to use SASL GSSAPI directly over ldap:// without using ldaps:// or START_TLS.

  To use LDAP with START_TLS and SASL GSSAPI (either Kerberos or NTLMSSP) sign/seal protection must be used by the client and server should be configured with "ldap server require strong auth = allow_sasl_over_tls".

  Consult OpenLDAP documentation how to set sign/seal protection in ldap.conf.

  For SSSD client configured with "id_provider = ad" or "id_provider = ldap" with "auth_provider = krb5", see sssd-ldap(5) manual for details on TLS session handling.

• As a File Server, compatibility with the Linux Kernel cifs client depends on which configuration options are selected, please use "sec=krb5(i)" or "sec=ntlmssp(i)", not "sec=ntlmv2".

• As a file or printer client and as a domain member, out of the box compatibility with Samba less than 4.0 and other SMB/CIFS servers, depends on support for SMB signing or SMB2 on the server, which is often disabled or absent. You may need to adjust the "client ipc signing" to "no" in these cases.

• In case of an upgrade from versions before 4.2.0, you might run into problems as a domain member. The out of the box compatibility with Samba 3.x domain controllers requires NETLOGON features only available in Samba 3.2 and above.

  However, all of these can be worked around by setting smb.conf options in Samba, see WHATSNEW.txt the 4.2.0 release notes and the Samba wiki for details, workarounds and suggested security-improving changes to these and other software packages.

  You might run into a regression that will prevent users from trusted domains to be authenticated on a domain member server and related problems. You can indentify the bug by debug messages at log level 1 in log.wb-* similar to:

     Unwilling to make connection to domain OTHERDOMAIN without
     connection level security, must set "winbind sealed pipes = false"
     and "require strong key = false" to proceed: NT_STATUS_DOWNGRADE_DETECTED
  

  Note that there is a workaround by changing the configuration: The workaround consists in adding the following to the [global] section of the smb.conf on the domain member server. In the example you would have "workgroup = PRIMARYDOMAIN".

     winbind sealed pipes = false
     require strong key = false
     winbind sealed pipes:PRIMARYDOMAIN = true
     require strong key:PRIMARYDOMAIN = true
  

  For further information see https://bugzilla.samba.org/show_bug.cgi?id=11830

  Some vendors may already include a patch that changes the default values for these options. Typically if they upgraded from versions before 4.2.0.

Attention for Samba vendors:

If you represent an existing vendor that ships Samba in their products, consider registering with Samba Team. To do so, please send details about your product, security contact person list (with individual email addresses), and GPG key fingerprint to security@samba.org, from your official corporate email address. Please register with the Samba Bugzilla instance using the same email address(es).

Download:

The uncompressed tarballs have been signed using GnuPG (ID 6568B7EA).

The 4.4.2 source code can be downloaded now. There are two patches available to upgrade from Samba 4.4.0 via 4.4.1 to 4.4.2: patch from Samba 4.4.0 to 4.4.1 and patch from Samba 4.4.1 to 4.4.2. See the release notes for more info.

The 4.3.8 source code can be downloaded now. There are two patches available to upgrade from Samba 4.3.6 via 4.3.7 to 4.3.8: patch from Samba 4.3.6 to 4.3.7 and patch from Samba 4.3.7 to 4.3.8. See the release notes for more info.

The 4.2.11 source code can be downloaded now. There are two patches available to upgrade from Samba 4.2.9 via 4.2.10 to 4.2.11: patch from Samba 4.2.9 to 4.2.10 and patch from Samba 4.2.10 to 4.2.11. See the release notes for more info.