Bug 14556 (CVE-2020-25717) - CVE-2020-25717 [SECURITY] A user on the domain can become root on domain members
Summary: CVE-2020-25717 [SECURITY] A user on the domain can become root on domain members
Status: RESOLVED FIXED
Alias: CVE-2020-25717
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.13.0
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on: 14802 14646 14647 14799 14801
Blocks: 14725
  Show dependency treegraph
 
Reported: 2020-10-29 08:11 UTC by Andrew Bartlett
Modified: 2022-02-04 06:48 UTC (History)
18 users (show)

See Also:


Attachments
Current work in progress patches (75.80 KB, patch)
2021-10-11 21:44 UTC, Stefan Metzmacher
no flags Details
advisory text (v01) (4.85 KB, text/plain)
2021-11-03 03:49 UTC, Andrew Bartlett
no flags Details
advisory text (v02) (4.95 KB, text/plain)
2021-11-03 08:50 UTC, Andrew Bartlett
no flags Details
CVE-2020-25717-advisory-v3.txt (4.98 KB, text/plain)
2021-11-03 16:26 UTC, Stefan Metzmacher
no flags Details
Patches for v4-11-test (77.25 KB, patch)
2021-11-04 17:05 UTC, Samuel Cabrero
scabrero: review?
Details
Patches for v4-10-test (77.15 KB, patch)
2021-11-04 17:07 UTC, Samuel Cabrero
no flags Details
Patches for v4-9-test (77.24 KB, patch)
2021-11-04 17:08 UTC, Samuel Cabrero
no flags Details
Patches for v4-7-test (77.70 KB, patch)
2021-11-04 17:10 UTC, Samuel Cabrero
no flags Details
CVE-2020-25717-advisory-v4.txt (5.25 KB, text/plain)
2021-11-04 18:12 UTC, Jeremy Allison
metze: review-
Details
Patches for v4-6-test (58.49 KB, patch)
2021-11-05 08:23 UTC, Samuel Cabrero
no flags Details
Patches for v4-4-test (59.25 KB, patch)
2021-11-05 08:24 UTC, Samuel Cabrero
no flags Details
Patches for v3-6-test (wip) (3.89 KB, patch)
2021-11-05 17:46 UTC, Samuel Cabrero
no flags Details
CVE-2020-25717-advisory-v5.txt (6.76 KB, text/plain)
2021-11-08 21:45 UTC, Stefan Metzmacher
no flags Details
advisory v6.txt (6.81 KB, text/plain)
2021-11-08 22:22 UTC, Jeremy Allison
metze: review+
Details
Patches for v3-6-test (19.62 KB, patch)
2021-11-09 08:06 UTC, Samuel Cabrero
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Comment 3 Andrew Bartlett 2020-11-03 22:04:14 UTC
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N (8.1)

This is on the basis that an AD user can typically create machine accounts in AD without special privileges.
Comment 4 Andrew Bartlett 2021-02-19 20:16:19 UTC
We should require that for:

security=user: NO PAC with a LOGON_INFO is provided (to avoid use in AD domains)
security=ads: A PAC is required

David Mulder was working on some tests but ran into difficulties before Christmas trying to prove which user the session became using the audit logging framework.

I'm generally concerned about the poor alignment between the krb5 and NTLM codepaths, but we can track this separately in bug 14646.
Comment 5 Andrew Bartlett 2021-06-12 09:47:23 UTC
This, perhaps in conjunction with bug 14647 will need to be tested and fixed in combination with the much-loved (joke!) "winbind use default domain" smb.conf option to ensure we don't miss a case that is security relelvant.

Always going via the SID->UID resolution from the PAC, which would be made required, might be the safest way out, but this is a different path to the current code.
Comment 7 Andrew Bartlett 2021-08-18 10:30:57 UTC
Trying to tease out the different parts here: 

 - bug 14647 describes how samAccountName can be controlled by users who are not full domain admin
 - bug 14646 describes that NTLM and Kerberos authentication diverge, which may not be a problem or might be good to tidy up long term
 - bug 14799 describes that we should require the PAC in security=ads
 - bug 14801 describes trusting the 'untrustworthy' usernames less, given without using winbindd for NSS pure sid based mapping isn't possible.
 - bug 14802 remembers 'winbindd use default domain' so we don't forget.
Comment 8 Stefan Metzmacher 2021-10-11 21:41:38 UTC
(In reply to Andrew Bartlett from comment #6)

I'm working on fixes to solve this bug, so far we have the following:

1. Samuel implemented the new 'min domain uid' parameter,
   the logic is this in make_server_info_info3():

   + } else if ((lp_security() == SEC_ADS || lp_security() == SEC_DOMAIN) &&
   +       !is_myname(domain) && pwd->pw_uid < lp_min_domain_uid()) {
   +    /*
   +     * !is_myname(domain) because when smbd starts tries to setup
   +     * the guest user info, calling this function with nobody
   +     * username. Nobody is usually uid 65535 but it can be changed
   +     * to a regular user with 'guest account' parameter
   +     */
   +    nt_status = NT_STATUS_INVALID_TOKEN;
   +    DBG_NOTICE("Username '%s%s%s' is invalid on this system, "
   +               "it does not meet 'min domain uid' "
   +               "restriction (%u < %u): %s\n",
   +               nt_domain, lp_winbind_separator(), nt_username,
   +               pwd->pw_uid, lp_min_domain_uid(),
   +               nt_errstr(nt_status));
   +    goto out;

   I think we may want to skip this if we mapped the authentication to
   the guest user in order to simplify the logic for admins.


2. I changed the 'ktest' selftest environment to match the real
   world. This environment was designed in order to test kerberos
   against a member server (the MIT kerberos case without a KDC),
   so it makes use of precreated krb5 ccaches and a secrets.tdb.

   So far it didn't start winbindd and uses the 'username map'
   option in order to map the user to a local user account.

   But we officially require winbindd for member server setups
   quite a while now (I think starting with 4.8.0), so we should
   really test such a setup, so I'm now starting winbindd
   and configured it to use idmap_autorid and removed the 'username map'.
   The new setup is still able to accept the authentication with
   the precreated service tickets and no reachable DC.


3. I noticed that we do really ugly stuff in smb_getpwnam()
   called from make_server_info_info3() => check_account().
   While we always pass in userdomain+winbind_separator+useraccount
   and the desire to create non-existing accounts.
   Note that map_username() is called on from check_account()
   before calling calling smb_getpwnam().

   So what happens is that we first try to call
   getpwnam(userdomain+winbind_separator+useraccount),
   but if that fails we happily fallback to
   just getpwnam(useraccount), which seems very dangerous
   and seems to be part of the problem to gain 'root' from
   'DOMAIN\root'.

   But it gets worse as we then fallback to calling
   the 'add user script' for just 'useraccount' and
   then retry getpwnam(useraccount).

   So DOMAIN1\exampleuser, DOMAIN2\exampleuser,
   DOMAIN3\exampleuser, LOCALMACHINE\exampleuser
   may all get mapped to the same token of just
   a 'exampleuser' in /etc/password.

   In order to avoid that, I've changed to logic to
   a) only try getpwnam(useraccount) with strequal(domain, get_global_sam_name())
      (Note this does not apply to the ADDC case)
      Here we no longer try getpwnam(userdomain+winbind_separator+useraccount),
      is that ok?
   b) for all other cases we only try
      getpwnam(userdomain+winbind_separator+useraccount)
      without any fallback to getpwnam(useraccount)
   c) I changed check_account() to pass 'create=false' to
      smb_getpwnam() in order to remove the autocreation of
      local user accounts with the 'add user script'.

   Note it's still possible to map a domain user
   to a local account using 'username map' or 'username map script'.

   Can anyone think of setups we may break with these changes?


4. I removed the strange winbind autodetection from
   create_local_token(), we now only every call create_token_from_username(),
   if 'username map' or 'username map script' mapped the account before.

   And I think we could keep that for people who really want name
   based tokens, maybe using 'username map scipt = /bin/echo', but
   it's the admins own desire!

   Note the map_username() is always called after a successful authentication,
   both ntlmssp and kerberos, before constructing the final auth_session_info,
   with nt and unix token. For NTLMSSP map_username() is also called on the
   user supplied useraccount (without the domain part) before we pass it
   to the auth stack.

   So we no longer silently fallback to create_token_from_username()
   in the moment winbindd is temporary restarted!


5. I changed the default of 'gensec:require_pac' to 'yes',
   this is maybe also done in other patchsets of related ADDC bugs.

   After the big security release we'll always get a PAC in a kerberos
   ticket from AD DCs. Which means we can always rely on getting
   info3.base.account_name and info3.base.logon_domain, which simplifies
   the code a lot. E.g. ntlm_auth will only look at these!
   More details can be found further down...

   Special cases, which operate on an MIT realm, need to explicitly set
   'gensec:require_pac=no'. More related constraints are explained further down...

   For the ADDC we should replace auth_generate_session_info_principal()
   with NT_STATUS_NO_IMPERSONATION_TOKEN.

5. We already have a function called is_allowed_domain(), which
   checks the info3.base.logon_domain against 'winbind:ignore domains',
   I've extended that to also check the 'allow trusted domains' option
   in order to make things more consistent.


6. In order to consolidate the code paths used for NTLMSSP and Kerberos
   I checked what we were already doing for NTLMSSP, which is this:

   a) source3/auth/auth_winbind.c calls wbcAuthenticateUserEx()
   b) as a domain member we require a valid response from winbindd,
      otherwise we'll return NT_STATUS_NO_LOGON_SERVERS
   c) we call make_server_info_wbcAuthUserInfo(), which internally
      calls make_server_info_info3()
   d) auth_check_ntlm_password() calls
      smb_pam_accountcheck(unix_username, rhost), where rhost
      is only an ipv4 or ipv6 address (without reverse dns lookup)
   e) from auth3_check_password_send/auth3_check_password_recv()
      server_returned_info will be passed to auth3_generate_session_info(),
      triggered by gensec_session_info(), which means we'll call into
      create_local_token() in order to transform auth_serversupplied_info
      into auth_session_info.

   For Kerberos gensec_session_info() will call
   auth3_generate_session_info_pac() via the gensec_generate_session_info_pac()
   helper function. The current logic is this:

   a) gensec_generate_session_info_pac() is the function that
      evaluates the 'gensec:require_pac', which defaulted to 'no'
      before.
   b) auth3_generate_session_info_pac() called
      wbcAuthenticateUserEx() in order to pass the PAC blob
      to winbindd, but only to prime its cache, e.g. netsamlogon cache
      and others. Most failures were just ignored.
   c) If the PAC blob is available, it extracted the PAC_LOGON_INFO
      from it.
   d) Then we called the horrible get_user_from_kerberos_info() function:
      - It uses a first part of the tickets principal name (before the @)
        as username and combines that with the 'logon_info->base.logon_domain'
        if the logon_info (PAC) is present.
      - As a fallback without a PAC it's tries to ask winbindd for a mapping
        from realm to netbios domain name.
      - Finally is falls back to using the realm as netbios domain name
      With this information is builds 'userdomain+winbind_separator+useraccount'
      and calls map_username() followed by smb_getpwnam() with create=true,
      Note this is similar to the make_server_info_info3() => check_account()
      => smb_getpwnam() logic under 3.
      - It also calls smb_pam_accountcheck(), but may pass the reverse DNS lookup name
        instead of the ip address as rhost.
      - It does some MAP_TO_GUEST_ON_BAD_UID logic and auto creates the
        guest account.
   e) We called create_info3_from_pac_logon_info()
   f) make_session_info_krb5() calls gets called and triggers this:
      - If get_user_from_kerberos_info() mapped to guest, it calls
        make_server_info_guest()
      - If create_info3_from_pac_logon_info() created a info3 from logon_info,
        it calls make_server_info_info3()
      - Without a PAC it tries pdb_getsampwnam()/make_server_info_sam() with
        a fallback to make_server_info_pw()
      From there it calls create_local_token()

   I tried to change auth3_generate_session_info_pac() to behave similar
   to auth_winbind.c together with auth3_generate_session_info() as
   a domain member, as we now rely on a PAC:

   a) If there's a PAC we always call wbcAuthenticateUserEx() and require
      a valid response!
   b) we call make_server_info_wbcAuthUserInfo(), which internally
      calls make_server_info_info3(). Note make_server_info_info3()
      handles MAP_TO_GUEST_ON_BAD_UID and make_server_info_guest()
      internally.
   c) Similar to auth_check_ntlm_password() we now call
      smb_pam_accountcheck(unix_username, rhost), where rhost
      is only an ipv4 or ipv6 address (without reverse dns lookup)
   d) From there it calls create_local_token()


   If there's no PAC we only and we have 'gensec:require_pac=no'
   we continue with the already existing code logic:
   - Here we require ROLE_STANDALONE, all other cases result
     in an error. Is that ok or do we need to keep the old
     pac handling code for the FreeIPA case?
   - We just remove all code that made use of PAC generated info3
     structure, because that's exclusively handled by winbindd now.
   - I've changed smb_getpwnam() for the guest account to create=false
   - Do we need to keep smb_getpwnam() with create=true only
     in get_user_from_kerberos_info() or should we remove
     the 'add user script' logic from smb_getpwnam() completely?


7. This might be more related to the ADDC case, but during tests
   I found that winbind_SamLogon() leaves r->out.authoritative = false,
   by default, which means that we'll do a fallback from OTHERDOMAIN\administrator
   to LOCALSAM\administrator even for temporary failures!
   r->out.authoritative = false should only be returned if a DC is sure that
   OTHERDOMAIN is a non-existing domain! All other cases should use
   r->out.authoritative = true!


So the main changes are
- we require a PAC unless being in ROLE_STANDALONE
- smb_getpwnam doesn't fallback for domain users
- smb_getpwnam always strips the domain name for local users
- auth3_generate_session_info_pac() relies on wbcAuthenticateUserEx()
  if a PAC is available
- only 'username map [script]' triggers create_token_from_username()
- make_server_info_info3() checks for 'min domain uid'

Can anyone think of valid usecases which would break with these
changes.
Comment 9 Stefan Metzmacher 2021-10-11 21:44:04 UTC
Created attachment 16845 [details]
Current work in progress patches
Comment 10 nico 2021-10-11 22:05:08 UTC
It'd be nice to be able to map every possible SID to a UID _and_ GID on demand using a reserved chunk of the UID and GID namespace.  Solaris supports that.  ISTR asking Simo about reserving part of the Linux UID/GID namespace to avoid a conflict with Solaris.  I'm guessing that's out of the question for Linux, but if there's any way to make it configurable...

What we did in particular in Solaris to make this scale well was to make these mappings ephemeral: reboot and they're all gone.  To do this we had to make sure they don't leak in tarballs and such things, and we benefited in that regard from uid_t and gid_t having been signed in the past in Solaris, which meant that half their namespace was guaranteed unused when we implemented this feature.

In Linux uid_t and gid_t are unsigned, so making these mappings ephemeral is much much trickier and possibly impossible, but such mappings could still be done with an RPC service and a primary server.  Assigning chunks of UIDs/GIDs to SID prefix + RID namespace chunk of same size would make write operations infrequent, and they could be done asynchronously ahead of time before they are likely to be needed.

There is a bit of a DoS issue given that the SID namespace is huge while the UID/GID namespace is on the order of 32 bits.  So such on-demand mappings should be done only when the SID comes from a PAC, NETLOGON, or an LDAP or SAM lookup.

(Every SID can be used as a user SID and as a group/historical (so supplementary) SID.  E.g., SQL Server will run with an access token where the user SID is actually a group SID.  The Windows kernel doesn't know whether a SID is a user or group SID.  This is why every SID needs to be able to map to both, a UID _and_ a GID.)
Comment 11 Alexander Bokovoy 2021-10-12 05:25:42 UTC
From FreeIPA side:

FreeIPA sets up Samba on domain member with a read-only idmap backend. Allocating new SID to ID is not possible in this configuration and should not be required by design -- all allocation either is done by SSSD on the host using already pre-defined ID ranges in FreeIPA itself or by using ID overrides in FreeIPA configuration. In both cases these are global to the whole FreeIPA deployment and a domain member only follows the logic set by admins here.

It is not possible to set up Samba on a domain member in FreeIPA domain without Samba domain controller already set up on the IPA server. By the way how it is done, SIDs must be associated with users and groups that would attempt to access resources on Samba domain members.

FreeIPA KDC starts issuing PACs immediately when it detects that a principal has a SID associated. Combined with the above, this means that kerberos tickets without PAC are not accepted by Samba on a domain member: because if the user has no PAC, then it has no SID and no way to discover SID through Samba domain controller on IPA server as there would have been PAC in the ticket otherwise.

As a result, FreeIPA kind of enforces "user of Samba = SID exists and Kerberos ticket has PAC" policy already. I need to test a combined patchset against actual deployment, though.

Adding Sumit to comment on SSSD side for direct integration with AD case.
Comment 12 Ralph Böhme 2021-10-12 09:52:07 UTC
(In reply to Stefan Metzmacher from comment #8)
Sounds good to me! Thanks a lot for explaining this in detail.
Comment 14 Andrew Bartlett 2021-11-03 03:49:40 UTC
Created attachment 16924 [details]
advisory text (v01)
Comment 15 Andrew Bartlett 2021-11-03 03:51:11 UTC
Opening this issue to vendors
Comment 16 Andrew Bartlett 2021-11-03 08:50:11 UTC
Created attachment 16926 [details]
advisory text (v02)
Comment 17 Stefan Metzmacher 2021-11-03 16:26:20 UTC
Created attachment 16934 [details]
CVE-2020-25717-advisory-v3.txt

Filled in the summary as:

== Summary:     Samba may map domain users to local user
==              in an undesired way.


Removed reference to 'winbind use default domain'

winbind use default domain = yes can lookup "DOMAIN\user" just fine.
Comment 18 Jeremy Allison 2021-11-04 16:54:00 UTC
Comment on attachment 16934 [details]
CVE-2020-25717-advisory-v3.txt

Sorry metze, some minor wording fixes.

--------------------------------------------
"Windows Active Directory domains have, but default" should be:
"Windows Active Directory domains have, by default"

Note "but" -> "by".
--------------------------------------------
"This patch changes to Samba mean that Samba instead, as with NTLM
based logins, works based on the SID in the PAC. The SID which is
unique, non-repeating and so can't be confused."

The phrasing here is very awkard. Try:

"This patch changes Samba to use the SID in the PAC instead of the account name, as with NTLM based logins. The SID is unique, non-repeating and so can't be confused."
--------------------------------------------
Comment 19 Samuel Cabrero 2021-11-04 17:05:01 UTC
Created attachment 16952 [details]
Patches for v4-11-test
Comment 20 Samuel Cabrero 2021-11-04 17:07:42 UTC
Created attachment 16953 [details]
Patches for v4-10-test
Comment 21 Samuel Cabrero 2021-11-04 17:08:56 UTC
Created attachment 16954 [details]
Patches for v4-9-test
Comment 22 Stefan Metzmacher 2021-11-04 17:10:12 UTC
(In reply to Jeremy Allison from comment #18)

Thanks Jeremy, can you please upload a CVE-2020-25717-advisory-v4.txt?
Comment 23 Samuel Cabrero 2021-11-04 17:10:22 UTC
Created attachment 16955 [details]
Patches for v4-7-test
Comment 24 Jeremy Allison 2021-11-04 18:12:23 UTC
Created attachment 16956 [details]
CVE-2020-25717-advisory-v4.txt

Updated with clarified advisory text. Metze please take a look. Thanks !
Comment 25 Samuel Cabrero 2021-11-05 08:23:11 UTC
Created attachment 16958 [details]
Patches for v4-6-test
Comment 26 Samuel Cabrero 2021-11-05 08:24:37 UTC
Created attachment 16959 [details]
Patches for v4-4-test
Comment 27 Stefan Metzmacher 2021-11-05 14:47:11 UTC
Comment on attachment 16956 [details]
CVE-2020-25717-advisory-v4.txt

We'll need to expand the advisory to be more verbose about the
functional changes provided by the patches.

I'll try to do that on Monday.

Here are some hints for me:

The key is if "getent passwd 'LOGONDOMAIN-FROM-PAC\ACCOUNTNAME-FROM-PAC'" works
or not. If it is not working and the setup is relying on the fallback to
just "getent passwd 'ACCOUNTNAME-FROM-PAC'", you'll have a problem if
ACCOUNTNAME-FROM-PAC would be 'root'.

The security patches remove the fallback that removes the 
'LOGONDOMAIN-FROM-PAC\' part. If the funtionality is needed
'username map' or 'username map script' should be used in order to
map 'LOGONDOMAIN-FROM-PAC\ACCOUNTNAME-FROM-PAC' to 'ACCOUNTNAME-FROM-PAC'
explicitly.
Comment 28 Samuel Cabrero 2021-11-05 17:46:13 UTC
Created attachment 16963 [details]
Patches for v3-6-test (wip)
Comment 29 Stefan Metzmacher 2021-11-08 21:45:56 UTC
Created attachment 16969 [details]
CVE-2020-25717-advisory-v5.txt

We also use the name from the PAC.

This explain the removed fallback from 'DOMAIN\user' to 'user'
and was to do explicit mapping using 'username map [script]'

I also added two additional mitigations:

1. The use of the 'invalid users' option, note this
   needs to be specified in the [global] section,
   as well as every share with an existing 'invalid users' option, e.g.:

   invalid users = root, ubuntu

2. The usage of the "obey pam restrictions = yes" together with
   something like 'account required pam_succeed_if.so quiet uid >= 1000' in
   the pam configuration for "samba", please consult 'man 8 pam_succeed_if'.

Please have a look at the full document and upload a fixed version if additional
changes are required.

Thanks!
Comment 30 Jeremy Allison 2021-11-08 22:22:13 UTC
Created attachment 16970 [details]
advisory v6.txt

Slight tidyup of language in new section.
Comment 31 Stefan Metzmacher 2021-11-08 23:18:33 UTC
Comment on attachment 16970 [details]
advisory v6.txt

Thanks!
Comment 32 Samuel Cabrero 2021-11-09 08:06:42 UTC
Created attachment 16978 [details]
Patches for v3-6-test
Comment 33 Samba QA Contact 2021-11-09 18:11:51 UTC
This bug was referenced in samba v4-15-stable (Release samba-4.15.2):

af86793af77ab0dfe1c0a9740820c52b435d993d
e44195b765a4029909fc7132928f1ec971d8727d
56ace59efee73988bfd6b25161fa70cfc1956c82
ff062e2b0ae4063fb807ddfe2fa172bae0d2eec5
eddf0a5c6fa06cc6348217ae339b7fb9ef88b80d
25d2174dd1bce0ef8e984db6223339c2e8862389
2d5d5a39b0d89b98dc466f3561721f9d4dbbeb1b
c955376e02c74208c47d474a08e8ebb9308e319c
3657c79eb2dbfc6bc6b6157881edefe0fe0f1b56
c55de3995cf49812b24d4c2fc6e14c5c609db46c
dd88bd9f273dcb49d80d226df457aa05df232237
ae21152809414e96c209f708ba9a737d9dc16e8b
a65cd59b200ec6570cca7f2ab2238f6221bda602
c1bf56f314667ee3c5399576a45b74346d4c7f2e
a92da791615cd42ce28c679aba1c18a1ef2b5eb8
210b3e36f76d7251714aa48af2319496b907db11
1ec930b2f584ef012cd84d3d7ae265719de1b878
325942e4e78cccac5456a831375b881d5f80b4c0
e40a1d46831be8b6125b76b511bb24582e8a13e9
651b74b12b9d995f442fd02e90ca0a1ce12d4a52
39b060eeea6d364c7b7b575fda7a6877ce6e2a9a
58a1cc488ce20f7cd3c9013e9b8ec3163a25075e
3efb9d684d957f0e08c4fd537b0916b02cb73ceb
e4172baf12205881098e42e502b0fc8d961e6601
7b9920b382ac57b045e46fa113a9c4a9da782b68
093c5502ab41f068dbc222854caf9cca14d4c157
fb5ca61f54412dcf24c4f20dd1dd4639838fbfab
9cb158a9a53de11a7f0959d30be28b9f09b41469
558cd30acc6f6fff2356fe755cba65de7b3a6603
1d126e4fd9a6895b4d4b69efbf9f1791aa955f96
67ef2899a7d5164b9788996ad86402722dcd2564
c513478908c19b3c9112a9d3d195a67931d6146c
255e5c14061ca65c135959046a26418321d80092
Comment 34 Samba QA Contact 2021-11-09 18:16:01 UTC
This bug was referenced in samba v4-14-stable (Release samba-4.14.10):

6dbc3f11c0212081ab25a40f46f007252fc7510e
93289e90d6f4f9ef8b0dd85411602a7f5cb23b93
44270951af60c8860a64e35654e82bd4479433f8
5a5b1a06d6de8d1ffb4b1db4a7f575d8b1c168c2
16098012df9dcd9561582982d078e89ff6f42f34
849ef477cb35e125ee7c0f4060cda766a8a8e376
e0ae20193e3c8b486586faa5f486789ad6ee94fb
3815c92cc87c256c212d713c50ae5629ecf9c69f
d92787c05a02153742062a6caf3c754961ec527c
e31b6f6094403d1186835af4e8385e988c19a4e5
f111e42082ac0a9f4e9d77e908cbb894ba5748b4
cc26ffe58666db3651be9f3670e9c972b4322a0b
1e84bcbe4cbe2edfc340badd810c49f90d398609
68e093683c7ad222e9df3d77c56cfa33df29455a
6b2ea12fe470db27396d6cf3656e53ef76cc8f96
f9e3774dbf01a06d411150208135c2c6941c9815
c01d19f7f99e1c3eb678da81164665eca4ebe985
0420b616035ca3fd88a3ba473002bc604b91d181
bfd89cdbaa4cb90b487b054cc8a036267546151b
a5e515b9637686095f1e3a9a9faf2cd978558fa4
4414546589bb589df129faa77fce91f9758a5b43
76859f7926c1498d2c5be73cdca910b0d7381f82
adb6620043d4113a350ea24369f00246ea6410d4
e43275fc182c6bc39faf71ac4c007c71013b4748
7ca428223f522bd959be8e564432afcf5ea37ed8
a624a73ce46bbca579411a26581394ea72ae9d09
39c834af93813c736d002a0669fdf01dfc2e5241
8aeac144220949bb4a9c2fb5aacfead6133f9ed9
c3c49ceeb7991f9851e616a901e2f601ff796c3e
6280d99de7d0f761842a5ab37a6253aefa237344
9c66eacf637bc25e7720ba0d2b2f9763639f6e8c
cc1c47f1679b85c8860b2ee05c3f45b7b667ccef
c219b832d96b582aa5b81f0cec31ab432d6469e4
151b6145e1c0cb360b088dfc4e41982854fc2c9d
f2aafe556290e9944cc03146084e8f3991fcd06b
3cceba46aa5e93d65d529f4ec76fa19fe17244c6
e5f10558e0861fe16eee40485c5b520b039f0d24
d5b302e674f2ba2435339e1f6a6104780c63be9a
182db923a1d19db41cfb39b98d344cc350c301cd
cf3de54d6d64f63e76e9fd7920a37146809035ad
da61668c8a0c4772e2d7a725f1598d7aa3c92009
af11f643f5072bc4c70461e9d20a0ea2cc8ca6d3
Comment 35 Samba QA Contact 2021-11-09 18:17:40 UTC
This bug was referenced in samba v4-13-stable (Release samba-4.13.14):

05b27742da44524e6007631a401dfef0b7180d53
0792d340860a44ccfb98b231e2518db751a98a59
340e2153c7e0d8e8c5593fb6431854d16d53718c
337cb0847bfe3ddb91017821acb83994ea28d585
68a823fd032ca2cdf0d731b7d23562defbef42cb
d4c9be23183f85dbdc3d88d483d31fdd6452ab38
861bc4ddd8ddd84937bc5756d552e51227720fbb
39da0df37c4d7a618f070c4216dbd7eae91f489a
b7b4bb1c55ba4476bd5b78bd2f3bc4197fe4d6b1
aebe4cec6c55ee180cda345fda0921fb9cc3818f
f3957ca5ce206e1224874e6495780b5130d6de0c
5e04b985acc4c774e0057056887a9f1ed05faf9b
a3cca16fac5d834f2f29e1daa31ced38938fada9
12fb0f40f60ba55cae3f92a2f642a7c32f8802c1
be81631363655e3437cae4303ab39c22500165fd
3812930e641d10d1ead10b52ddc7240dd585d0f6
713f9c960073df0a515279478f5e34b656cbe4ba
e226e0a163a463b67b9cad194cf07264d820a2aa
27b73f9d343821881221ea95d486acaba0098952
ca5cf8d35b9756c9d65831718c5032533612c94a
5e4491e84555fbf32b50ec08e3a8027f9ab38e9c
ab4f028db000b76a7d800ad5f42c9f44de525c09
ed7664036183256d109a652aee39ff9842680d47
0ec6beec7dafa70dd9ce7dd7b97be5e61a75b7af
69c53f9c3174b0a93a425dbdf80d6cb8f5722ec3
ed1542b9f37734bc77906c4ba49ea6ea3be09af8
04e10a843187810e97bf565731ddc5d70b0f4245
bd12ce56f03ab05a5a4652344efbabe11261e46c
4925a110c4e0586ca74566beca2450bbc4d18e4c
4a68c748e47e906f0d812a1572168e677afc1eb4
4a39d8a1610b635760ac182be894d206eb0a1ee7
eb4123b5caed6c5cbfe8ef050f198e2d5a03f8b7
654b09ec8b9e5a2342a7a4fa4bb323ad431ef0d9
031fc79834c9df4cbffffcc702a9482b22084738
b2fffcfacbd8987ff4ba763a5f34483f9219a532
b2e1e518f7ea7ea58645ff3a5562f102e725b0a8
ad4192e815d1e52802e6ac88c20ecab6d8ce3880
d7a295b97e4321e9e98b3ff61b8bfb1250ff672e
bba5ff7c4e956d04a8c9cd75e2f3a99a9c6f0fd1
b64de25abd88bfb2da99bbf820e1b770860b9256
78c76cf5f727a67872df6a96d4d74ce121da54a6
25d6b0c5e4816c579ad7a502e0e5cbb7ecb0e95b
4fea58a531ea4b40914d7a0063fdf0e47b60539e
2966b61522e05753ad1c6f10d1b573576afc4b15
f507539d822072e2f2f337d0fd06acde38e87371
2aa37d595e4204a7c30daf2e7ee64d96df1b13df
5966f8c2d47ed0d6544d7ac242bcbe2c849b474e
66cd97e558cdb57bff2dfc2bf8734b0ee12f648e
9b73069dc8ea885a93ada106938f6c6c1c875ae0
38e7562ccdcdf9c83aca8af3ea67adcddf0ae733
49779027293aa0039423d3beeff78a6f57991e07
25fd512f63b62dfa5e8e226e97602f0f2c52213a
04ca59a5129345a84bd1be6eb86378bbd6fb06d0
9b977f505100e235c3ecd91f916e14f62d813725
8a946f2758fc4cd5d9ceb6c411f1db1b8f04a50a
6ca265b8634cb35e444a4269956aed7ae49ccb1f
b9d8f8025b7122cab64c37e5042866c66b556016
37c2f73cc958003fbba479d6d4d7c003f5d88fd6
eea64478862bc5bffea84f0eb78bf541620293fb
c703f7a5642174d0e52aec91a6817d5cc56f47ab
ce47a81eb5f79dd3f54b300f6a9a7ccac9c1296a
885fe6e31b107b3a6362cde0785e6d886888e0ec
d079628a43f845522598be7efa0abf5e478549c6
844faf2f0ac5d21d65f452fb6f4d1b19bb0a2be2
b0031f531850e6cd4e674be45da54307f3e4360b
e8e0bea9b333315ec1ff9eb1d36d4e810ca95941
39cf01d0d26608065dc071d58fea4cfd8d51bf02
eba5e1321830624e6e42d248616f651beb0d3b99
e95392aa08f3cc421998648c584af5bab89e4ad6
9f73360e17d1e519d25cb4b60d7506fca9fd02fe
131d5ceb9deaaa1d8dd478a9b2e2556133c511aa
a152f36b0576737e647dbe5f1954039668123c1f
6a1f5f5797109050960688e4f9ec8817ace4c668
9f807fdd8d1a148891d389820c329f44f9ffe965
27d719174b75842156fba8b92d98e0908e95339b
ef4df24b472413925ca569456857dd10060c6917
Comment 36 Samba QA Contact 2021-11-09 18:44:32 UTC
This bug was referenced in samba v4-14-test:

6dbc3f11c0212081ab25a40f46f007252fc7510e
93289e90d6f4f9ef8b0dd85411602a7f5cb23b93
44270951af60c8860a64e35654e82bd4479433f8
5a5b1a06d6de8d1ffb4b1db4a7f575d8b1c168c2
16098012df9dcd9561582982d078e89ff6f42f34
849ef477cb35e125ee7c0f4060cda766a8a8e376
e0ae20193e3c8b486586faa5f486789ad6ee94fb
3815c92cc87c256c212d713c50ae5629ecf9c69f
d92787c05a02153742062a6caf3c754961ec527c
e31b6f6094403d1186835af4e8385e988c19a4e5
f111e42082ac0a9f4e9d77e908cbb894ba5748b4
cc26ffe58666db3651be9f3670e9c972b4322a0b
1e84bcbe4cbe2edfc340badd810c49f90d398609
68e093683c7ad222e9df3d77c56cfa33df29455a
6b2ea12fe470db27396d6cf3656e53ef76cc8f96
f9e3774dbf01a06d411150208135c2c6941c9815
c01d19f7f99e1c3eb678da81164665eca4ebe985
0420b616035ca3fd88a3ba473002bc604b91d181
bfd89cdbaa4cb90b487b054cc8a036267546151b
a5e515b9637686095f1e3a9a9faf2cd978558fa4
4414546589bb589df129faa77fce91f9758a5b43
76859f7926c1498d2c5be73cdca910b0d7381f82
adb6620043d4113a350ea24369f00246ea6410d4
e43275fc182c6bc39faf71ac4c007c71013b4748
7ca428223f522bd959be8e564432afcf5ea37ed8
a624a73ce46bbca579411a26581394ea72ae9d09
39c834af93813c736d002a0669fdf01dfc2e5241
8aeac144220949bb4a9c2fb5aacfead6133f9ed9
c3c49ceeb7991f9851e616a901e2f601ff796c3e
6280d99de7d0f761842a5ab37a6253aefa237344
9c66eacf637bc25e7720ba0d2b2f9763639f6e8c
cc1c47f1679b85c8860b2ee05c3f45b7b667ccef
c219b832d96b582aa5b81f0cec31ab432d6469e4
151b6145e1c0cb360b088dfc4e41982854fc2c9d
f2aafe556290e9944cc03146084e8f3991fcd06b
3cceba46aa5e93d65d529f4ec76fa19fe17244c6
e5f10558e0861fe16eee40485c5b520b039f0d24
d5b302e674f2ba2435339e1f6a6104780c63be9a
182db923a1d19db41cfb39b98d344cc350c301cd
cf3de54d6d64f63e76e9fd7920a37146809035ad
da61668c8a0c4772e2d7a725f1598d7aa3c92009
af11f643f5072bc4c70461e9d20a0ea2cc8ca6d3
Comment 37 Samba QA Contact 2021-11-09 18:53:24 UTC
This bug was referenced in samba v4-13-test:

05b27742da44524e6007631a401dfef0b7180d53
0792d340860a44ccfb98b231e2518db751a98a59
340e2153c7e0d8e8c5593fb6431854d16d53718c
337cb0847bfe3ddb91017821acb83994ea28d585
68a823fd032ca2cdf0d731b7d23562defbef42cb
d4c9be23183f85dbdc3d88d483d31fdd6452ab38
861bc4ddd8ddd84937bc5756d552e51227720fbb
39da0df37c4d7a618f070c4216dbd7eae91f489a
b7b4bb1c55ba4476bd5b78bd2f3bc4197fe4d6b1
aebe4cec6c55ee180cda345fda0921fb9cc3818f
f3957ca5ce206e1224874e6495780b5130d6de0c
5e04b985acc4c774e0057056887a9f1ed05faf9b
a3cca16fac5d834f2f29e1daa31ced38938fada9
12fb0f40f60ba55cae3f92a2f642a7c32f8802c1
be81631363655e3437cae4303ab39c22500165fd
3812930e641d10d1ead10b52ddc7240dd585d0f6
713f9c960073df0a515279478f5e34b656cbe4ba
e226e0a163a463b67b9cad194cf07264d820a2aa
27b73f9d343821881221ea95d486acaba0098952
ca5cf8d35b9756c9d65831718c5032533612c94a
5e4491e84555fbf32b50ec08e3a8027f9ab38e9c
ab4f028db000b76a7d800ad5f42c9f44de525c09
ed7664036183256d109a652aee39ff9842680d47
0ec6beec7dafa70dd9ce7dd7b97be5e61a75b7af
69c53f9c3174b0a93a425dbdf80d6cb8f5722ec3
ed1542b9f37734bc77906c4ba49ea6ea3be09af8
04e10a843187810e97bf565731ddc5d70b0f4245
bd12ce56f03ab05a5a4652344efbabe11261e46c
4925a110c4e0586ca74566beca2450bbc4d18e4c
4a68c748e47e906f0d812a1572168e677afc1eb4
4a39d8a1610b635760ac182be894d206eb0a1ee7
eb4123b5caed6c5cbfe8ef050f198e2d5a03f8b7
654b09ec8b9e5a2342a7a4fa4bb323ad431ef0d9
031fc79834c9df4cbffffcc702a9482b22084738
b2fffcfacbd8987ff4ba763a5f34483f9219a532
b2e1e518f7ea7ea58645ff3a5562f102e725b0a8
ad4192e815d1e52802e6ac88c20ecab6d8ce3880
d7a295b97e4321e9e98b3ff61b8bfb1250ff672e
bba5ff7c4e956d04a8c9cd75e2f3a99a9c6f0fd1
b64de25abd88bfb2da99bbf820e1b770860b9256
78c76cf5f727a67872df6a96d4d74ce121da54a6
25d6b0c5e4816c579ad7a502e0e5cbb7ecb0e95b
4fea58a531ea4b40914d7a0063fdf0e47b60539e
2966b61522e05753ad1c6f10d1b573576afc4b15
f507539d822072e2f2f337d0fd06acde38e87371
2aa37d595e4204a7c30daf2e7ee64d96df1b13df
5966f8c2d47ed0d6544d7ac242bcbe2c849b474e
66cd97e558cdb57bff2dfc2bf8734b0ee12f648e
9b73069dc8ea885a93ada106938f6c6c1c875ae0
38e7562ccdcdf9c83aca8af3ea67adcddf0ae733
49779027293aa0039423d3beeff78a6f57991e07
25fd512f63b62dfa5e8e226e97602f0f2c52213a
04ca59a5129345a84bd1be6eb86378bbd6fb06d0
9b977f505100e235c3ecd91f916e14f62d813725
8a946f2758fc4cd5d9ceb6c411f1db1b8f04a50a
6ca265b8634cb35e444a4269956aed7ae49ccb1f
b9d8f8025b7122cab64c37e5042866c66b556016
37c2f73cc958003fbba479d6d4d7c003f5d88fd6
eea64478862bc5bffea84f0eb78bf541620293fb
c703f7a5642174d0e52aec91a6817d5cc56f47ab
ce47a81eb5f79dd3f54b300f6a9a7ccac9c1296a
885fe6e31b107b3a6362cde0785e6d886888e0ec
d079628a43f845522598be7efa0abf5e478549c6
844faf2f0ac5d21d65f452fb6f4d1b19bb0a2be2
b0031f531850e6cd4e674be45da54307f3e4360b
e8e0bea9b333315ec1ff9eb1d36d4e810ca95941
39cf01d0d26608065dc071d58fea4cfd8d51bf02
eba5e1321830624e6e42d248616f651beb0d3b99
e95392aa08f3cc421998648c584af5bab89e4ad6
9f73360e17d1e519d25cb4b60d7506fca9fd02fe
131d5ceb9deaaa1d8dd478a9b2e2556133c511aa
a152f36b0576737e647dbe5f1954039668123c1f
6a1f5f5797109050960688e4f9ec8817ace4c668
9f807fdd8d1a148891d389820c329f44f9ffe965
27d719174b75842156fba8b92d98e0908e95339b
ef4df24b472413925ca569456857dd10060c6917
Comment 38 Andrew Bartlett 2021-11-09 19:10:22 UTC
The releases are made, removing [EMBARGOED] tag.  The vendor-only restriction will be removed soon once the dust settles.
Comment 39 Samba QA Contact 2021-11-09 19:47:47 UTC
This bug was referenced in samba v4-15-test:

af86793af77ab0dfe1c0a9740820c52b435d993d
e44195b765a4029909fc7132928f1ec971d8727d
56ace59efee73988bfd6b25161fa70cfc1956c82
ff062e2b0ae4063fb807ddfe2fa172bae0d2eec5
eddf0a5c6fa06cc6348217ae339b7fb9ef88b80d
25d2174dd1bce0ef8e984db6223339c2e8862389
2d5d5a39b0d89b98dc466f3561721f9d4dbbeb1b
c955376e02c74208c47d474a08e8ebb9308e319c
3657c79eb2dbfc6bc6b6157881edefe0fe0f1b56
c55de3995cf49812b24d4c2fc6e14c5c609db46c
dd88bd9f273dcb49d80d226df457aa05df232237
ae21152809414e96c209f708ba9a737d9dc16e8b
a65cd59b200ec6570cca7f2ab2238f6221bda602
c1bf56f314667ee3c5399576a45b74346d4c7f2e
a92da791615cd42ce28c679aba1c18a1ef2b5eb8
210b3e36f76d7251714aa48af2319496b907db11
1ec930b2f584ef012cd84d3d7ae265719de1b878
325942e4e78cccac5456a831375b881d5f80b4c0
e40a1d46831be8b6125b76b511bb24582e8a13e9
651b74b12b9d995f442fd02e90ca0a1ce12d4a52
39b060eeea6d364c7b7b575fda7a6877ce6e2a9a
58a1cc488ce20f7cd3c9013e9b8ec3163a25075e
3efb9d684d957f0e08c4fd537b0916b02cb73ceb
e4172baf12205881098e42e502b0fc8d961e6601
7b9920b382ac57b045e46fa113a9c4a9da782b68
093c5502ab41f068dbc222854caf9cca14d4c157
fb5ca61f54412dcf24c4f20dd1dd4639838fbfab
9cb158a9a53de11a7f0959d30be28b9f09b41469
558cd30acc6f6fff2356fe755cba65de7b3a6603
1d126e4fd9a6895b4d4b69efbf9f1791aa955f96
67ef2899a7d5164b9788996ad86402722dcd2564
c513478908c19b3c9112a9d3d195a67931d6146c
255e5c14061ca65c135959046a26418321d80092
Comment 40 Stefan Metzmacher 2021-11-09 20:12:42 UTC
Please notice the regression fix under
https://gitlab.com/samba-team/samba/-/merge_requests/2246
Comment 41 Samba QA Contact 2021-11-09 20:38:49 UTC
This bug was referenced in samba master:

9fe1b719e1b35ae4053cbb13f29f76f4b2f950ef
f9b16272d2879812011c5642019fd33ae72a6b91
b4ea50f8b272a3b1d1d9d9ceda3641c22a082604
05587361498ae8131435aca2d8c860e98f605581
0e23000f27823243ad797eb39581f83c3ad50b2b
6aedd965e167c46ab7e42e35268574e18a97fd51
9a2351581416223a4486c33378f430f510a03db4
76ec5f94091095bb1736a4582696ef6c4b37654c
cc6d63100cdfad10cd1a17e111b7d3012d796098
cc32b2464a74ecd8a53460eba3523296fa31e943
4cda41677ccb6d68289bafdf4d486e85b6beb2a7
27d20fc335c5df53bf6780d6296f1e4aef277311
79a6616cbe723a2bc05084b90298745143a76a7c
b39b698cdac9ef97d018d6f02d59493ec5bff6e6
6771b2f211f6f5ae08d94a75afb7c6109f65497d
14b9f905da196e4e1904e4d4b0dec6192e76ab61
97d54027910b7d3fa04bd6c1b72448a85cdf5d7c
4b78ad7346c7128142a65ce6d6625d3d28116882
28fae9c2215698e465201b6ad27eb9eeb55c906a
dd0423bfbbce2d9f1f8a62c21cf612e5c755b616
8f79ee99a6a3390ccb409ac1b5f543488e7bd784
52190982de134fb55abce76def0609651e45012e
57abb7f8f8884f52f1d194c5c74e067aecd0d3dd
e2d5b4d709293b52112d078d6fcde95593d790c5
e2d271cb6bcd292f786664f055cde41c32002804
935feff8e54cef9b379f653a3198a5bbd3a64989
bd8d06ff155fb831cd8d487eabfbc69743d12252
c4ddf939e0ee2b9ae1af8b2ff8344fc9c7118adf
566c2b296dd6826491958bf739673ca7b8d75be5
3ed0e5b924f77e0f92867cf93892e974e21542e5
2609e4297e04c93ca5bd1466617c4536faf5be32
e8bb009009cd68550db814904399163794e3a84a
757f1d20e4bcdef20307607a4501fe920270fd6e
Comment 42 Andrew Bartlett 2021-11-09 20:54:27 UTC
The patches addressing this issue have been pushed to master and security releases made.
Comment 43 Stefan Metzmacher 2021-11-11 20:15:44 UTC
Please notice(In reply to Stefan Metzmacher from comment #40)

Please also notice the additional fix and advanced example
for the 'username map [script]' based fallback from 'DOMAIN\user' to
'user'.
https://bugzilla.samba.org/show_bug.cgi?id=14901
https://gitlab.com/samba-team/samba/-/merge_requests/2251
Comment 44 Andrew Bartlett 2021-11-22 09:42:05 UTC
Removing vendor-only embargo and all-vendor CC.  If you wish to continue to follow this issue please CC individually.
Comment 45 Andrew Bartlett 2022-01-30 06:13:11 UTC
Actually removing the vendor-only embargo
Comment 46 Nagendra.V.S 2022-02-04 06:48:39 UTC
(In reply to Stefan Metzmacher from comment #31)
I was checking out the CVE description @ https://www.samba.org/samba/security/CVE-2020-25717.html
I see following text section in the doc

[Obsoleted 2021-11-16]
[Added 2021-11-11]

Looks like internals notes
While https://attachments.samba.org/attachment.cgi?id=16970 
advisory does not have them. Is this intentional?

Also the CVE is still in reserved state in mitre.