The branch, master has been updated
       via  ef64cc0 NEWS[4.4.2]: Samba 4.4.2, 4.3.8 and 4.2.11 Security 
Releases Available for Download
       via  88454c6 NEWS[4.4.1]: Samba 4.4.1, 4.3.7 and 4.2.10 Security 
Releases Available for Download
       via  b7365eb style/2010/grey/screen.css: fix ol ul nesting
      from  bf2c180 support: Update Catalyst entry and add primary global 
offices

https://git.samba.org/?p=samba-web.git;a=shortlog;h=master


- Log -----------------------------------------------------------------
commit ef64cc0eba85eb294c40d9f54613817ab6b4f5cd
Author: Stefan Metzmacher <me...@samba.org>
Date:   Fri Apr 1 22:10:28 2016 +0200

    NEWS[4.4.2]: Samba 4.4.2, 4.3.8 and 4.2.11 Security Releases Available for 
Download
    
    Signed-off-by: Stefan Metzmacher <me...@samba.org>
    Signed-off-by: Andreas Schneider <a...@samba.org>
    Signed-off-by: Karolin Seeger <ksee...@samba.org>

commit 88454c6198a6f76812fc916f027b7e12b23bd9ba
Author: Karolin Seeger <ksee...@samba.org>
Date:   Fri Apr 1 22:10:28 2016 +0200

    NEWS[4.4.1]: Samba 4.4.1, 4.3.7 and 4.2.10 Security Releases Available for 
Download
    
    Signed-off-by: Karolin Seeger <ksee...@samba.org>

commit b7365ebd191643e60bd4b7f93051e156dd702571
Author: Stefan Metzmacher <me...@samba.org>
Date:   Tue Apr 12 13:58:42 2016 +0200

    style/2010/grey/screen.css: fix ol ul nesting
    
    Signed-off-by: Stefan Metzmacher <me...@samba.org>

-----------------------------------------------------------------------

Summary of changes:
 history/header_history.html                     |   6 +
 history/samba-4.2.10.html                       | 564 ++++++++++++++++++++++
 history/samba-4.2.11.html                       | 590 ++++++++++++++++++++++++
 history/samba-4.3.7.html                        | 533 +++++++++++++++++++++
 history/samba-4.3.8.html                        | 563 ++++++++++++++++++++++
 history/samba-4.4.1.html                        | 522 +++++++++++++++++++++
 history/samba-4.4.2.html                        | 552 ++++++++++++++++++++++
 history/security.html                           |  31 ++
 posted_news/20160412-185634.4.4.2.body.html     | 342 ++++++++++++++
 posted_news/20160412-185634.4.4.2.headline.html |   3 +
 posted_news/20160412-185634.4.4.2.snip.html     |  13 +
 security/CVE-2015-5370.html                     |  95 ++++
 security/CVE-2016-2110.html                     | 108 +++++
 security/CVE-2016-2111.html                     | 125 +++++
 security/CVE-2016-2112.html                     | 128 +++++
 security/CVE-2016-2113.html                     | 121 +++++
 security/CVE-2016-2114.html                     |  92 ++++
 security/CVE-2016-2115.html                     | 144 ++++++
 security/CVE-2016-2118.html                     | 148 ++++++
 style/2010/grey/screen.css                      |   4 +
 20 files changed, 4684 insertions(+)
 create mode 100755 history/samba-4.2.10.html
 create mode 100755 history/samba-4.2.11.html
 create mode 100644 history/samba-4.3.7.html
 create mode 100644 history/samba-4.3.8.html
 create mode 100644 history/samba-4.4.1.html
 create mode 100644 history/samba-4.4.2.html
 create mode 100644 posted_news/20160412-185634.4.4.2.body.html
 create mode 100644 posted_news/20160412-185634.4.4.2.headline.html
 create mode 100644 posted_news/20160412-185634.4.4.2.snip.html
 create mode 100644 security/CVE-2015-5370.html
 create mode 100644 security/CVE-2016-2110.html
 create mode 100644 security/CVE-2016-2111.html
 create mode 100644 security/CVE-2016-2112.html
 create mode 100644 security/CVE-2016-2113.html
 create mode 100644 security/CVE-2016-2114.html
 create mode 100644 security/CVE-2016-2115.html
 create mode 100644 security/CVE-2016-2118.html


Changeset truncated at 500 lines:

diff --git a/history/header_history.html b/history/header_history.html
index 6fe75a1..1c4cdd3 100755
--- a/history/header_history.html
+++ b/history/header_history.html
@@ -9,7 +9,11 @@
                <li><a href="/samba/history/">Release Notes</a>
                <li class="navSub">
                        <ul>
+                       <li><a href="samba-4.4.2.html">samba-4.4.2</a></li>
+                       <li><a href="samba-4.4.1.html">samba-4.4.1 (do not 
use)</a></li>
                        <li><a href="samba-4.4.0.html">samba-4.4.0</a></li>
+                       <li><a href="samba-4.3.8.html">samba-4.3.8</a></li>
+                       <li><a href="samba-4.3.7.html">samba-4.3.7 (do not 
use)</a></li>
                        <li><a href="samba-4.3.6.html">samba-4.3.6</a></li>
                        <li><a href="samba-4.3.5.html">samba-4.3.5</a></li>
                        <li><a href="samba-4.3.4.html">samba-4.3.4</a></li>
@@ -17,6 +21,8 @@
                        <li><a href="samba-4.3.2.html">samba-4.3.2</a></li>
                        <li><a href="samba-4.3.1.html">samba-4.3.1</a></li>
                        <li><a href="samba-4.3.0.html">samba-4.3.0</a></li>
+                       <li><a href="samba-4.2.11.html">samba-4.2.11</a></li>
+                       <li><a href="samba-4.2.10.html">samba-4.2.10 (do not 
use)</a></li>
                        <li><a href="samba-4.2.9.html">samba-4.2.9</a></li>
                        <li><a href="samba-4.2.8.html">samba-4.2.8</a></li>
                        <li><a href="samba-4.2.7.html">samba-4.2.7</a></li>
diff --git a/history/samba-4.2.10.html b/history/samba-4.2.10.html
new file mode 100755
index 0000000..5e2608e
--- /dev/null
+++ b/history/samba-4.2.10.html
@@ -0,0 +1,564 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
+<html xmlns="http://www.w3.org/1999/xhtml";>
+
+<head>
+<title>Samba - Release Notes Archive</title>
+</head>
+
+<body>
+
+   <H2>Samba 4.2.10 Available for Download</H2>
+
+<p>
+<pre>
+                   ==============================
+                   Release Notes for Samba 4.2.10
+                           April 12, 2016
+                   ==============================
+
+
+This is a security release in order to address the following CVEs:
+
+o  CVE-2015-5370 (Multiple errors in DCE-RPC code)
+
+o  CVE-2016-2110 (Man in the middle attacks possible with NTLMSSP)
+
+o  CVE-2016-2111 (NETLOGON Spoofing Vulnerability)
+
+o  CVE-2016-2112 (LDAP client and server don't enforce integrity)
+
+o  CVE-2016-2113 (Missing TLS certificate validation)
+
+o  CVE-2016-2114 ("server signing = mandatory" not enforced)
+
+o  CVE-2016-2115 (SMB IPC traffic is not integrity protected)
+
+o  CVE-2016-2118 (SAMR and LSA man in the middle attacks possible)
+
+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.
+
+In order to prevent the man in the middle attacks it was required
+to change the (default) behavior for some protocols. Please see the
+"New smb.conf options" and "Behavior changes" sections below.
+
+=======
+Details
+=======
+
+o  CVE-2015-5370
+
+   Versions of Samba from 3.6.0 to 4.4.0 inclusive are vulnerable to
+   denial of service attacks (crashes and high cpu consumption)
+   in the DCE-RPC client and server implementations. In addition,
+   errors in validation of the DCE-RPC packets can lead to a downgrade
+   of a secure connection to an insecure one.
+
+   The above applies all possible server roles Samba can operate in.
+
+   Note that versions before 3.6.0 had completely different marshalling
+   functions for the generic DCE-RPC layer. It's quite possible that
+   that code has similar problems!
+
+   The downgrade of a secure connection to an insecure one may
+   allow an attacker to take control of Active Directory object
+   handles created on a connection created from an Administrator
+   account and re-use them on the now non-privileged connection,
+   compromising the security of the Samba AD-DC.
+
+o  CVE-2016-2110:
+
+   There are several man in the middle attacks possible with
+   NTLMSSP authentication.
+
+   E.g. NTLMSSP_NEGOTIATE_SIGN and NTLMSSP_NEGOTIATE_SEAL
+   can be cleared by a man in the middle.
+
+   This was by protocol design in earlier Windows versions.
+
+   Windows Server 2003 RTM and Vista RTM introduced a way
+   to protect against the trivial downgrade.
+
+   See MsvAvFlags and flag 0x00000002 in
+   https://msdn.microsoft.com/en-us/library/cc236646.aspx
+
+   This new feature also implies support for a mechlistMIC
+   when used within SPNEGO, which may prevent downgrades
+   from other SPNEGO mechs, e.g. Kerberos, if sign or
+   seal is finally negotiated.
+
+   The Samba implementation doesn't enforce the existence of
+   required flags, which were requested by the application layer,
+   e.g. LDAP or SMB1 encryption (via the unix extensions).
+   As a result a man in the middle can take over the connection.
+   It is also possible to misguide client and/or
+   server to send unencrypted traffic even if encryption
+   was explicitly requested.
+
+   LDAP (with NTLMSSP authentication) is used as a client
+   by various admin tools of the Samba project,
+   e.g. "net", "samba-tool", "ldbsearch", "ldbedit", ...
+
+   As an active directory member server LDAP is also used
+   by the winbindd service when connecting to domain controllers.
+
+   Samba also offers an LDAP server when running as
+   active directory domain controller.
+
+   The NTLMSSP authentication used by the SMB1 encryption
+   is protected by smb signing, see CVE-2015-5296.
+
+o  CVE-2016-2111:
+
+   It's basically the same as CVE-2015-0005 for Windows:
+
+     The NETLOGON service in Microsoft Windows Server 2003 SP2,
+     Windows Server 2008 SP2 and R2 SP1, and Windows Server 2012 Gold
+     and R2, when a Domain Controller is configured, allows remote
+     attackers to spoof the computer name of a secure channel's
+     endpoint, and obtain sensitive session information, by running a
+     crafted application and leveraging the ability to sniff network
+     traffic, aka "NETLOGON Spoofing Vulnerability".
+
+   The vulnerability in Samba is worse as it doesn't require
+   credentials of a computer account in the domain.
+
+   This only applies to Samba running as classic primary domain controller,
+   classic backup domain controller or active directory domain controller.
+
+   The security patches introduce a new option called "raw NTLMv2 auth"
+   ("yes" or "no") for the [global] section in smb.conf.
+   Samba (the smbd process) will reject client using raw NTLMv2
+   without using NTLMSSP.
+
+   Note that this option also applies to Samba running as
+   standalone server and member server.
+
+   You should also consider using "lanman auth = no" (which is already the 
default)
+   and "ntlm auth = no". Have a look at the smb.conf manpage for further 
details,
+   as they might impact compatibility with older clients. These also
+   apply for all server roles.
+
+o  CVE-2016-2112:
+
+   Samba uses various LDAP client libraries, a builtin one and/or the system
+   ldap libraries (typically openldap).
+
+   As active directory domain controller Samba also provides an LDAP server.
+
+   Samba takes care of doing SASL (GSS-SPNEGO) authentication with Kerberos or 
NTLMSSP
+   for LDAP connections, including possible integrity (sign) and privacy (seal)
+   protection.
+
+   Samba has support for an option called "client ldap sasl wrapping" since 
version
+   3.2.0. Its default value has changed from "plain" to "sign" with version 
4.2.0.
+
+   Tools using the builtin LDAP client library do not obey the
+   "client ldap sasl wrapping" option. This applies to tools like:
+   "samba-tool", "ldbsearch", "ldbedit" and more. Some of them have command 
line
+   options like "--sign" and "--encrypt". With the security update they will
+   also obey the "client ldap sasl wrapping" option as default.
+
+   In all cases, even if explicitly request via "client ldap sasl wrapping",
+   "--sign" or "--encrypt", the protection can be downgraded by a man in the
+   middle.
+
+   The LDAP server doesn't have an option to enforce strong authentication
+   yet. The security patches will introduce a new option called
+   "ldap server require strong auth", possible values are "no",
+   "allow_sasl_over_tls" and "yes".
+
+   As the default behavior was as "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.
+
+o  CVE-2016-2113:
+
+   Samba has support for TLS/SSL for some protocols:
+   ldap and http, but currently certificates are not
+   validated at all. While we have a "tls cafile" option,
+   the configured certificate is not used to validate
+   the server certificate.
+
+   This applies to ldaps:// connections triggered by tools like:
+   "ldbsearch", "ldbedit" and more. Note that it only applies
+   to the ldb tools when they are built as part of Samba or with Samba
+   extensions installed, which means the Samba builtin LDAP client library is
+   used.
+
+   It also applies to dcerpc client connections using ncacn_http (with 
https://),
+   which are only used by the openchange project. Support for ncacn_http
+   was introduced in version 4.2.0.
+
+   The security patches will introduce a new option called
+   "tls verify peer". Possible values are "no_check", "ca_only",
+   "ca_and_name_if_available", "ca_and_name" and "as_strict_as_possible".
+
+   If you use the self-signed certificates which are auto-generated
+   by Samba, you won't have a crl file and need to explicitly
+   set "tls verify peer = ca_and_name".
+
+o  CVE-2016-2114
+
+   Due to a regression introduced in Samba 4.0.0,
+   an explicit "server signing = mandatory" in the [global] section
+   of the smb.conf was not enforced for clients using the SMB1 protocol.
+
+   As a result it does not enforce smb signing and allows man in the middle 
attacks.
+
+   This problem applies to all possible server roles:
+   standalone server, member server, classic primary domain controller,
+   classic backup domain controller and active directory domain controller.
+
+   In addition, when Samba is configured with "server role = active directory 
domain controller"
+   the effective default for the "server signing" option should be "mandatory".
+
+   During the early development of Samba 4 we had a new experimental
+   file server located under source4/smb_server. But before
+   the final 4.0.0 release we switched back to the file server
+   under source3/smbd.
+
+   But the logic for the correct default of "server signing" was not
+   ported correctly ported.
+
+   Note that the default for server roles other than active directory domain
+   controller, is "off" because of performance reasons.
+
+o  CVE-2016-2115:
+
+   Samba has an option called "client signing", this is turned off by default
+   for performance reasons on file transfers.
+
+   This option is also used when using DCERPC with ncacn_np.
+
+   In order to get integrity protection for ipc related communication
+   by default the "client ipc signing" option is introduced.
+   The effective default for this new option is "mandatory".
+
+   In order to be compatible with more SMB server implementations,
+   the following additional options are introduced:
+   "client ipc min protocol" ("NT1" by default) and
+   "client ipc max protocol" (the highest support SMB2/3 dialect by default).
+   These options overwrite the "client min protocol" and "client max protocol"
+   options, because the default for "client max protocol" is still "NT1".
+   The reason for this is the fact that all SMB2/3 support SMB signing,
+   while there are still SMB1 implementations which don't offer SMB signing
+   by default (this includes Samba versions before 4.0.0).
+
+   Note that winbindd (in versions 4.2.0 and higher) enforces SMB signing
+   against active directory domain controllers despite of the
+   "client signing" and "client ipc signing" options.
+
+o  CVE-2016-2118 (a.k.a. BADLOCK):
+
+   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 options
+====================
+
+  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
+
+  client ipc signing (G)
+
+    This controls whether the client is allowed or required to use
+    SMB signing for IPC$ connections as DCERPC 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 DCERPC 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 DCERPC 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 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
+
+  ldap server require strong auth (G)
+
+    The ldap server require strong auth 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
+
+  raw NTLMv2 auth (G)
+
+    This parameter determines whether or not smbd(8) will allow SMB1 clients
+    without extended security (without SPNEGO) to use NTLMv2 authentication.
+
+    If this option, lanman auth and ntlm auth are all disabled, then only
+    clients with SPNEGO support will be permitted. That means NTLMv2 is only
+    supported within NTLMSSP.
+
+    Default: raw NTLMv2 auth = no
+
+  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 to be 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 certificate's
+    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 certificate's 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
+
+  tls priority (G) (backported from Samba 4.3 to Samba 4.2)
+
+    This option can be set to a string describing the TLS protocols to be
+    supported in the parts of Samba that use GnuTLS, specifically the AD DC.
+
+    The default turns off SSLv3, as this protocol is no longer considered
+    secure after CVE-2014-3566 (otherwise known as POODLE) impacted SSLv3 use
+    in HTTPS applications.
+
+    The valid options are described in the GNUTLS Priority-Strings
+    documentation at http://gnutls.org/manual/html_node/Priority-Strings.html
+
+    Default: tls priority = NORMAL:-VERS-SSL3.0
+
+================
+Behavior changes
+================
+
+o  The default auth level for authenticated binds has changed from
+   DCERPC_AUTH_LEVEL_CONNECT to DCERPC_AUTH_LEVEL_INTEGRITY.
+   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.
+
+o  The following constraints are applied to SMB1 connections:
+
+   - "client lanman auth = yes" is now consistently
+     required for authenticated connections using the
+     SMB1 LANMAN2 dialect.
+   - "client ntlmv2 auth = yes" and "client use spnego = yes"
+     (both the default values), require extended security (SPNEGO)
+     support from the server. That means NTLMv2 is only used within
+     NTLMSSP.
+
+o  Tools like "samba-tool", "ldbsearch", "ldbedit" and more obey the
+   default of "client ldap sasl wrapping = sign". Even with
+   "client ldap sasl wrapping = plain" they will automatically upgrade
+   to "sign" when getting LDAP_STRONG_AUTH_REQUIRED from the LDAP
+   server.
+
+Changes since 4.2.9:
+--------------------
+


-- 
Samba Website Repository

Reply via email to