history/samba-4.4.1.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml">
   4 <head>
   5 <title>Samba 4.4.1 - Release Notes</title>
   6 </head>
   7 <body>
   8 <H2>Samba 4.4.1 Available for Download</H2>
   9 <p>
  10 <a href="https://download.samba.org/pub/samba/stable/samba-4.4.1.tar.gz">Samba 4.4.1 (gzipped)</a><br>
  11 <a href="https://download.samba.org/pub/samba/stable/samba-4.4.1.tar.asc">Signature</a>
  12 </p>
  13 <p>
  14 <a href="https://download.samba.org/pub/samba/patches/samba-4.4.0-4.4.1.diffs.gz">Patch (gzipped) against Samba 4.4.0</a><br>
  15 <a href="https://download.samba.org/pub/samba/patches/samba-4.4.0-4.4.1.diffs.asc">Signature</a>
  16 </p>
  17 <p>
  18 <pre>
  19                    =============================
  20                    Release Notes for Samba 4.4.1
  21                            April 12, 2016
  22                    =============================
  23
  24
  25 This is a security release in order to address the following CVEs:
  26
  27 o  CVE-2015-5370 (Multiple errors in DCE-RPC code)
  28
  29 o  CVE-2016-2110 (Man in the middle attacks possible with NTLMSSP)
  30
  31 o  CVE-2016-2111 (NETLOGON Spoofing Vulnerability)
  32
  33 o  CVE-2016-2112 (LDAP client and server don&apos;t enforce integrity)
  34
  35 o  CVE-2016-2113 (Missing TLS certificate validation)
  36
  37 o  CVE-2016-2114 (&quot;server signing = mandatory&quot; not enforced)
  38
  39 o  CVE-2016-2115 (SMB IPC traffic is not integrity protected)
  40
  41 o  CVE-2016-2118 (SAMR and LSA man in the middle attacks possible)
  42
  43 The number of changes are rather huge for a security release,
  44 compared to typical security releases.
  45
  46 Given the number of problems and the fact that they are all related
  47 to man in the middle attacks we decided to fix them all at once
  48 instead of splitting them.
  49
  50 In order to prevent the man in the middle attacks it was required
  51 to change the (default) behavior for some protocols. Please see the
  52 &quot;New smb.conf options&quot; and &quot;Behavior changes&quot; sections below.
  53
  54 =======
  55 Details
  56 =======
  57
  58 o  CVE-2015-5370
  59
  60    Versions of Samba from 3.6.0 to 4.4.0 inclusive are vulnerable to
  61    denial of service attacks (crashes and high cpu consumption)
  62    in the DCE-RPC client and server implementations. In addition,
  63    errors in validation of the DCE-RPC packets can lead to a downgrade
  64    of a secure connection to an insecure one.
  65
  66    The above applies all possible server roles Samba can operate in.
  67
  68    Note that versions before 3.6.0 had completely different marshalling
  69    functions for the generic DCE-RPC layer. It&apos;s quite possible that
  70    that code has similar problems!
  71
  72    The downgrade of a secure connection to an insecure one may
  73    allow an attacker to take control of Active Directory object
  74    handles created on a connection created from an Administrator
  75    account and re-use them on the now non-privileged connection,
  76    compromising the security of the Samba AD-DC.
  77
  78 o  CVE-2016-2110:
  79
  80    There are several man in the middle attacks possible with
  81    NTLMSSP authentication.
  82
  83    E.g. NTLMSSP_NEGOTIATE_SIGN and NTLMSSP_NEGOTIATE_SEAL
  84    can be cleared by a man in the middle.
  85
  86    This was by protocol design in earlier Windows versions.
  87
  88    Windows Server 2003 RTM and Vista RTM introduced a way
  89    to protect against the trivial downgrade.
  90
  91    See MsvAvFlags and flag 0x00000002 in
  92    https://msdn.microsoft.com/en-us/library/cc236646.aspx
  93
  94    This new feature also implies support for a mechlistMIC
  95    when used within SPNEGO, which may prevent downgrades
  96    from other SPNEGO mechs, e.g. Kerberos, if sign or
  97    seal is finally negotiated.
  98
  99    The Samba implementation doesn&apos;t enforce the existence of
 100    required flags, which were requested by the application layer,
 101    e.g. LDAP or SMB1 encryption (via the unix extensions).
 102    As a result a man in the middle can take over the connection.
 103    It is also possible to misguide client and/or
 104    server to send unencrypted traffic even if encryption
 105    was explicitly requested.
 106
 107    LDAP (with NTLMSSP authentication) is used as a client
 108    by various admin tools of the Samba project,
 109    e.g. &quot;net&quot;, &quot;samba-tool&quot;, &quot;ldbsearch&quot;, &quot;ldbedit&quot;, ...
 110
 111    As an active directory member server LDAP is also used
 112    by the winbindd service when connecting to domain controllers.
 113
 114    Samba also offers an LDAP server when running as
 115    active directory domain controller.
 116
 117    The NTLMSSP authentication used by the SMB1 encryption
 118    is protected by smb signing, see CVE-2015-5296.
 119
 120 o  CVE-2016-2111:
 121
 122    It&apos;s basically the same as CVE-2015-0005 for Windows:
 123
 124      The NETLOGON service in Microsoft Windows Server 2003 SP2,
 125      Windows Server 2008 SP2 and R2 SP1, and Windows Server 2012 Gold
 126      and R2, when a Domain Controller is configured, allows remote
 127      attackers to spoof the computer name of a secure channel&apos;s
 128      endpoint, and obtain sensitive session information, by running a
 129      crafted application and leveraging the ability to sniff network
 130      traffic, aka &quot;NETLOGON Spoofing Vulnerability&quot;.
 131
 132    The vulnerability in Samba is worse as it doesn&apos;t require
 133    credentials of a computer account in the domain.
 134
 135    This only applies to Samba running as classic primary domain controller,
 136    classic backup domain controller or active directory domain controller.
 137
 138    The security patches introduce a new option called &quot;raw NTLMv2 auth&quot;
 139    (&quot;yes&quot; or &quot;no&quot;) for the [global] section in smb.conf.
 140    Samba (the smbd process) will reject client using raw NTLMv2
 141    without using NTLMSSP.
 142
 143    Note that this option also applies to Samba running as
 144    standalone server and member server.
 145
 146    You should also consider using &quot;lanman auth = no&quot; (which is already the default)
 147    and &quot;ntlm auth = no&quot;. Have a look at the smb.conf manpage for further details,
 148    as they might impact compatibility with older clients. These also
 149    apply for all server roles.
 150
 151 o  CVE-2016-2112:
 152
 153    Samba uses various LDAP client libraries, a builtin one and/or the system
 154    ldap libraries (typically openldap).
 155
 156    As active directory domain controller Samba also provides an LDAP server.
 157
 158    Samba takes care of doing SASL (GSS-SPNEGO) authentication with Kerberos or NTLMSSP
 159    for LDAP connections, including possible integrity (sign) and privacy (seal)
 160    protection.
 161
 162    Samba has support for an option called &quot;client ldap sasl wrapping&quot; since version
 163    3.2.0. Its default value has changed from &quot;plain&quot; to &quot;sign&quot; with version 4.2.0.
 164
 165    Tools using the builtin LDAP client library do not obey the
 166    &quot;client ldap sasl wrapping&quot; option. This applies to tools like:
 167    &quot;samba-tool&quot;, &quot;ldbsearch&quot;, &quot;ldbedit&quot; and more. Some of them have command line
 168    options like &quot;--sign&quot; and &quot;--encrypt&quot;. With the security update they will
 169    also obey the &quot;client ldap sasl wrapping&quot; option as default.
 170
 171    In all cases, even if explicitly request via &quot;client ldap sasl wrapping&quot;,
 172    &quot;--sign&quot; or &quot;--encrypt&quot;, the protection can be downgraded by a man in the
 173    middle.
 174
 175    The LDAP server doesn&apos;t have an option to enforce strong authentication
 176    yet. The security patches will introduce a new option called
 177    &quot;ldap server require strong auth&quot;, possible values are &quot;no&quot;,
 178    &quot;allow_sasl_over_tls&quot; and &quot;yes&quot;.
 179
 180    As the default behavior was as &quot;no&quot; before, you may
 181    have to explicitly change this option until all clients have
 182    been adjusted to handle LDAP_STRONG_AUTH_REQUIRED errors.
 183    Windows clients and Samba member servers already use
 184    integrity protection.
 185
 186 o  CVE-2016-2113:
 187
 188    Samba has support for TLS/SSL for some protocols:
 189    ldap and http, but currently certificates are not
 190    validated at all. While we have a &quot;tls cafile&quot; option,
 191    the configured certificate is not used to validate
 192    the server certificate.
 193
 194    This applies to ldaps:// connections triggered by tools like:
 195    &quot;ldbsearch&quot;, &quot;ldbedit&quot; and more. Note that it only applies
 196    to the ldb tools when they are built as part of Samba or with Samba
 197    extensions installed, which means the Samba builtin LDAP client library is
 198    used.
 199
 200    It also applies to dcerpc client connections using ncacn_http (with https://),
 201    which are only used by the openchange project. Support for ncacn_http
 202    was introduced in version 4.2.0.
 203
 204    The security patches will introduce a new option called
 205    &quot;tls verify peer&quot;. Possible values are &quot;no_check&quot;, &quot;ca_only&quot;,
 206    &quot;ca_and_name_if_available&quot;, &quot;ca_and_name&quot; and &quot;as_strict_as_possible&quot;.
 207
 208    If you use the self-signed certificates which are auto-generated
 209    by Samba, you won&apos;t have a crl file and need to explicitly
 210    set &quot;tls verify peer = ca_and_name&quot;.
 211
 212 o  CVE-2016-2114
 213
 214    Due to a regression introduced in Samba 4.0.0,
 215    an explicit &quot;server signing = mandatory&quot; in the [global] section
 216    of the smb.conf was not enforced for clients using the SMB1 protocol.
 217
 218    As a result it does not enforce smb signing and allows man in the middle attacks.
 219
 220    This problem applies to all possible server roles:
 221    standalone server, member server, classic primary domain controller,
 222    classic backup domain controller and active directory domain controller.
 223
 224    In addition, when Samba is configured with &quot;server role = active directory domain controller&quot;
 225    the effective default for the &quot;server signing&quot; option should be &quot;mandatory&quot;.
 226
 227    During the early development of Samba 4 we had a new experimental
 228    file server located under source4/smb_server. But before
 229    the final 4.0.0 release we switched back to the file server
 230    under source3/smbd.
 231
 232    But the logic for the correct default of &quot;server signing&quot; was not
 233    ported correctly ported.
 234
 235    Note that the default for server roles other than active directory domain
 236    controller, is &quot;off&quot; because of performance reasons.
 237
 238 o  CVE-2016-2115:
 239
 240    Samba has an option called &quot;client signing&quot;, this is turned off by default
 241    for performance reasons on file transfers.
 242
 243    This option is also used when using DCERPC with ncacn_np.
 244
 245    In order to get integrity protection for ipc related communication
 246    by default the &quot;client ipc signing&quot; option is introduced.
 247    The effective default for this new option is &quot;mandatory&quot;.
 248
 249    In order to be compatible with more SMB server implementations,
 250    the following additional options are introduced:
 251    &quot;client ipc min protocol&quot; (&quot;NT1&quot; by default) and
 252    &quot;client ipc max protocol&quot; (the highest support SMB2/3 dialect by default).
 253    These options overwrite the &quot;client min protocol&quot; and &quot;client max protocol&quot;
 254    options, because the default for &quot;client max protocol&quot; is still &quot;NT1&quot;.
 255    The reason for this is the fact that all SMB2/3 support SMB signing,
 256    while there are still SMB1 implementations which don&apos;t offer SMB signing
 257    by default (this includes Samba versions before 4.0.0).
 258
 259    Note that winbindd (in versions 4.2.0 and higher) enforces SMB signing
 260    against active directory domain controllers despite of the
 261    &quot;client signing&quot; and &quot;client ipc signing&quot; options.
 262
 263 o  CVE-2016-2118 (a.k.a. BADLOCK):
 264
 265    The Security Account Manager Remote Protocol [MS-SAMR] and the
 266    Local Security Authority (Domain Policy) Remote Protocol [MS-LSAD]
 267    are both vulnerable to man in the middle attacks. Both are application level
 268    protocols based on the generic DCE 1.1 Remote Procedure Call (DCERPC) protocol.
 269
 270    These protocols are typically available on all Windows installations
 271    as well as every Samba server. They are used to maintain
 272    the Security Account Manager Database. This applies to all
 273    roles, e.g. standalone, domain member, domain controller.
 274
 275    Any authenticated DCERPC connection a client initiates against a server
 276    can be used by a man in the middle to impersonate the authenticated user
 277    against the SAMR or LSAD service on the server.
 278
 279    The client chosen application protocol, auth type (e.g. Kerberos or NTLMSSP)
 280    and auth level (NONE, CONNECT, PKT_INTEGRITY, PKT_PRIVACY) do not matter
 281    in this case. A man in the middle can change auth level to CONNECT
 282    (which means authentication without message protection) and take over
 283    the connection.
 284
 285    As a result, a man in the middle is able to get read/write access to the
 286    Security Account Manager Database, which reveals all passwords
 287    and any other potential sensitive information.
 288
 289    Samba running as an active directory domain controller is additionally
 290    missing checks to enforce PKT_PRIVACY for the
 291    Directory Replication Service Remote Protocol [MS-DRSR] (drsuapi)
 292    and the BackupKey Remote Protocol [MS-BKRP] (backupkey).
 293    The Domain Name Service Server Management Protocol [MS-DNSP] (dnsserver)
 294    is not enforcing at least PKT_INTEGRITY.
 295
 296 ====================
 297 New smb.conf options
 298 ====================
 299
 300   allow dcerpc auth level connect (G)
 301
 302     This option controls whether DCERPC services are allowed to be used with
 303     DCERPC_AUTH_LEVEL_CONNECT, which provides authentication, but no per
 304     message integrity nor privacy protection.
 305
 306     Some interfaces like samr, lsarpc and netlogon have a hard-coded default
 307     of no and epmapper, mgmt and rpcecho have a hard-coded default of yes.
 308
 309     The behavior can be overwritten per interface name (e.g. lsarpc,
 310     netlogon, samr, srvsvc, winreg, wkssvc ...) by using
 311     &apos;allow dcerpc auth level connect:interface = yes&apos; as option.
 312
 313     This option yields precedence to the implementation specific restrictions.
 314     E.g. the drsuapi and backupkey protocols require DCERPC_AUTH_LEVEL_PRIVACY.
 315     The dnsserver protocol requires DCERPC_AUTH_LEVEL_INTEGRITY.
 316
 317     Default: allow dcerpc auth level connect = no
 318
 319     Example: allow dcerpc auth level connect = yes
 320
 321   client ipc signing (G)
 322
 323     This controls whether the client is allowed or required to use
 324     SMB signing for IPC$ connections as DCERPC transport. Possible
 325     values are auto, mandatory and disabled.
 326
 327     When set to mandatory or default, SMB signing is required.
 328
 329     When set to auto, SMB signing is offered, but not enforced and
 330     if set to disabled, SMB signing is not offered either.
 331
 332     Connections from winbindd to Active Directory Domain Controllers
 333     always enforce signing.
 334
 335     Default: client ipc signing = default
 336
 337   client ipc max protocol (G)
 338
 339     The value of the parameter (a string) is the highest protocol level that will
 340     be supported for IPC$ connections as DCERPC transport.
 341
 342     Normally this option should not be set as the automatic negotiation phase
 343     in the SMB protocol takes care of choosing the appropriate protocol.
 344
 345     The value default refers to the latest supported protocol, currently SMB3_11.
 346
 347     See client max protocol for a full list of available protocols.
 348     The values CORE, COREPLUS, LANMAN1, LANMAN2 are silently upgraded to NT1.
 349
 350     Default: client ipc max protocol = default
 351
 352     Example: client ipc max protocol = SMB2_10
 353
 354   client ipc min protocol (G)
 355
 356     This setting controls the minimum protocol version that the will be
 357     attempted to use for IPC$ connections as DCERPC transport.
 358
 359     Normally this option should not be set as the automatic negotiation phase
 360     in the SMB protocol takes care of choosing the appropriate protocol.
 361
 362     The value default refers to the higher value of NT1 and the
 363     effective value of &quot;client min protocol&quot;.
 364
 365     See client max protocol for a full list of available protocols.
 366     The values CORE, COREPLUS, LANMAN1, LANMAN2 are silently upgraded to NT1.
 367
 368     Default: client ipc min protocol = default
 369
 370     Example: client ipc min protocol = SMB3_11
 371
 372   ldap server require strong auth (G)
 373
 374     The ldap server require strong auth defines whether the
 375     ldap server requires ldap traffic to be signed or
 376     signed and encrypted (sealed). Possible values are no,
 377     allow_sasl_over_tls and yes.
 378
 379     A value of no allows simple and sasl binds over all transports.
 380
 381     A value of allow_sasl_over_tls allows simple and sasl binds (without sign or seal)
 382     over TLS encrypted connections. Unencrypted connections only
 383     allow sasl binds with sign or seal.
 384
 385     A value of yes allows only simple binds over TLS encrypted connections.
 386     Unencrypted connections only allow sasl binds with sign or seal.
 387
 388     Default: ldap server require strong auth = yes
 389
 390   raw NTLMv2 auth (G)
 391
 392     This parameter determines whether or not smbd(8) will allow SMB1 clients
 393     without extended security (without SPNEGO) to use NTLMv2 authentication.
 394
 395     If this option, lanman auth and ntlm auth are all disabled, then only
 396     clients with SPNEGO support will be permitted. That means NTLMv2 is only
 397     supported within NTLMSSP.
 398
 399     Default: raw NTLMv2 auth = no
 400
 401   tls verify peer (G)
 402
 403     This controls if and how strict the client will verify the peer&apos;s
 404     certificate and name. Possible values are (in increasing order): no_check,
 405     ca_only, ca_and_name_if_available, ca_and_name and as_strict_as_possible.
 406
 407     When set to no_check the certificate is not verified at all,
 408     which allows trivial man in the middle attacks.
 409
 410     When set to ca_only the certificate is verified to be signed from a ca
 411     specified in the &quot;tls ca file&quot; option. Setting &quot;tls ca file&quot; to a valid file
 412     is required. The certificate lifetime is also verified. If the &quot;tls crl file&quot;
 413     option is configured, the certificate is also verified against
 414     the ca crl.
 415
 416     When set to ca_and_name_if_available all checks from ca_only are performed.
 417     In addition, the peer hostname is verified against the certificate&apos;s
 418     name, if it is provided by the application layer and not given as
 419     an ip address string.
 420
 421     When set to ca_and_name all checks from ca_and_name_if_available are performed.
 422     In addition the peer hostname needs to be provided and even an ip
 423     address is checked against the certificate&apos;s name.
 424
 425     When set to as_strict_as_possible all checks from ca_and_name are performed.
 426     In addition the &quot;tls crl file&quot; needs to be configured. Future versions
 427     of Samba may implement additional checks.
 428
 429     Default: tls verify peer = as_strict_as_possible
 430
 431   tls priority (G) (backported from Samba 4.3 to Samba 4.2)
 432
 433     This option can be set to a string describing the TLS protocols to be
 434     supported in the parts of Samba that use GnuTLS, specifically the AD DC.
 435
 436     The default turns off SSLv3, as this protocol is no longer considered
 437     secure after CVE-2014-3566 (otherwise known as POODLE) impacted SSLv3 use
 438     in HTTPS applications.
 439
 440     The valid options are described in the GNUTLS Priority-Strings
 441     documentation at http://gnutls.org/manual/html_node/Priority-Strings.html
 442
 443     Default: tls priority = NORMAL:-VERS-SSL3.0
 444
 445 ================
 446 Behavior changes
 447 ================
 448
 449 o  The default auth level for authenticated binds has changed from
 450    DCERPC_AUTH_LEVEL_CONNECT to DCERPC_AUTH_LEVEL_INTEGRITY.
 451    That means ncacn_ip_tcp:server is now implicitly the same
 452    as ncacn_ip_tcp:server[sign] and offers a similar protection
 453    as ncacn_np:server, which relies on smb signing.
 454
 455 o  The following constraints are applied to SMB1 connections:
 456
 457    - &quot;client lanman auth = yes&quot; is now consistently
 458      required for authenticated connections using the
 459      SMB1 LANMAN2 dialect.
 460    - &quot;client ntlmv2 auth = yes&quot; and &quot;client use spnego = yes&quot;
 461      (both the default values), require extended security (SPNEGO)
 462      support from the server. That means NTLMv2 is only used within
 463      NTLMSSP.
 464
 465 o  Tools like &quot;samba-tool&quot;, &quot;ldbsearch&quot;, &quot;ldbedit&quot; and more obey the
 466    default of &quot;client ldap sasl wrapping = sign&quot;. Even with
 467    &quot;client ldap sasl wrapping = plain&quot; they will automatically upgrade
 468    to &quot;sign&quot; when getting LDAP_STRONG_AUTH_REQUIRED from the LDAP
 469    server.
 470
 471 Changes since 4.4.0:
 472 --------------------
 473
 474 o  Jeremy Allison &lt;jra@samba.org&gt;
 475    * Bug 11344 - CVE-2015-5370: Multiple errors in DCE-RPC code.
 476
 477 o  Christian Ambach &lt;ambi@samba.org&gt;
 478    * Bug 11804 - prerequisite backports for the security release on
 479      April 12th, 2016.
 480
 481 o  Ralph Boehme &lt;slow@samba.org&gt;
 482    * Bug 11644 - CVE-2016-2112: The LDAP client and server don&apos;t enforce
 483      integrity protection.
 484
 485 o  G&uuml;nther Deschner &lt;gd@samba.org&gt;
 486    * Bug 11749 - CVE-2016-2111: NETLOGON Spoofing Vulnerability.
 487
 488    * Bug 11804 - prerequisite backports for the security release on
 489      April 12th, 2016.
 490
 491 o  Volker Lendecke &lt;vl@samba.org&gt;
 492    * Bug 11804 - prerequisite backports for the security release on
 493      April 12th, 2016.
 494
 495 o  Stefan Metzmacher &lt;metze@samba.org&gt;
 496    * Bug 11344 - CVE-2015-5370: Multiple errors in DCE-RPC code.
 497
 498    * Bug 11616 - CVE-2016-2118: SAMR and LSA man in the middle attacks possible.
 499
 500    * Bug 11644 - CVE-2016-2112: The LDAP client and server doesn&apos;t enforce
 501      integrity protection.
 502
 503    * Bug 11687 - CVE-2016-2114: &quot;server signing = mandatory&quot; not enforced.
 504
 505    * Bug 11688 - CVE-2016-2110: Man in the middle attacks possible with NTLMSSP.
 506
 507    * Bug 11749 - CVE-2016-2111: NETLOGON Spoofing Vulnerability.
 508
 509    * Bug 11752 - CVE-2016-2113: Missing TLS certificate validation allows man in
 510      the middle attacks.
 511
 512    * Bug 11756 - CVE-2016-2115: SMB client connections for IPC traffic are not
 513      integrity protected.
 514
 515    * Bug 11804 - prerequisite backports for the security release on
 516      April 12th, 2016.
 517
 518
 519 </pre>
 520 </p>
 521 </body>
 522 </html>