Bug 15045 - [SECURITY] UF_SMARTCARD_REQUIRED not consistently honoured
Summary: [SECURITY] UF_SMARTCARD_REQUIRED not consistently honoured
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.16.0rc5
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Jo Sutton
QA Contact: Samba QA Contact
Depends on:
Reported: 2022-04-13 03:53 UTC by Andrew Bartlett
Modified: 2024-03-11 22:13 UTC (History)
1 user (show)

See Also:

WIP patch for Samba (37.55 KB, patch)
2023-09-26 03:03 UTC, Jo Sutton
no flags Details
Patch for Heimdal (2.02 KB, patch)
2023-09-26 03:04 UTC, Jo Sutton
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Bartlett 2022-04-13 03:53:26 UTC
Samba (and perhaps windows) relies on the fact that passwords are randomised or blanked out when UF_SMARTCARD_REQUIRED is set.

This Bug to track hardening this so that we do not accept any password authentication, other than NTLM network logons (for legacy) no matter the passwords stored.
Comment 1 Jo Sutton 2022-04-20 00:14:25 UTC
Setting the UF_SMARTCARD_REQUIRED bit on an account randomizes the keys, but if the account password is set to a known value via kpasswd or LDAP, some of the intended restrictions can be bypassed:

* NTLM logins still work.
* Interactive SamLogons fail with NT_STATUS_SMARTCARD_LOGON_REQUIRED, but network logons presumably still work.
* Simple binds still work. On Samba with NT hashes disabled, simple binds fail due to the random AES256 keys generated in db-glue.c; this presumably increments the bad password count.
* An AS-REQ cannot be used to get a TGT. On Windows, this fails with a KRB5KDC_ERR_POLICY error. On Samba, assuming preauth is required (this is the case unless the 'require_preauth' KDC option is false and the client and server both have the UF_DONT_REQUIRE_PREAUTH flag set), this fails due to the random keys generated in db-glue.c preventing the KDC from decrypting the padata. This presumably means the bad password count is incremented in the Samba case.
* Existing TGTs can still be used (e.g. to get service tickets, as armor tickets, to use kpasswd).
* Existing service tickets can still be used (e.g. to connect to ldap:// on a DC).
* The account's password can be set or changed with the right permissions (using kpasswd or LDAP).
* SAMR password sets/changes presumably still work.
Comment 2 Jo Sutton 2022-09-08 02:04:22 UTC
Further research would be to find out whether tickets can be obtained using a smartcard and then used to change the account's password, given that attempts to obtain tickets using a password/enc-timestamp fail.
Comment 3 Andrew Bartlett 2023-09-26 02:50:41 UTC
I rate this as AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N (4.3)


That is, while it is not ideal, it requires that the user actively set a password on their account, and then pass that on to others.

Even if the user was an administrator, then:
AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N is 4.9.

Both are below our score for the private security process, in my assessment.
Comment 4 Jo Sutton 2023-09-26 03:03:29 UTC
Created attachment 18125 [details]
WIP patch for Samba
Comment 5 Jo Sutton 2023-09-26 03:04:07 UTC
Created attachment 18126 [details]
Patch for Heimdal
Comment 6 Andrew Bartlett 2023-09-26 03:11:33 UTC
Comment on attachment 18126 [details]
Patch for Heimdal

I don't think the Heimdal patch is correct.  Everything I can see so far suggests that the hwauth ticket flag (which this isn't, but is related to) is ill-defined, with some even suggesting that some it should only be set if a magic OID is in a certificate.

I think this came to Heimdal for MIT db compatibility more than anything else.

It could be added to upstream Heimdal, and they may choose to use it to enforce PKINIT, but that isn't a security-sensitive change, it can just go in if they agree, as a new feature, as it hasn't ever worked as far as I see. 

If Samba needs this, and this gives the right error compared with random keys, then great but we may not get it upstream.
Comment 7 Andrew Bartlett 2023-09-26 03:12:31 UTC
Comment on attachment 18126 [details]
Patch for Heimdal

See discussions like http://datwww.mit.edu/menelaus.mit.edu/krb5dev/20277
Comment 8 Jo Sutton 2023-09-26 03:18:14 UTC
(In reply to Andrew Bartlett from comment #6)
Well, I don’t know about the ‘hwauth’ ticket flag, but I’m pretty sure that patch, or something like it, is required to fix the Samba bug. The ‘require_hwauth’ flag is set by Samba in uf2SDBFlags() if the account requires a smartcard to log in.
Comment 9 Andrew Bartlett 2023-09-26 03:23:58 UTC
Comment on attachment 18125 [details]
WIP patch for Samba

Thanks for this.  This looks OK as a start.  The main thing to do first is to enforce that password sets and resets randomise, not just when initially setting UF_SMARTCARD_REQUIRED.
Comment 10 Andrew Bartlett 2023-09-26 03:25:04 UTC
(In reply to Joseph Sutton from comment #8)
Yes, and I think this can just go in as a fix for a feature that never really worked.  We could get a CVE if we want, but I don't think the security process is the best way to do this, it hasn't helped move this on so far, and we could have released 4.19 with this fixed, or at least progressed, otherwise.
Comment 11 Andrew Bartlett 2023-09-26 03:27:32 UTC
Also, on the seriousness of this bug, I would suggest that there are many, many ways to give another user access to your account, if you are determined, so this is not super-serious.
Comment 12 Jo Sutton 2023-09-26 03:36:38 UTC
(In reply to Andrew Bartlett from comment #11)
Is that all there is to the issue? I thought there might have been an exploit that allowed you to change your password after your account was set to require a smartcard (possibly using a ticket acquired before the account modification, without using the smartcard — but we’ve since locked down the kinds of tickets that can be used with kpasswd). If so, then it could be used to bypass UF_SMARTCARD_REQUIRED on your own account.
Comment 13 Andrew Bartlett 2023-09-26 03:44:44 UTC
(In reply to Joseph Sutton from comment #12)
Yes, which is why we get to 4.3, you could set a password and then use your account without your smart card. 

But while it makes the bit meaningless, it looks like it falls into this exception:


* Mitigated by the selection of strong passwords.

       We will not do a security release simply because weak passwords
       are permitted to be selected (eg our password policy tools fail
       to exclude all weak passwords) or a weak password can be brute
       forced online (eg avoiding a bad password lockout).

     These issues are real, important and should be backported to
     maintained releases, but do not justify the costs of coordinated
     disclosure or a seperate security release.
Comment 14 Andrew Bartlett 2024-03-11 22:13:14 UTC
Removing embargo so details are clear and public, as this does not meet the requirements for the security process.  We plan to start working on this shortly.