===========================================================
== Subject:     LDAP Denial of Service (stack overflow) in
==              Samba AD DC
==
== CVE ID#:     CVE-2020-10704
==
== Versions:    All versions of Samba since Samba 4.0.0
==
== Summary:     A deeply nested filter in an un-authenticated
==              LDAP search can exhaust the LDAP server's stack
==              memory causing a SIGSEGV.
===========================================================

===========
Description
===========

LDAP is encoded as ASN.1, and LDAP filters are defined recursively as
   Filter ::= CHOICE {
                and             [0] SET OF Filter,
                or              [1] SET OF Filter,
                not             [2] Filter,
		
This recursion is mirrored in Samba's recursive decent parser, which
consumes around 600 bytes of stack per filter sent by the client.

In Samba, LDAP packets are parsed pre-authentication.

As an example on Linux x86_64, a LDAP search expression of (|(|(x=y)))
will consume over 1k of stack (600 bytes or so per OR).  Therefore,
even a fairly small, un-authenticated LDAP packet can cause the server
to fault with SIGSEGV as the stack reaches the OS-imposed limit (8MB
in this case).

If the network architecture allows a CLDAP packet (to UDP port 389) of
over 13,000 bytes (the maximum UDP packet size is 65,535) this
would also fit enough ASN.1 to crash the CLDAP server.

Samba 4.11 and later use the 'prefork' process model by default for
LDAP, and all versions use single process for CLDAP.

This shares one process between multiple network clients.  By crashing
one worker, legitimate service is disrupted to other clients.  The
process is restarted in all supported versions, but with a back-off.

NOTE WELL: Unsupported Samba versions before Samba 4.7 use a single
process for the (C)LDAP servers.  All versions of Samba before Samba
4.10 do not restart that process.

To address further concerns about resource use from LDAP packets, new
pre-parse limits are placed on LDAP searches (250k packet size limit),
all un-authenticated packets (250k packet size limit) other
authenticated packets (16MB) and CLDAP packets (4k).

* For authenticated connections the maximum packet size is controlled by
  the smb.conf parameter "ldap max authenticated request size"

* For anonymous connections the maximum packet size is controlled by
  the smb.conf parameter "ldap max anonymous request size"

* For searches, the maximum packet size is controlled by
  the smb.conf parameter "ldap max search request size"

==================
Patch Availability
==================

Patches addressing both these issues have been posted to:

    https://www.samba.org/samba/security/

Additionally, Samba 4.10.15, 4.11.8 and 4.12.2 have been issued
as security releases to correct the defect.  Samba administrators are
advised to upgrade to these releases or apply the patch as soon
as possible.

==================
CVSSv3 calculation
==================

CVSSv3.1: AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5)

================================
Workaround and mitigating factors
================================

By default, Samba 4.10 is run using the "standard" process model,
which would leave only the CLDAP server affected.  (Later versions use
'prefork').

This is controlled by the -M or --model parameter to the samba binary.

All Samba versions are impacted if -M prefork or -M single is used. To
mitigate this issue for LDAP only, select -M standard (however this
will use more memory, may allow resource exhaustion, and will still
leave the CLDAP server exposed).

=======
Credits
=======

Credit to oss-fuzz.

Triage of the oss-fuzz report and advisory written by Andrew Bartlett
of Catalyst and the Samba Team.

Patches provided by Gary Lockyer of Catalyst and the Samba Team.

==========================================================
== Our Code, Our Bugs, Our Responsibility.
== The Samba Team
==========================================================