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.

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.

I rate this as AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N (4.3)

https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N&version=3.1

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.

Created attachment 18125 [details]
WIP patch for Samba

Created attachment 18126 [details]
Patch for Heimdal

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 on attachment 18126 [details]
Patch for Heimdal

See discussions like http://datwww.mit.edu/menelaus.mit.edu/krb5dev/20277

(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 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.

(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.

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.

(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.

(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:

https://wiki.samba.org/index.php/Samba_Security_Process

* 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.

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.

I recently had the opportunity for a long video call with Microsoft, and the reasoning for the current windows behaviour is now clearer.

While it would be ideal to never allow the password to be set or changed to a known value, this is actually required by DPAPI on the windows client.

That is, the local keychain on Windows is secured by this password, and if the password can't be set back to a known-to-the-keychain value, then the keychain can become lost and unable to be recovered. 

(Yes, recovery is also possible by BackupKey, but this involves a distinct step reaching a full DC that may not be possible for the client at that time). 

So while the password and the smartcard could be considered distinct credentials that should not be able to replace each other, they are tied and represent the same user, so knowing the password is OK, as long as it doesn't unlock Kerberos or allow interactive logons.  

Essentially UF_SMARTCARD_REQUIRED really means 'smartcard required for Kerberos', with stronger security guarantees left to policies that disable NTLM. 

So, while Samba could deviate, the current behaviour should simply be documented (hence this comment) and we can look into it in the future if (as I have suggested) the PAC is extended to return the DPAPI key to the client as part of the single-shot Kerberos login exchange.

This bug was referenced in samba master:

dc6c4b215e2b191945f5ad0202133cd3c47925e6