== Subject:     SAMR and LSA man in the middle attacks possible
== CVE ID#:     CVE-2016-2118 (a.k.a. BADLOCK)
== Versions:    Samba 3.6.0 to 4.4.0
== Summary:     A man in the middle can intercept any DCERPC
==              traffic between a client and a server in order to
==              impersonate the client and get the same privileges
==              as the authenticated user account. This is
==              most problematic against active directory
==              domain controllers.


The Security Account Manager Remote Protocol [MS-SAMR] and the
Local Security Authority (Domain Policy) Remote Protocol [MS-LSAD]
are both vulnerable to man in the middle attacks. Both are application level
protocols based on the generic DCE 1.1 Remote Procedure Call (DCERPC) protocol.

These protocols are typically available on all Windows installations
as well as every Samba server. They are used to maintain
the Security Account Manager Database. This applies to all
roles, e.g. standalone, domain member, domain controller.

Any authenticated DCERPC connection a client initiates against a server
can be used by a man in the middle to impersonate the authenticated user
against the SAMR or LSAD service on the server.

The client chosen application protocol, auth type (e.g. Kerberos or NTLMSSP)
and auth level (NONE, CONNECT, PKT_INTEGRITY, PKT_PRIVACY) do not matter
in this case. A man in the middle can change auth level to CONNECT
(which means authentication without message protection) and take over
the connection.

As a result, a man in the middle is able to get read/write access to the
Security Account Manager Database, which reveals all passwords
and any other potential sensitive information.

Samba running as an active directory domain controller is additionally
missing checks to enforce PKT_PRIVACY for the
Directory Replication Service Remote Protocol [MS-DRSR] (drsuapi)
and the BackupKey Remote Protocol [MS-BKRP] (backupkey).
The Domain Name Service Server Management Protocol [MS-DNSP] (dnsserver)
is not enforcing at least PKT_INTEGRITY.

New smb.conf option

  allow dcerpc auth level connect (G)

    This option controls whether DCERPC services are allowed to be used with
    DCERPC_AUTH_LEVEL_CONNECT, which provides authentication, but no per
    message integrity nor privacy protection.

    Some interfaces like samr, lsarpc and netlogon have a hard-coded default
    of no and epmapper, mgmt and rpcecho have a hard-coded default of yes.

    The behavior can be overwritten per interface name (e.g. lsarpc,
    netlogon, samr, srvsvc, winreg, wkssvc ...) by using
    'allow dcerpc auth level connect:interface = yes' as option.

    This option yields precedence to the implementation specific restrictions.
    E.g. 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

Binding string handling

  The default auth level for authenticated binds has changed from
  That means ncacn_ip_tcp:server is now implicitly the same
  as ncacn_ip_tcp:server[sign] and offers a similar protection
  as ncacn_np:server, which relies on smb signing.

Patch Availability

A patch addressing this defect has been posted to

Additionally, Samba 4.4.2, 4.3.8 and 4.2.11 have been issued as
security releases to correct the defect. Samba vendors and administrators
running affected versions are advised to upgrade or apply the patch as
soon as possible.

Note that Samba 4.4.1, 4.3.7 and 4.2.10 were privately released to vendors,
but had a regression, which is fixed in 4.4.2, 4.3.8 and 4.2.11.


You may lower risk by avoiding to login/authenticate with privileged accounts
over unprotected networks. Privileged accounts should only be used on the physical
console (server) console, so that authentication does not involve any network

If the machine is acting as client workstation you may restrict any incoming
network traffic by a firewall.

Vendor Specific Information

As this a multi-vendor problem we have decided to use one CVE number
per vendor:

* For Samba it is CVE-2016-2118 (this one).
* For Windows see CVE-2016-0128.


This vulnerability was discovered and researched by Stefan Metzmacher of
SerNet ( and the Samba Team (
He provides the fixes in collaboration with the Samba Team.