Bug 14642 (CVE-2020-17049) - MS CVE-2020-17049 in Samba [SECURITY] 'Bronze bit' S4U2Proxy Constrained Delegation bypass
Summary: MS CVE-2020-17049 in Samba [SECURITY] 'Bronze bit' S4U2Proxy Constrained Dele...
Status: ASSIGNED
Alias: CVE-2020-17049
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.13.4
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
URL: https://blog.netspi.com/cve-2020-1704...
Keywords:
Depends on: 14817
Blocks: 14079
  Show dependency treegraph
 
Reported: 2021-02-16 22:10 UTC by Andrew Bartlett
Modified: 2021-09-15 08:55 UTC (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Andrew Bartlett 2021-02-18 02:21:06 UTC
Because Samba doesn't implement "Protected Users", and only implements constrained delegation in terms of the service that can be delegated to, the remaining issue appears to be that UF_NOT_DELEGATED is not honoured. 

UF_NOT_DELEGATED controls the forwardable flag in the ticket, which is used to work out if this particular user should not be open for constrained delegation. 

Does anybody else have a different reading?
Comment 2 Andrew Bartlett 2021-02-18 02:37:42 UTC
Isaac,

I think I understood the plan to be for Heimdal and MIT Kerberos to start to match Windows and issue a PAC for all S4U2Self tickets and to include a signature over the whole ticket (including flags) in that PAC.

That will, as with Windows, prevent modification of the forwardable flag, or anything else for that matter.

Can you write up the plan with a focus for particular things I can do to progress this, at least for Heimdal (as this is the production KDC for now in Samba).

In another place you said it was 'just a bunch of work' but I'm not clear exactly what remains to be done so I'm lost as to being able to assist.

I don't mind if that advice is either on the MR or this Samba bug.

Thanks!
Comment 3 Greg Hudson 2021-02-18 04:19:20 UTC
> I think I understood the plan to be for Heimdal and MIT Kerberos to start to match Windows and issue a PAC for all S4U2Self tickets

For all tickets, unless turned off by realm configuration, request padata, or the server DB entry.  There is no way to tell whether a ticket will be used as an S4U2Self evidence ticket, and that's where we need the signature.
Comment 4 Isaac Boukris 2021-02-18 10:05:31 UTC
(In reply to Andrew Bartlett from comment #1)

The main issue is that UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION flag (set via samba-tool on an account) has no real effect because it can be forged.  That and the UF_NOT_DELEGATED you mentioned, as the both use the same mechanism, that is the forwardable flag.

How about a call to sync on this?
Comment 5 Andrew Bartlett 2021-09-03 20:07:09 UTC
We don't seem to be trying to keep the fact that we are working on this very private for various good reasons, including in particular the need to land intrusive patches in the upstream projects.

Given all that should we just make this bug public?
Comment 6 Isaac Boukris 2021-09-05 17:05:56 UTC
(In reply to Andrew Bartlett from comment #5)

> Given all that should we just make this bug public?

This has been made public as a protocol defect, so yeah we should make this bug public IMO.
Comment 7 Andrew Bartlett 2021-09-05 22:01:41 UTC
Thanks, I agree.  

As the patches and tests for this are being developed in public and will be landed in master first, a private bug is not as useful.  Removing embargo.
Comment 8 Samba QA Contact 2021-09-15 08:55:12 UTC
This bug was referenced in samba master:

4ba5e82ae53410ec9a0bc7d47b181a88c15d9387
a5186f92803009c81eca2957e1bf2eb0ff7b6dff
0e99382d73f44eed7e19e83e430938d587e762d0
c9fd8ffd8927ef42fd555e690f966f65aa01332e
943079fd94fec66cdc2ba4ea1b2beb2971473004
a99a76722d6046a5d63032e3d2bb3f791da948a6
c2bbe774ce03661666a1f48922a9ab681ef4f64b
19a2af02f57d99db8ed3c6b028c3abdf4b553700
7bc52cecb442c4bcbd39372a8b98bb033e4d1540
a5bf7aad54b7053417a24ae0918ee42ceed7bf21
af633992e31e839cdd7f77740c1f25d129be2f79
3cc9e77f38f6698aa01abca4285a520c7c0cd2ac
ef5666bc51ca80e1acdadd525a9c61762756c8e3
35292bd32225b39ad7a03c3aa53027458f0671eb