All Samba selftest environments set "gensec:require_pac = true" however this is NOT on by default in production. This means that a user who can request a kerberos ticket without a PAC is in the position to alter how the authorization of their session is done. Furthermore, the KDC implements a number of 'name mapping' rules which can be exposed in the kerberos principal name that is found in the ticket. In particular, a computer account with an innocuous name like root$ can also be accessed via the name root, which will show up in the kerberos principal name. If the PAC is specfically not requested, the target server must work out the authorization details by another method, which may not be as accurate. We should change the default for "gensec:require_pac" to be true if we are in an AD Domain, either as a domain member or DC. In a testenv, setup thus: SMBD_OPTIONS=-d10 SELFTEST_TESTENV=ad_member make testenv bin/samba-tool computer add root -s st/ad_dc/etc/smb.conf bin/samba-tool user setpassword root$ -s st/ad_dc/etc/smb.conf bin/samba4kinit --request-pac=0 root bin/rpcclient -k $SERVER -c 'getusername' grep root st/ad_member/smbd_test.log gives Successful AuthZ: [SMB2,krb5] user [ADDOMAIN]\[root] [S-1-22-1-65534] at [Thu, 29 Oct 2020 07:09:17.220561 UTC] Remote host [ipv4:10.53.57.11:19690] local host [ipv4:10.53.57.29:445] {"timestamp": "2020-10-29T07:09:17.220648+0000", "type": "Authorization", "Authorization": {"version": {"major": 1, "minor": 1}, "localAddress": "ipv4:10.53.57.29:445", "remoteAddress": "ipv4:10.53.57.11:19690", "serviceDescription": "SMB2", "authType": "krb5", "domain": "ADDOMAIN", "account": "root", "sid": "S-1-22-1-65534", "sessionId": "ddd95161-02b3-4e20-871f-5e45bf7ff67b", "logonServer": null, "transportProtection": "SMB", "accountFlags": "0x00000010"}} This is a local unix user SID. The UID is seen in the sesion as that matching "root" in the testenv. bin/samba4kinit root bin/rpcclient -k $SERVER -c 'getusername' grep root st/ad_member/smbd_test.log gives Successful AuthZ: [DCE/RPC,ncacn_np] user [ADDOMAIN]\[root$] [S-1-5-21-3499764700-1180176110-2152090493-1115] at [Thu, 29 Oct 2020 07:10:18.690560 UTC] Remote host [ipv4:10.53.57.11:19721] local host [ipv4:10.53.57.29:445] {"timestamp": "2020-10-29T07:10:18.690592+0000", "type": "Authorization", "Authorization": {"version": {"major": 1, "minor": 1}, "localAddress": "ipv4:10.53.57.29:445", "remoteAddress": "ipv4:10.53.57.11:19721", "serviceDescription": "DCE/RPC", "authType": "ncacn_np", "domain": "ADDOMAIN", "account": "roo$", "sid": "S-1-5-21-3499764700-1180176110-2152090493-1115", "sessionId": "1f3ebf0a-c758-4755-ba02-49fd130d3d82", "logonServer": "ADDC", "transportProtection": "SMB", "accountFlags": "0x00000080"}} This is the correct domain SID. The root$ -> root thing is critical as it means we bypass the getpwnam($DOMAIN\$USER) which would at least give a mangled imitation of the PAC token. We shouldn't allow the attacker this much flexability, we should just require the PAC.
A plan for how to test this: Write a python tests for the lsarpc GerUserName binding checking for an expected value. This value is incorrect for all Kerberos connections at the moment as the username in the PAC is not used. The test will create the user to test with, and expect back the domain and username that was created. To test without the PAC the user account will be set with UF_NO_AUTH_DATA_REQUIRED. To get the normative baseline, a connection will be made with NTLMSSP. This still won't actually exploit this issue, but should show the fix is consistent. A plan to test the exploited issue: Create a user root$ on the AD DC and use the auth audit code to notice if the connection is made as the correct SID. A plan for how to fix this: Combine much more closely the NTLM and Kerberos authorization code paths in smbd, requiring unless configured otherwise a PAC for all kerberos users in an Active Directory domain.
(In reply to Andrew Bartlett from comment #1) Currently we can't get a ticket via the credentials (and so easily in python) infrastructure without canonicalise being set, we need to work out a way to do this in order to exploit this issue.
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.
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.
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.
Note that we have to be careful on usernames in general, not just non-canonicalisation, as if there is no PAC then a race can be created between the name in the ticket at issue time and use time. That is, the ticket could be for a real AD user root, but without a PAC the samlogon cache will not be primed and at session setup time the user root could be renamed to root2, causing a miss on the getpwnam("DOM\root") and so a fallback to getpwnam("root").
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.
(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.
Created attachment 16845 [details] Current work in progress patches
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.)
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.
(In reply to Stefan Metzmacher from comment #8) Sounds good to me! Thanks a lot for explaining this in detail.
Created attachment 16924 [details] advisory text (v01)
Opening this issue to vendors
Created attachment 16926 [details] advisory text (v02)
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 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." --------------------------------------------
Created attachment 16952 [details] Patches for v4-11-test
Created attachment 16953 [details] Patches for v4-10-test
Created attachment 16954 [details] Patches for v4-9-test
(In reply to Jeremy Allison from comment #18) Thanks Jeremy, can you please upload a CVE-2020-25717-advisory-v4.txt?
Created attachment 16955 [details] Patches for v4-7-test
Created attachment 16956 [details] CVE-2020-25717-advisory-v4.txt Updated with clarified advisory text. Metze please take a look. Thanks !
Created attachment 16958 [details] Patches for v4-6-test
Created attachment 16959 [details] Patches for v4-4-test
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.
Created attachment 16963 [details] Patches for v3-6-test (wip)
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!
Created attachment 16970 [details] advisory v6.txt Slight tidyup of language in new section.
Comment on attachment 16970 [details] advisory v6.txt Thanks!
Created attachment 16978 [details] Patches for v3-6-test
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
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
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
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
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
The releases are made, removing [EMBARGOED] tag. The vendor-only restriction will be removed soon once the dust settles.
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
Please notice the regression fix under https://gitlab.com/samba-team/samba/-/merge_requests/2246
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
The patches addressing this issue have been pushed to master and security releases made.
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
Removing vendor-only embargo and all-vendor CC. If you wish to continue to follow this issue please CC individually.
Actually removing the vendor-only embargo
(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.
I've made some comments public now the issue is well described.