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