Sorry for the incorrect detail, the option is "server schannel".

For servers that do not have "server schannel = yes" (either by default or explicitly):

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8)

I've run the exploit from 
https://github.com/dirkjanm/CVE-2020-1472/blob/master/cve-2020-1472-exploit.py
against Samba (git master) and confirmed Samba is vulnerable if
'server schannel = auto'.

I understand the mitigation will be to strongly recommend the 

require schannel = yes

setting, but no code changes?

(In reply to Marcus Meissner from comment #4)

We'll also do code changes, but for now we only have:

  server schannel = yes

Note again that 'require schannel' was a typo in the initial text!

Antoher typo perhaps:

The researchers call it "ZeroLogon", not "ZeroLogin" ?

Created attachment 16228 [details]
Work in progress patches for master

This is my current state...

I guess someone needs to port the netr_ServerPasswordSet2
protection to source3.

The "server require schannel:MACHINE$ = no" was not tested yet and I'm
not sure our smb.conf parser handles the '$' sign.

Both cve-2020-1472-exploit.py and zerologon_tester.py fail to attack us now.
I tested them with the netlogon_creds_server_init() fix applied.
Then I tested cve-2020-1472-exploit.py with just the netr_ServerPasswordSet2 change
(and server schannel = auto) also prevents the problem.
(I commented the checks out step by step, to see that each of alone also catches it).

I was also planing some more DBG_ERR() messages in
dcesrv_netr_creds_server_step_check() in order to
warn the admin to fix the configuration.

If "server schannel" is not "yes", we should give hints,
which machine uses schannel and that the values should be
changed to from auto to yes.

The same applies if "server require schannel:MACHINE$ = no"
is configured, but the client actually uses schannel.

The reverse should also be logged, If a client is rejected
because of "server schannel = yes", we could propose
"server require schannel:MACHINE$ = no", but with a big warning
that it could also be an attacker.

Created attachment 16229 [details]
Back-port of Metze's _netr_ServerPasswordSet2 protections to s3.

Compiles, but not tested. Just thought I'd try and help out.

Comment on attachment 16229 [details]
Back-port of Metze's _netr_ServerPasswordSet2 protections to s3.

Thanks Jeremy, but I fear it won't work as decode_pw_buffer()
returns a utf8 blob, while extract_pw_from_buffer() just extracts
the utf16 bytes. So you need to do everything with extract_pw_from_buffer()
and only after it all passes convert to utf8 using convert_string_talloc()
at the end.

Thanks for the review. I'll amend and try again !

Created attachment 16230 [details]
Back-port of Metze's _netr_ServerPasswordSet2 protections to s3 - v2

Trying again, now with some more understanding of what this code is supposed to do :-).

Comment on attachment 16230 [details]
Back-port of Metze's _netr_ServerPasswordSet2 protections to s3 - v2

Closer :-)

You can't use decode_pw_buffer() as password_buf.data
don't hold the decrypted password anymore.

Just convert new_password into plaintext using
convert_string_talloc()

(In reply to Stefan Metzmacher from comment #12)

I guess this would catch any regression:
TDB_NO_FSYNC=1 make -j test FAIL_IMMEDIATELY=1 TESTS='rpc.schannel rpc.netlogon'

Created attachment 16231 [details]
Third time is the charm :-).

Thanks for the help Metze.

Pedantic mode:

 AES -> AES CFB8 with all zero IV

(In case you want to use the description in some release notes or other communication)

Comment on attachment 16228 [details]
Work in progress patches for master


in dcerpc_netlogon.c
I'm unclear what the block after the length check achieves, doesn't the code added before the length check  do the same thing?
861 »       /*                                                                      
 862 »        * Check that the password part was actually encrypted,                 
 863 »        * otherwise we are under attack.                                       
 864 »        */                                                                     
 865                                                                                 
 866 »       memcpy(password_buf.data, r->in.new_password->data, 512);               
 867 »       SIVAL(password_buf.data, 512, new_password.length);                     
 868                                                                                 
 869 »       if (!extract_pw_from_buffer(mem_ctx, password_buf.data, &enc_blob)) {   
 870 »       »       DBG_WARNING("Failed extract encrypted password Length[%zu]\n",  
 871 »       »       »           new_password.length);                               
 872 »       »       return NT_STATUS_WRONG_PASSWORD;                                
 873 »       }                                                                       
 874                                                                                 
 875 »       if (data_blob_cmp(&new_password, &enc_blob) == 0) {                     
 876 »       »       DBG_WARNING("Password buffer not encrypted Length[%zu]\n",      
 877 »       »       »           new_password.length);                               
 878 »       »       return NT_STATUS_WRONG_PASSWORD;                                
 879 »       }

Notes from phone call Andrew and I had with Microsoft.

The check for repeated data in the challenge is

       if (challenge->data[1] == challenge->data[0] &&                                                                                                                      
           challenge->data[2] == challenge->data[0] &&                                                                                                                      
           challenge->data[3] == challenge->data[0] &&                                                                                                                      
           challenge->data[4] == challenge->data[0])   


They are currently only allowing accounts to operate without schannel 
if the account connects with secure channel type is workstation
   (Is a domain member)
AND is not running windows
   (specified in the AD operating system attribute, set by the
    LogonGetDomainInfoCall)

And the February 2021 fixes will prevent any account operating without schannel unless explicitly permitted.

Created attachment 16232 [details]
DEFERRED-WIP patch to enforce DCs and trusts to use schannel

This patch tries to implement the behaviour Gary just descried, except for the OS check, but blocks the most serious part of this issue which is the reset of the DC password.

Does this affect samba configs only in AD configuration? Would a samba server as a file/print server be also affected?

(In reply to Huzaifa Sidhpurwala from comment #19)

Only domain controllers are affected, AD as well as classic/NT4-style,
where the impact on AD seems to be more critical.

(In reply to Gary Lockyer from comment #17)

Thanks!

Do they just search for the string 'Windows' in:

operatingSystem: Windows Server 2008 R2 Enterprise

Comment on attachment 16232 [details]
DEFERRED-WIP patch to enforce DCs and trusts to use schannel

This is basically the same as

https://git.samba.org/?p=metze/samba/wip.git;a=commitdiff;h=56dad369545483bbd411995c0d54fea13c1d596c

It means a lot of tests fail.

Maybe we could add an 'server testing require dc schannel:DCNAME$ = no'
for DEVELOPER builds, in order decouple changing all tests from getting this out of the door.

(In reply to Gary Lockyer from comment #16)

in dcerpc_netlogon.c
I'm unclear what the block after the length check achieves, doesn't the code added before the length check  do the same thing?
861 »       /*                                                                      
 862 »        * Check that the password part was actually encrypted,                 
 863 »        * otherwise we are under attack.                                       
 864 »        */                                                                     
 865                                                                                 
 866 »       memcpy(password_buf.data, r->in.new_password->data, 512);               
 867 »       SIVAL(password_buf.data, 512, new_password.length);                     
 868                                                                                 
 869 »       if (!extract_pw_from_buffer(mem_ctx, password_buf.data, &enc_blob)) {   
 870 »       »       DBG_WARNING("Failed extract encrypted password Length[%zu]\n",  
 871 »       »       »           new_password.length);                               
 872 »       »       return NT_STATUS_WRONG_PASSWORD;                                
 873 »       }                                                                       
 874                                                                                 
 875 »       if (data_blob_cmp(&new_password, &enc_blob) == 0) {                     
 876 »       »       DBG_WARNING("Password buffer not encrypted Length[%zu]\n",      
 877 »       »       »           new_password.length);                               
 878 »       »       return NT_STATUS_WRONG_PASSWORD;                                
 879 »       }

The code above calls netlogon_creds_aes_decrypt(), but here we don't.
So the first 512 bytes are the encrypted ones from the client, while
we store the decrypted length in the last 4 bytes.
That means enc_blob contails the same amount of bytes as new_password
(with the random confounder bytes stripped),
but it hold the bytes in their encrypted form.

If I added a few random bytes as confounder as the start of the message,
following zero bytes in the confounder can still cause the password part to
be unencrypted.

(In reply to Andrew Bartlett from comment #2)


Interestingly NVD gave a full 10 to this flaw

NVD: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Created attachment 16233 [details]
Possible patches for master

I guess we should do releases with something like this patchset,
it should fix the main problems.

I think all other hardening (like always enforcing schannel for non
workstation trusts and looking at the operatingSystem attribute) can be done in the next weeks.

I'll try to do some basic testing with the 
server require schannel:COMPUTERACCOUNT option.

Someone needs to do some basic testing with a NT4 DC.

For backports vendors may want to include the following change for 4.7 and older:

commit 0341e83d40dc42fbb1f1e467626418a9e4dedf40
Author: Stefan Metzmacher <metze@samba.org>
Date:   Thu Dec 7 13:22:22 2017 +0100

    docs-xml: deprecate "server schannel" and change the default to "yes"
    
    No client should use the old protocol without DCERPC level integrity/privacy,
    but Maybe there're some lagacy OEM file servers, which require this.
    
    Signed-off-by: Stefan Metzmacher <metze@samba.org>
    Reviewed-by: Ralph Boehme <slow@samba.org>

Comment on attachment 16233 [details]
Possible patches for master

A pipeline is running under
https://gitlab.com/samba-team/devel/samba/-/pipelines/191259509

Can some write an advisory we can use for security releases?

If the patches are ok, we also need backports...

I'd propose we should do releases (for 4.10, 4.11 and 4.12)
as soon as possible (if possible tomorrow before 12:00 UTC).

4.13 can follow a bit later (there we may remove the global "server schannel" option).

Created attachment 16234 [details]
Possible patches for master (v2)

Here's a new patchset, it should pass the samba.tests.docs test
and nt4 tests now.

I've also tested the "server require schannel:ub1404-163$ = no"
option and fixed a few logic bugs in the DBG_ERR messages.

The pipeline runs here:
https://gitlab.com/samba-team/devel/samba/-/pipelines/191302122

Someone should play with the options and test the nt4 cases.
While testing with running the exploit again nt4/source3,
it's useful to revert the netlogon_creds_server_init check
in order to trigger the other cases. In the ServerPasswordSet2
code I typically add '0 &&' to the if statements step by step
in until I can prove the last check is triggered and protect
against the problem alone.

(In reply to Stefan Metzmacher from comment #21)
That was the impression I got from the call, yes.

(In reply to Stefan Metzmacher from comment #28)
How does this pass our existing rpc.netlogon tests which deliberately set a "" password?  I don't see any knownfail entries.

(In reply to Stefan Metzmacher from comment #28)

That all looks reasonable, I'm going to start writing tests

(In reply to Andrew Bartlett from comment #30)
These appear to be tagged as "dangerous tests", and are not run by default.

Testing ServerPasswordSet2 on machine account
Changing machine account password to '%%tj&dAIShP+,>qomEs0+Pppf-6DshA_9CC1M2ii[zG:uSB1TGL3dDDH9w#P13Jm;mb.g~>TNjlJA~&0Ut9$RpAU[+1v'
Not testing ability to set password to '', enable dangerous tests to perform this test

My plan for today:
 - backport the patch to supported branches
 - write advisory text (starting with what went to CERT and samba-announce)
 - wait for any tests that get written (gary is working on tests)
 - backport again based on any tests that come up

I'll work towards the suggested 12:00 UTC Friday goal.

Created attachment 16235 [details]
advisory v1, needs at least $VERSIONS

Created attachment 16236 [details]
advisoryv2 still needs $VERSIONS

Created attachment 16237 [details]
WIP initial tests

CI currently under way
https://gitlab.com/samba-team/devel/samba/-/pipelines/191461883

Comment on attachment 16237 [details]
WIP initial tests

+	/*
+	 * Set the first 4 bytes of the client challenge to the same value,
+	 * this should fail pass, CVE-2020-1472(ZeroLogon)
+	 * BUG: https://bugzilla.samba.org/show_bug.cgi?id=14497
+	 */

Just a wrong comment, try: this should pass as 5 bytes identical are needed to fail for CVE-....

Otherwise looks good to me.

Comment on attachment 16236 [details]
advisoryv2 still needs $VERSIONS

Also missing from advisory v2 is Günther Deschner in the credits.

Passing pipelines:

https://gitlab.com/samba-team/devel/samba/-/commits/abartlet/CVE-2020-1472-ZeroLogon-v4-13-test - https://gitlab.com/samba-team/devel/samba/-/pipelines/191410510

https://gitlab.com/samba-team/devel/samba/-/commits/abartlet/CVE-2020-1472-ZeroLogon-v4-12-test - https://gitlab.com/samba-team/devel/samba/-/pipelines/191411984

https://gitlab.com/samba-team/devel/samba/-/commits/abartlet/CVE-2020-1472-ZeroLogon-v4-11-test - https://gitlab.com/samba-team/devel/samba/-/pipelines/191417436

https://gitlab.com/samba-team/devel/samba/-/commits/abartlet/CVE-2020-1472-ZeroLogon-v4-10-test - https://gitlab.com/samba-team/devel/samba/-/pipelines/191419178

I'll add Gary's test and re-run those.

Comment on attachment 16237 [details]
WIP initial tests

Sorry, this doesn't apply cleanly on top of attachment 16234 [details]

(In reply to Andrew Bartlett from comment #40)
Sorry, I had an old pull from git.samba.org so I had an old master.

Created attachment 16238 [details]
patch v3 including tests for master

Created attachment 16239 [details]
patch v3 including tests for 4.13

Created attachment 16240 [details]
patch v3 including tests for 4.12

Comment on attachment 16240 [details]
patch v3 including tests for 4.12

https://gitlab.com/samba-team/devel/samba/-/pipelines/191479984

Comment on attachment 16238 [details]
patch v3 including tests for master

https://gitlab.com/samba-team/devel/samba/-/pipelines/191476872

Created attachment 16241 [details]
patch v3 including tests for 4.11

https://gitlab.com/samba-team/devel/samba/-/pipelines/191480430

Created attachment 16242 [details]
patch v3 including tests for 4.10

https://gitlab.com/samba-team/devel/samba/-/pipelines/191480978

Comment on attachment 16239 [details]
patch v3 including tests for 4.13

"patch v3 including tests for 4.13" has a garbled comment in the final test patch.

+	/*
+	 * Set the first 4 bytes of the client challenge to the same value,
+	 * this should fail pass, CVE-2020-1472(ZeroLogon)
+	 * BUG: https://bugzilla.samba.org/show_bug.cgi?id=14497
+	 */


Diff vis-a-vis master patch:

 +      /*
-+       * Set the first 4 bytes of the client challenge to the same value,
-+       * this should fail pass, CVE-2020-1472(ZeroLogon)
++       * Set the first 4 bytes of the client challenge to the same
++       * value, this should pass as 5 bytes identical are needed to
++       * fail for CVE-2020-1472(ZeroLogon)
++       *
 +       * BUG:


Otherwise fine.

Comment on attachment 16241 [details]
patch v3 including tests for 4.11

The 4.12 and 4.11 patches have the same test comment anomaly as 4.13.

4.11 also has a difference here that makes sense in context, but maybe we want to add a comment to the commit message:

 From: Jeremy Allison <jra@samba.org>
 Date: Wed, 16 Sep 2020 12:48:21 -0700
 Subject: [PATCH 09/19] CVE-2020-1472(ZeroLogon): s3:rpc_server/netlogon: Fix
@@ -576,22 +568,22 @@ Signed-off-by: Jeremy Allison <jra@samba.org>
  1 file changed, 1 insertion(+)
 
 diff --git a/source3/rpc_server/netlogon/srv_netlog_nt.c b/source3/rpc_server/netlogon/srv_netlog_nt.c
-index 3894eecd7ae..bc5ec654a95 100644
+index 548efb44ad2..2b68a2db15a 100644
 --- a/source3/rpc_server/netlogon/srv_netlog_nt.c
 +++ b/source3/rpc_server/netlogon/srv_netlog_nt.c
-@@ -1364,6 +1364,7 @@ NTSTATUS _netr_ServerPasswordSet2(struct pipes_struct *p,
-                                                     password_buf.data,
+@@ -1386,6 +1386,7 @@ NTSTATUS _netr_ServerPasswordSet2(struct pipes_struct *p,
                                                      516);
-               if (!NT_STATUS_IS_OK(status)) {
-+                      TALLOC_FREE(creds);
-                       return status;
-               }
        }
+       if (!NT_STATUS_IS_OK(status)) {
++              TALLOC_FREE(creds);
+               return status;
+       }
+ 



(4.11 also contains whitespace differences).

Comment on attachment 16242 [details]
patch v3 including tests for 4.10

The 4.10 patch has this difference that should perhaps be noted in commit message.

([PATCH 07/18] CVE-2020-1472(ZeroLogon): libcli/auth: reject weak)


 --- a/libcli/auth/wscript_build
 +++ b/libcli/auth/wscript_build
 @@ -18,7 +18,7 @@ bld.SAMBA_SUBSYSTEM('NTLM_CHECK',
  
  bld.SAMBA_SUBSYSTEM('LIBCLI_AUTH',
        source='credentials.c session.c smbencrypt.c smbdes.c',
--      public_deps='MSRPC_PARSE',
-+      public_deps='MSRPC_PARSE util_str_escape',
+-      public_deps='MSRPC_PARSE gnutls GNUTLS_HELPERS',
++      public_deps='MSRPC_PARSE gnutls GNUTLS_HELPERS util_str_escape',
        public_headers='credentials.h:domain_credentials.h'
        )


4.10 has the same test comment quirks of 4.11 - 4.13.

It lacks the "s3:rpc_server/netlogon: Fix mem leak onto p->mem_ctx in error path of _netr_ServerPasswordSet2()" patch, because it lacks an error path.

Comment on attachment 16236 [details]
advisoryv2 still needs $VERSIONS

Really *excellent* work Douglas. A few minor clarifications below:

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

I'd change:

"The following applies to Samba used as domain controller only."

to:

"The following applies to Samba used as domain controller only.
Installations running Samba as a file server only are not affected
by this flaw."

-------------------------------------------------------------------
Also:

"Vendors supporting Samba 4.7 and below are advised to patch their
installations and packages to add this line."

to:

"Vendors supporting Samba 4.7 and below are advised to modify their
installations and packages to add this line into the [global]
section of their smb.conf file."

-------------------------------------------------------------------
And:

"Some of the exploits for this issue only attempt to authenticate to
the NetLogon service but do not attempt a takeover of the domain."

to:

"The published proof of concept exploit for this issue only attempts to authenticate to
the NetLogon service but does not attempt a takeover of the domain."

-------------------------------------------------------------------
And:

"This Samba release includes a restriction on the client-specified
challenge that both provides some protection when 'server schannel =
no/auto' and avoids this false-positive result.

to:

"This Samba release adds additional server checks for the protocol attack
in the client-specified challenge that provides some protection when
'server schannel = no/auto' and avoids this false-positive result.

These server checks are identical to the server logic added
by Microsoft for their patch for the Windows server code for CVE-2020-1472.
The Samba Team would like to thank Microsoft for their disclosure of
the method used to prevent the proof of concept exploit code from
working against such a hardened server."
-------------------------------------------------------------------

That's all I can see. Feel free to disagree/modify these modifcations
if you wish !

Comment on attachment 16238 [details]
patch v3 including tests for master

With the comments fixed As Douglas noted. RB+

Comment on attachment 16239 [details]
patch v3 including tests for 4.13

With comments fixed as Douglas noted RB+

Do we need to add reviewd by tags?

Comment on attachment 16240 [details]
patch v3 including tests for 4.12

With comment fixes as noted by Douglas

Do we need to add reviewed by tags.

Comment on attachment 16241 [details]
patch v3 including tests for 4.11

With comment fixes as noted by Douglas

Do we need to add reviewed by tags.

Comment on attachment 16242 [details]
patch v3 including tests for 4.10

With comment fixes as noted by Douglas

Do we need to add reviewed by tags.

Going offline while I sort out tea, email me if I can usefully do anything.

(In reply to Douglas Bagnall from comment #49)
Sorry about that, poor backport on my part!

(I fixed the comment and failed to backport it)

Created attachment 16243 [details]
advisory v3, expands $VERSIONS, includes JRA feedback, and credits Günther

Thanks Jeremy!

I included all your suggestions, but for the "file server only" line I added a pointer down to the section we have about file servers, which warns about "client schannel = no". 

It makes it a bit unwieldy, though. Whether it should be there depends on whether anyone would actually use "client schannel = no". I don't know.

For $VERSIONS I put 4.10.18, 4.11.13, and 4.12.7 but not 4.13.0.

Comment on attachment 16243 [details]
advisory v3, expands $VERSIONS, includes JRA feedback, and credits Günther

Looks good, thanks!

Created attachment 16244 [details]
patch v4 for 4.13

Created attachment 16245 [details]
patch v4 for 4.12

Created attachment 16246 [details]
patch v4 for 4.11

Created attachment 16247 [details]
patch v4 for 4.10

The v4 patches have the various minor changes proposed here, which amounts to no code changes except in comments in a test.

I have not added reviewed-bys because, honestly, I have not reviewed the code changes, only the backporting.

There is no v4 master patch -- it is the same as v3.

Created attachment 16248 [details]
Backports v4 to 4.9 (compiles, but untested)

A pipeline is running here:
https://gitlab.com/samba-team/devel/samba/-/pipelines/191574660

Created attachment 16249 [details]
Backports v4 to 4.8 (compiles, but untested)

A pipeline is running here:
https://gitlab.com/samba-team/devel/samba/-/pipelines/191586233

Created attachment 16250 [details]
advisory v4

Created attachment 16251 [details]
advisory v4

This bug was referenced in samba v4-11-stable:

6941fa1ff8336af0f77728aaf8162b59aa704988
691d854c141cfe177f4c18ed045e38725504aaf3
f7b0e7a6dde36bd6721c7f8d926dfdd0d70ba68e
a71bc6c974db72fd3ef0a234fb9a0ef4fdc4d963
35277995d3977c37509ef072e6b5cc785ceb7ee2
13185dd83563cc7927a511f5d2a4a56cc2186743
fd05519caa2e738da317432371f42e4967514773
9b174d71541ec60157c17938551d8c9b429e578f
d5926ad40ffc31a9b0f6e2cb66d47aa58e1e5e4e
0da2f3e2455999cc30761a40715a1f1a88e1b725
f867164dc57b85c3c69b08be51c64aa430a23b2e
92d7e9f7f92f1ff225cd52fb24242a0f5d8f1d3d
c836fc24b9c11752581ac9d314ecdde80588aba2
5ee9480a89860d6906710fac39067e7d9db14feb
615cc75074b0f51734da261dc9b57ad209780e13
86c54d3a270ab984bfc7c7c0cc334210ed7956ce
572a41b24e7cb1b7d52f4021e0fef257cc0563eb
337e4da4daa564f90bfcde1bd8a30cb269fd54a9
db344db0efb0eff16211e6bb7dbf02501278c890

This bug was referenced in samba v4-10-stable:

e3e816443470860a93793117b26328d2ebaa36a6
0b45e084a450fe5e44904c0e4b9e2517f26c5336
520216a051a7fc0c4e2ef20b988c36d5d4a178f7
8aa00858571f69c084d7fb3847d994acf683d764
36824951f3a5fb082c98051df6439402c13fac2a
1665085bb3a3050a6a51af8082dccde61a08ec57
bffdfb129cead0448ad233fd8b94da9e7fb5aeca
e799c47b6e0ec996099612a7f287888ed4d5559f
59f88cb36eb1ce7e53abf3b1d007b4625f35996c
b33d4dff5f5f32dfb316ec10108d5cb5c12f7986
1a1ecc5fc31aa8d00aa8b9ac03daf99375c54d17
bfb70388c1cdb39a460375fffa3714606498c533
6a6f64fc8c3c515294010b2876667a6e157a486b
912cc29a9950d6385f4e372b5141900f87a464b7
54fb5e12d6805e687e8840209a2d4af26294ee18
4c0ad865d400739106c624beb1494128f885fce6
4809d018dea336dd50e84f713778c53ed85fef20
a414d149503718650bf2bdd049a92b04472ef267

This bug was referenced in samba v4-12-stable:

e862b4ce5678ce19d7d529fd76cfc4e67195ed10
d92c031f69afaaeef9a1f69d644301086d5cd964
daeb1bebcea08d2ce3467743fd092f1826c3fb6e
88d4e02c6b14c93b5b3fc0712416057989f63a11
0371ca12772e0ec8bd62810cf040cfd8e841116b
ef49b5d0911aae59cb4dad8bdcbd966d4167522b
e0e2d5911f554b4abe508283096fbd1b1e9698e4
0f4d98c1a2eb157677e16cf925e5095d481da8b1
dac81bdde6a881b09d6cb3191c119c87381a7c4a
e75cfccb1c5d91be12123f7e901a5111f1256352
1a03f0119144c8af8e89cdb7d0c3563be20c7a66
e4e0094fdbdf7b85da1cd10b78568801d0557b26
8c5940223e11eb926553f1a9642a4f7805686618
2462fa5f30e002e69bc3b6f75aafe0c720151769
f3f792b8eabe4fc833363d1e8159ffd754279f1f
a26ee2bf94a2d13a7fd31edd6a8e5d33e55fb0e2
512060e37ee996fc5a32dc374d7d47957c5081ef
3eeb5671b8076b22a67c34153d2f0899a02e7a88
04d316f3d510152c6ff052f62fa7eddd451a1b6b

This bug was referenced in samba v4-10-stable (Release samba-4.10.18):

e3e816443470860a93793117b26328d2ebaa36a6
0b45e084a450fe5e44904c0e4b9e2517f26c5336
520216a051a7fc0c4e2ef20b988c36d5d4a178f7
8aa00858571f69c084d7fb3847d994acf683d764
36824951f3a5fb082c98051df6439402c13fac2a
1665085bb3a3050a6a51af8082dccde61a08ec57
bffdfb129cead0448ad233fd8b94da9e7fb5aeca
e799c47b6e0ec996099612a7f287888ed4d5559f
59f88cb36eb1ce7e53abf3b1d007b4625f35996c
b33d4dff5f5f32dfb316ec10108d5cb5c12f7986
1a1ecc5fc31aa8d00aa8b9ac03daf99375c54d17
bfb70388c1cdb39a460375fffa3714606498c533
6a6f64fc8c3c515294010b2876667a6e157a486b
912cc29a9950d6385f4e372b5141900f87a464b7
54fb5e12d6805e687e8840209a2d4af26294ee18
4c0ad865d400739106c624beb1494128f885fce6
4809d018dea336dd50e84f713778c53ed85fef20
a414d149503718650bf2bdd049a92b04472ef267

This bug was referenced in samba v4-11-stable (Release samba-4.11.13):

6941fa1ff8336af0f77728aaf8162b59aa704988
691d854c141cfe177f4c18ed045e38725504aaf3
f7b0e7a6dde36bd6721c7f8d926dfdd0d70ba68e
a71bc6c974db72fd3ef0a234fb9a0ef4fdc4d963
35277995d3977c37509ef072e6b5cc785ceb7ee2
13185dd83563cc7927a511f5d2a4a56cc2186743
fd05519caa2e738da317432371f42e4967514773
9b174d71541ec60157c17938551d8c9b429e578f
d5926ad40ffc31a9b0f6e2cb66d47aa58e1e5e4e
0da2f3e2455999cc30761a40715a1f1a88e1b725
f867164dc57b85c3c69b08be51c64aa430a23b2e
92d7e9f7f92f1ff225cd52fb24242a0f5d8f1d3d
c836fc24b9c11752581ac9d314ecdde80588aba2
5ee9480a89860d6906710fac39067e7d9db14feb
615cc75074b0f51734da261dc9b57ad209780e13
86c54d3a270ab984bfc7c7c0cc334210ed7956ce
572a41b24e7cb1b7d52f4021e0fef257cc0563eb
337e4da4daa564f90bfcde1bd8a30cb269fd54a9
db344db0efb0eff16211e6bb7dbf02501278c890

This bug was referenced in samba v4-12-stable (Release samba-4.12.7):

e862b4ce5678ce19d7d529fd76cfc4e67195ed10
d92c031f69afaaeef9a1f69d644301086d5cd964
daeb1bebcea08d2ce3467743fd092f1826c3fb6e
88d4e02c6b14c93b5b3fc0712416057989f63a11
0371ca12772e0ec8bd62810cf040cfd8e841116b
ef49b5d0911aae59cb4dad8bdcbd966d4167522b
e0e2d5911f554b4abe508283096fbd1b1e9698e4
0f4d98c1a2eb157677e16cf925e5095d481da8b1
dac81bdde6a881b09d6cb3191c119c87381a7c4a
e75cfccb1c5d91be12123f7e901a5111f1256352
1a03f0119144c8af8e89cdb7d0c3563be20c7a66
e4e0094fdbdf7b85da1cd10b78568801d0557b26
8c5940223e11eb926553f1a9642a4f7805686618
2462fa5f30e002e69bc3b6f75aafe0c720151769
f3f792b8eabe4fc833363d1e8159ffd754279f1f
a26ee2bf94a2d13a7fd31edd6a8e5d33e55fb0e2
512060e37ee996fc5a32dc374d7d47957c5081ef
3eeb5671b8076b22a67c34153d2f0899a02e7a88
04d316f3d510152c6ff052f62fa7eddd451a1b6b

Samba 4.12.7, 4.11.13 and 4.10.18 are released.

I'll do 4.13.0rc6 soon and also push the patches to master.

Comment on attachment 16238 [details]
patch v3 including tests for master

Pushed to autobuild for master

This bug was referenced in samba v4-13-test:

b57b6004db8ac9fef38227e67d1d77a237600f30
9d90cd2b50962a63e02ff633b0fa60a3129fbc60
acf80197316dbea610129dfc9e4b735e7cec0424
5f28e4f74739cc282abb165fb0d3b4548988d953
afa0ec41cbb08d8bcafb6eedee1f9171a992d97c
fdac15704f9b06cb828a9a94c1bc3b8627ec366d
ba9110a17d753c63a1d8f3981ba3ef88eae64965
ed94cb18f01550197a66727566b55fb5f58e7890
4ad58d61ba16537b838708e8337a512258ef864c
6e8f183038286f3bb8e2eae4bd2f1a89b33db396
befc2aca239ee78ea36bb0d8c527bb7aa26198f1
b6f91e77ef4effe305d2c7c0fc8bcd06cda7761d
32dd379f30a1a1864633a6133ed98e38eb5d6b3f
7ab19ec5a1080c3c68baca6e3a1ab09aa4ee60fd
b93e1dcd15400725904ec3e68a02bada11c80d69
6192153da9accb152737ea57ef6465b5bed97830
e5c7800b096a4b9fd03490de939e1f26c776123e
7c88d85ca8c513f0fe967f91f4ea64d8f63d0aee
e4dc8227ae1e28ef7f49d0903d057c7f7912ca27

This bug was referenced in samba v4-13-stable (Release samba-4.13.0rc6):

b57b6004db8ac9fef38227e67d1d77a237600f30
9d90cd2b50962a63e02ff633b0fa60a3129fbc60
acf80197316dbea610129dfc9e4b735e7cec0424
5f28e4f74739cc282abb165fb0d3b4548988d953
afa0ec41cbb08d8bcafb6eedee1f9171a992d97c
fdac15704f9b06cb828a9a94c1bc3b8627ec366d
ba9110a17d753c63a1d8f3981ba3ef88eae64965
ed94cb18f01550197a66727566b55fb5f58e7890
4ad58d61ba16537b838708e8337a512258ef864c
6e8f183038286f3bb8e2eae4bd2f1a89b33db396
befc2aca239ee78ea36bb0d8c527bb7aa26198f1
b6f91e77ef4effe305d2c7c0fc8bcd06cda7761d
32dd379f30a1a1864633a6133ed98e38eb5d6b3f
7ab19ec5a1080c3c68baca6e3a1ab09aa4ee60fd
b93e1dcd15400725904ec3e68a02bada11c80d69
6192153da9accb152737ea57ef6465b5bed97830
e5c7800b096a4b9fd03490de939e1f26c776123e
7c88d85ca8c513f0fe967f91f4ea64d8f63d0aee
e4dc8227ae1e28ef7f49d0903d057c7f7912ca27

This bug was referenced in samba v4-10-test (Release samba-4.10.18):

e3e816443470860a93793117b26328d2ebaa36a6
0b45e084a450fe5e44904c0e4b9e2517f26c5336
520216a051a7fc0c4e2ef20b988c36d5d4a178f7
8aa00858571f69c084d7fb3847d994acf683d764
36824951f3a5fb082c98051df6439402c13fac2a
1665085bb3a3050a6a51af8082dccde61a08ec57
bffdfb129cead0448ad233fd8b94da9e7fb5aeca
e799c47b6e0ec996099612a7f287888ed4d5559f
59f88cb36eb1ce7e53abf3b1d007b4625f35996c
b33d4dff5f5f32dfb316ec10108d5cb5c12f7986
1a1ecc5fc31aa8d00aa8b9ac03daf99375c54d17
bfb70388c1cdb39a460375fffa3714606498c533
6a6f64fc8c3c515294010b2876667a6e157a486b
912cc29a9950d6385f4e372b5141900f87a464b7
54fb5e12d6805e687e8840209a2d4af26294ee18
4c0ad865d400739106c624beb1494128f885fce6
4809d018dea336dd50e84f713778c53ed85fef20
a414d149503718650bf2bdd049a92b04472ef267

This bug was referenced in samba v4-11-test:

6941fa1ff8336af0f77728aaf8162b59aa704988
691d854c141cfe177f4c18ed045e38725504aaf3
f7b0e7a6dde36bd6721c7f8d926dfdd0d70ba68e
a71bc6c974db72fd3ef0a234fb9a0ef4fdc4d963
35277995d3977c37509ef072e6b5cc785ceb7ee2
13185dd83563cc7927a511f5d2a4a56cc2186743
fd05519caa2e738da317432371f42e4967514773
9b174d71541ec60157c17938551d8c9b429e578f
d5926ad40ffc31a9b0f6e2cb66d47aa58e1e5e4e
0da2f3e2455999cc30761a40715a1f1a88e1b725
f867164dc57b85c3c69b08be51c64aa430a23b2e
92d7e9f7f92f1ff225cd52fb24242a0f5d8f1d3d
c836fc24b9c11752581ac9d314ecdde80588aba2
5ee9480a89860d6906710fac39067e7d9db14feb
615cc75074b0f51734da261dc9b57ad209780e13
86c54d3a270ab984bfc7c7c0cc334210ed7956ce
572a41b24e7cb1b7d52f4021e0fef257cc0563eb
337e4da4daa564f90bfcde1bd8a30cb269fd54a9
db344db0efb0eff16211e6bb7dbf02501278c890

This bug was referenced in samba v4-12-test:

e862b4ce5678ce19d7d529fd76cfc4e67195ed10
d92c031f69afaaeef9a1f69d644301086d5cd964
daeb1bebcea08d2ce3467743fd092f1826c3fb6e
88d4e02c6b14c93b5b3fc0712416057989f63a11
0371ca12772e0ec8bd62810cf040cfd8e841116b
ef49b5d0911aae59cb4dad8bdcbd966d4167522b
e0e2d5911f554b4abe508283096fbd1b1e9698e4
0f4d98c1a2eb157677e16cf925e5095d481da8b1
dac81bdde6a881b09d6cb3191c119c87381a7c4a
e75cfccb1c5d91be12123f7e901a5111f1256352
1a03f0119144c8af8e89cdb7d0c3563be20c7a66
e4e0094fdbdf7b85da1cd10b78568801d0557b26
8c5940223e11eb926553f1a9642a4f7805686618
2462fa5f30e002e69bc3b6f75aafe0c720151769
f3f792b8eabe4fc833363d1e8159ffd754279f1f
a26ee2bf94a2d13a7fd31edd6a8e5d33e55fb0e2
512060e37ee996fc5a32dc374d7d47957c5081ef
3eeb5671b8076b22a67c34153d2f0899a02e7a88
04d316f3d510152c6ff052f62fa7eddd451a1b6b

This bug was referenced in samba master:

b813cdcac377210c3ab18e0d0a0c1a76870b1d74
355efadc6a18ffaaef2e4786e35e89780b10bccc
46642fd32d91b008615b859cfdf946f63b1ca0aa
caba2d8082d4b038aa59954b6e812612c2ecc0e1
74eb448adf7fb638fe925eab87a2dbfe9c002cc0
53528c71ffdb3377c4e73ac596c8507bc3898e83
d3123858fb59046e826cf2c7ec2a3839e6508624
d8a6e6549c185daa26852d6d85f475cddfb3083a
9ec8b59bdea19c99099a718ff9e04cd854563e11
82d41977a8bef426396e3e00833d55711a55f372
be8e63949908d8c10d490c8cd0119df4fb917eeb
f9b772bf286b7bde6a29cb8d7bbd241638daf5e7
ca8a0098ac207123a47b8b8f8602599d71d739db
9ef5b63e7a169154401e58f7a29ed25443e5318f
b74017d2dd15006f4bec899aa38191a3b44800e4
b8e4b0f4306e2d0b4b7c7c443d97abf46d7f9aca
d1790a0b5ae7160f6707c6c4fbf2217b251584ea
4b262b03e1e8285c399338895832a115953d3f23
9945f3e3548657c33cc2e5ef97eedd1dfe2edf71

We'll follow up with further hardening in
https://bugzilla.samba.org/show_bug.cgi?id=14501

Comment on attachment 16251 [details]
advisory v4

Advisory LGTM. Only one (minor) comment - in the sentence:

"Stefan Metzmacher made the changes to Samba 4.8 that preemptively
dodge this bug in default installs."

change "dodge" to "avoids" -> more professional language.

But not a mandatory change, it's OK as is if you want to ship :-).

Removing samba-vendor to avoid continued noise to that alias.

Vendors:  Please CC individually if you wish to continue to follow any developments here.  See also bug 14501 for further follow-up patches (likely additional automated tests at least).

Created attachment 16268 [details]
Backport for V4.4

Created attachment 16269 [details]
Backport for Version 4.5