Critical Security Flaws in Samba Released on April 12, 2016

Samba is an open-source implementation of the Server Message Block (SMB) or Common Internet File System (CIFS) protocol, which allows PC-compatible machines to share files, printers, and other information. Several flaws have been discovered and fixed across all currently supported versions of Samba. For more information about the Badlock issue (CVE-2016-2118), refer to Knowledgebase article 2253041.

Affected versions:

CVE-2015-5370: Multiple flaws in DCE/RPC code

Multiple flaws were found in Samba's DCE/RPC protocol implementation. A remote, authenticated attacker could use these flaws to cause a denial of service against the Samba server (high CPU load or a crash) or, possibly, execute arbitrary code with the permissions of the user running Samba (root). This flaw could also be used to downgrade a secure DCE/RPC connection by a man-in-the-middle attacker taking control of an Active Directory (AD) object and compromising the security of a Samba Active Directory Domain Controller (DC).

Note: While Samba packages as shipped in Red Hat Enterprise Linux do not support running Samba as an AD DC, this flaw applies to all roles Samba implements.

CVE-2016-2118 (Badlock): SAMR and LSA man-in-the-middle attacks

Details about this flaw are available at: Badlock Security Flaw in Samba - CVE-2016-2118

CVE-2016-2110: Man-in-the-middle attacks possible with NTLMSSP

Several flaws were found in Samba's implementation of NTLMSSP authentication. An unauthenticated, man-in-the-middle attacker could use this flaw to clear the encryption and integrity flags of a connection, causing data to be transmitted in plain text. The attacker could also force the client or server into sending data in plain text even if encryption was explicitly requested for that connection.

LDAP (with NTLMSSP authentication) is used as a client by various administrative Samba project tools (for example, "net", "samba-tool", "ldbsearch", or "ldbedit").

These flaws affect all possible roles in which Samba can operate, and are related to CVE-2016-2112 and CVE-2016-2113.

CVE-2016-2111: NETLOGON Spoofing Vulnerability

It was discovered that Samba configured as a Domain Controller would establish a secure communication channel with a machine using a spoofed computer name. A remote attacker able to observe network traffic could use this flaw to obtain session-related information about the spoofed machine.

This flaw only affects Samba running as a classic primary DC, backup DC, or Active Directory DC.

This flaw is referred to as CVE-2015-0005 for Microsoft Windows Server.

The security advisory patch for this flaw introduces a new smb.conf option:

  raw NTLMv2 auth (G)

    This parameter determines whether or not smbd(8) allows SMB1 clients
    without extended security (without SPNEGO) to use NTLMv2 authentication.

    If this option, lanman auth, and ntlm auth are all disabled, only
    clients with SPNEGO support are permitted. That means NTLMv2 is only
    supported within NTLMSSP.

    Default: raw NTLMv2 auth = no

CVE-2016-2112: LDAP client and server do not enforce integrity protection

It was found that Samba's LDAP implementation did not enforce integrity protection for LDAP connections. A man-in-the-middle attacker could use this flaw to downgrade LDAP connections to use no integrity protection, allowing them to hijack such connections.

This flaw affects all possible roles Samba can operate in.

The security advisory patch for this flaw introduces a new smb.conf option:

  ldap server require strong auth (G)

    The "ldap server require strong auth" option defines whether the
    ldap server requires ldap traffic to be signed or
    signed and encrypted (sealed). Possible values are no,
    allow_sasl_over_tls and yes.

    A value of no allows simple and sasl binds over all transports.

    A value of allow_sasl_over_tls allows simple and sasl binds (without sign or seal)
    over TLS encrypted connections. Unencrypted connections only
    allow sasl binds with sign or seal.

    A value of yes allows only simple binds over TLS encrypted connections.
    Unencrypted connections only allow sasl binds with sign or seal.

    Default: ldap server require strong auth = yes

Note: The LDAP server does not have an option to enforce strong authentication yet. The security patches will introduce a new option called ldap server require strong auth, possible values of which are no, allow_sasl_over_tls and yes.

As the default behavior was set to no before, you may have to explicitly change this option until all clients have been adjusted to handle LDAP_STRONG_AUTH_REQUIRED errors. Windows clients and Samba member servers already use integrity protection.

CVE-2016-2113: Missing TLS/SSL certificate validation allows man-in-the-middle attacks

It was found that Samba did not validate SSL/TLS certificates in certain connections. A man-in-the-middle attacker could use this flaw to spoof a Samba server using a specially crafted SSL/TLS certificate.

This flaw affects all possible roles Samba can operate in.

The security advisory patch for this flaw introduces a new smb.conf option:

  tls verify peer (G)

    This controls if and how strict the client will verify the peer's
    certificate and name. Possible values are (in increasing order): no_check,
    ca_only, ca_and_name_if_available, ca_and_name and as_strict_as_possible.

    When set to no_check the certificate is not verified at all,
    which allows trivial man-in-the-middle attacks.

    When set to ca_only the certificate is verified that it is signed from a CA
    specified in the "tls ca file" option. Setting "tls ca file" to a valid file
    is required. The certificate lifetime is also verified. If the "tls crl file"
    option is configured, the certificate is also verified against
    the CA CRL.

    When set to ca_and_name_if_available all checks from ca_only are performed.
    In addition, the peer hostname is verified against the certificates
    name, if it is provided by the application layer and not given as
    an IP address string.

    When set to ca_and_name all checks from ca_and_name_if_available are performed.
    In addition the peer hostname needs to be provided and even an IP
    address is checked against the certificates name.

    When set to as_strict_as_possible all checks from ca_and_name are performed.
    In addition the "tls crl file" needs to be configured. Future versions
    of Samba may implement additional checks.

    Default: tls verify peer = as_strict_as_possible

CVE-2016-2114: "server signing = mandatory" not enforced

It was discovered that Samba did not enforce Server Message Block (SMB) signing for clients using the SMB1 protocol. A man-in-the-middle attacker could use this flaw to modify traffic between a client and a server.

This flaw affects the following server roles: standalone server, member server, classic primary DC, backup DC, and Active Directory DC.

Mitigation:

An explicit server signing = mandatory configuration option in the [global] section of the smb.conf file together with server min protocol = SMB2, should prevent connections without signing protection. However, this may cause older clients without support for SMB2 (or higher) to not be able to connect.

CVE-2016-2115: SMB client connections for IPC traffic are not integrity protected

It was found that Samba did not enable integrity protection for IPC traffic by default. A man-in-the-middle attacker could use this flaw to view and modify the data sent between a Samba server and a client.

The security advisory patch for this flaw introduces several new smb.conf options:

  client ipc signing (G)

    This controls whether the client is allowed or required to use
    SMB signing for IPC$ connections as DCE/RPC transport. Possible
    values are auto, mandatory and disabled.

    When set to mandatory or default, SMB signing is required.

    When set to auto, SMB signing is offered, but not enforced and
    if set to disabled, SMB signing is not offered either.

    Connections from winbindd to Active Directory Domain Controllers
    always enforce signing.

    Default: client ipc signing = default

  client ipc max protocol (G)

    The value of the parameter (a string) is the highest protocol level that will
    be supported for IPC$ connections as DCE/RPC transport.

    Normally this option should not be set as the automatic negotiation phase
    in the SMB protocol takes care of choosing the appropriate protocol.

    The value default refers to the latest supported protocol, currently SMB3_11.

    See client max protocol for a full list of available protocols.
    The values CORE, COREPLUS, LANMAN1, LANMAN2 are silently upgraded to NT1.
   Default: client ipc max protocol = default

    Example: client ipc max protocol = SMB2_10

  client ipc min protocol (G)

    This setting controls the minimum protocol version that the will be
    attempted to use for IPC$ connections as DCE/RPC transport.

    Normally this option does not need to be set as the automatic negotiation phase
    in the SMB protocol takes care of choosing the appropriate protocol.

    The value default refers to the higher value of NT1 and the
    effective value of "client min protocol".

    See client max protocol for a full list of available protocols.
    The values CORE, COREPLUS, LANMAN1, LANMAN2 are silently upgraded to NT1.

    Default: client ipc min protocol = default

    Example: client ipc min protocol = SMB3_11

Mitigation:

An explicit client signing = mandatory configuration option in the [global] section of the smb.conf file.

This flaw affects all possible roles Samba can operate in.