https://www.rfc-editor.org/rfc/rfc8429.html tells us that arcfour-hmac-md5 is weak, however we will still offer it to clients unless: - AS-REQ the user is a protected user - TGS-REQ the service has set msDS-SupportedEncryptionTypes This needs to be flipped, to use arcfour-hmac-md5 the account should be specifically configured as needing it. This will make it slower to brute force service keys back to passwords (arcfour-hmac-md5 keys are not salted) and avoid attackers downgrading a connection to the weaker cryptosystem. All modern Kerberos libraries support stronger authentication types, since Windows 2008 in the MS ecosystem, so this would change things for Windows 2003 servers and Windows XP. The primary risk is that the server doesn't have the correct salt, but in a not-being-attacked operation the AES key would be returned anyway, needing the salt. We should invert the logic around msDS-SupportedEncryptionTypes to require to be set to ENC_RC4_HMAC_MD5 to support these target services.
Looking at how we might, in a pure Samba/Samba environment make progress here. In note that in source3/libnet/libnet_join.c we set: ctx->in.desired_encryption_types = ENC_CRC32 | ENC_RSA_MD5 | ENC_RC4_HMAC_MD5; #ifdef HAVE_ENCTYPE_AES128_CTS_HMAC_SHA1_96 ctx->in.desired_encryption_types |= ENC_HMAC_SHA1_96_AES128; #endif #ifdef HAVE_ENCTYPE_AES256_CTS_HMAC_SHA1_96 ctx->in.desired_encryption_types |= ENC_HMAC_SHA1_96_AES256; #endif We should change this to be only AES, we always require a Kerberos library that knows about AES, and we never want DES anyway. Is there every any reason to offer an encryption type lower than ENC_HMAC_SHA1_96_AES128? Do we need to be compatible with a FL2003 DC, and if so could we detect this somehow, rather than always populating an arcfour-hmac-md5 key?
For completeness, the source4 code does: rtn = samdb_msg_add_uint(remote_ldb, msg, msg, "msDS-SupportedEncryptionTypes", ENC_ALL_TYPES); with #define ENC_ALL_TYPES (ENC_RC4_HMAC_MD5 | \ ENC_HMAC_SHA1_96_AES128 | ENC_HMAC_SHA1_96_AES256)
Sorry for the noise, the lower bits don't matter for the encryption key selection, except that we will put weaker entries into a keytab that won't ever be sent by the KDC. The KDC will use other bits to indicate what encryption types to offer a session key to however. Even then, Samba will use the strongest key type supported by all parties.
Note that we already have a "kerberos encryption types" option... maybe we should use it in more cases...
I've been thinking about this more, and a few thoughts stand out. RFC 8429 does not give a guide as to which uses of RC4 are most at risk, it just warns that these and DES/3DES are not considered secure for new deployment. There are 3 use cases as I see it: - AS-REQ/AS-REP - user kinit - TGS-REQ/TGS-REP - get ticket for service - gss_wrap() - secured use of a service In all these cases, the KDC could certainly ban use of RC4/arcfour-hmac-md5, but absent a catastrophic attack that is worse than total failure to operate, we need to instead provide a mitigation approach, allowing the phase out or upgrade of impacted services. Looking at all 5 possible use cases: - if AS-REQ (pre-authentication) is vulnerable (if observed), we need to patch/configure the client to know never to attempt ENC-TS pre-authentication with it. We could disable that on the server, changing the meaning of msDS-SupportedEncryptionTypes to cover AS-REQ also. However the primary change should be to have the client move to AES. - if AS-REQ TS-ENC pre-authentication can be bypassed by an active attacker we should disable that on the server, unless overridden by msDS-SupportedEncryptionTypes. This seems unlikely in the short term. - if the AS-REP is vulnerable (to observation), likewise we could use msDS-SupportedEncryptionTypes. But this would only be returned if the client asked for it, and failed to select a newer encryption type, so the client configuration is the primary gateway. - if the ticket returned in the TGS-REP is vulnerable, then again msDS-SupportedEncryptionTypes should be updated, once the client is confirmed to have a more modern key type in the local keytab. We cannot presume to know what keys are in the keytab, nor if they are correctly salted. I discussed this with metze who mentioned that Samba and likely 3rd party products never update their msDS-SupportedEncryptionTypes after the join. We should have Samba routinely update SupportedEncryptionTypes, perhaps via netr_LogonGetDomainInfo(), and this might be what we do in response to this RFC. Essentially, there is very little, except perhaps in AS-REQ if we want to assert that in 2022 all Kerberos clients can do ENC-TS, including getting the salt correctly, to an KRB5_ENCTYPE_AES128_CTS_HMAC_SHA1_96 key. Finally, we should change Samba's tooling not to export keytab entries for anything other than the strongest key.
I've been looking over how, in a TGS-REP, we select the encryption type of ticket. This seems to be the most vulnerable point, and one where there is a good reason to tighten things up. The Kerberos ticket only needs to be readable to the target server, not the client. In Samba 4.5 (eg a version with the older Heimdal) we allow the client etypes to control this, and select the same type as the session key. In Samba master (eg a version with the modern Heimdal) we only use the strongest encryption type from the keys in our DB. This is via _kdc_get_preferred_key(), which is not subject to client input. Therefore Samba 4.15 and older are the most vulnerable to this concern, as a malicious client can get the KDC to issue a ticket encrypted with arcfour-hmac-md5, even if the server could have accepted an KRB5_ENCTYPE_AES128_CTS_HMAC_SHA1_96 key.
Created attachment 17534 [details] Patches for Heimdal that seem to be the upstream fix for selecting the strongest key Attached are the changes in upstream Heimdal that seem to have been why modern Heimdal will select the strongest key for the service ticket. This may be useful as part of a patch for Samba 4.15 and below.
(In reply to Andrew Bartlett from comment #9) https://gitlab.com/samba-team/samba/-/merge_requests/2459/commits Will the lower 4 patches from (https://gitlab.com/samba-team/samba/-/merge_requests/2459/commits) also help here?
(In reply to Stefan Metzmacher from comment #10) While these are clearly a good idea, I don't think so, at least at security-release urgency. A good kerberos target will be rotating passwords every two weeks so will pick up the strongest supported keys pretty fast, and on the flip side a malicious client wanting a weaker cipher could also just just leak the session key. I'm sceptical that there is a client that updates msDS-supportedEncryptionTypes but doesn't rotate the passwords. Much more of a concern to me are clients that don't set msDS-supportedEncryptionTypes and so only have a working key for arcfour-hmac-md5.
(In reply to Andrew Bartlett from comment #9) This part I've moved to bug 15214 For the this bug in particular, we are blocked in finalising patches by the issue described here: https://twitter.com/fabian_bader/status/1590432854399676416 https://lists.samba.org/archive/cifs-protocol/2022-November/003832.html As this is stopping us testing computer accounts set not to permit arcfour-hmac-md5.
The session key and ticket key logic in the KDC is intertwined, so mark this as part of bug 15214 and use the same CVE-2022-45141 for it.
https://twitter.com/fabian_bader/status/1590339101580222464 has more context on what users are seeing on Windows. We are waiting for this to settle down before we finalise Samba's choices here.
Sorry, it is CVE-2022-3938 that this is most linked with.
Opening these bugs to the public, and the core issue that triggered this is now described in a BlackHat Europe Presentation by Tom Tervoort, Principal Security Specialist at Secura.
Removing the embargo tag as the code and now a clear description is now public.
I believe this has since been fixed in Windows.
Time to go ahead and fix this?
(In reply to Demi Marie Obenour from comment #19) Bug 15237 is CVE-2022-37966 and reflects the MS fix you are referring to. This bug is more about broader ideas to move away from rc4-hmac/arcfour-hmac-md5, which is a longer term project and would require funding or donated development effort from an interested developer or employer.