This fallback in krb5_rd_req_ctx(): /* If caller specified a server, fail. */ if (service == NULL && (context->flags & KRB5_CTX_F_RD_REQ_IGNORE) == 0) goto out; /* Otherwise, fall back to iterating over the keytab. This * have serious performace issues for larger keytab. */ o->keyblock = NULL; means that the kpasswd service will try many inappropriate keys to decrypt the ticket supplied to it. For example, it will accept a ticket encrypted with the Administrator's key, when it should rather accept only tickets encrypted with the krbtgt's key (and not an RODC krbtgt).
To be clear, as I understand it, the issue is that the keytab being iterated over is the HDB backed emulated keytab, which contains all the keys in the domain, so every account including all user accounts would be considered. From that point, building a ticket with a forged PAC to allow a password reset would be trivial.
I haven't tested it, but I suspect it might also be possible to submit password change requests for other users in this way, and thus gain access to their accounts.
(In reply to Joseph Sutton from comment #2) Yes, the security of Kerberos services absolutely depends on the decryption key being secret between the KDC and service, otherwise everything in the ticket can be forged.
This appears to be avoided in upstream Heimdal by: commit 1d845628863531fb967689943e1634a0579cfbaa Author: Love Hornquist Astrand <lha@h5l.org> Date: Tue Oct 15 12:40:39 2013 +0200 add HDBGET: that only supports get, iteration doesnt really make sense for the HDB keytab except when dumping Sadly we didn't notice this change (which looks like it might have been a silent security fix upstream). Thankfully the fix will therefore be trivial (to use HDBGET: not HDB:)
(In reply to Andrew Bartlett from comment #4) Thanks, that seems to do the trick. That would also explain this comment on a Heimdal PR: https://github.com/heimdal/heimdal/issues/334#issuecomment-330072922
Unfortunately, HDBGET isn't enough to solve the problem. If an attacker sets the sname of the ticket to the principal of the user whose key is used to encrypt it, and sets the enc-part kvno to the user's current kvno, kpasswd will still decrypt and accept the ticket.
That behaviour is due to these lines in gensec_krb5.c, which mean we pass a NULL server principal into krb5_rd_req_ctx(). if (keytab->password_based || obtained < CRED_SPECIFIED) { /* * Use match-by-key in this case (matches * cli_credentials_get_server_gss_creds() * behaviour). No need to free the memory, * this is handled with a talloc destructor. */ server_in_keytab = NULL; }
(In reply to Joseph Sutton from comment #7) Thanks so much for your cautious and careful examination of my assumptions and assertions. This is so very much appreciated.
There is also a possible bug here related to the kvno. hdb_get_entry() always passes HDB_F_KVNO_SPECIFIED when it calls hdb_fetch_kvno(), assuming to have received a definite kvno, but get_key_from_keytab() will send 0 as an 'I don't know' value if the enc-part didn't specify one. If the guess of 0 was incorrect, samba_kdc_message2entry_keys() won't return any keys. We'll have to ensure not to accept just any kvno here, or we'll erroneously accept tickets from the RODC.
I also saw this, but as a DoS problem in a domain with ~ 300000 users.
(In reply to Joseph Sutton from comment #9) I guess we can use HDBGET with a principal we constructed and then copy the keytab to an MEMORY keytab and pass that to cli_credentials_set_keytab_name()
(In reply to Stefan Metzmacher from comment #11) I also guess we might have a similar problem in the MIT KDC
(In reply to Stefan Metzmacher from comment #11) Thanks. I suppose we would do that only for the kpasswd service (in kpasswd_process()), rather than in the gensec layer (in gensec_krb5_update_internal())?
(In reply to Joseph Sutton from comment #13) Yes. Or the add a new HDB:samba4-kpasswd that will force principal name Can has a modified version of hdb_samba4_create_kdc(), where the hdb_samba4kpasswd_firstkey() and hdb_samba4kpasswd_nextkey() just return not found. And hdb_samba4kpasswd_fetch_kvno() calls hdb_samba4_fetch_kvno() with a fixed principal and no explicit kvno, so that we only ever allow kpasswd with the latest keys.
(In reply to Stefan Metzmacher from comment #12) I can confirm this issue also affects the MIT KDC. The difference is that the principal is looked up as a server (not as a client), so the KDC will only decrypt tickets encrypted to a service. I've included a test for this (test_kpasswd_wrong_key_server) in the patchset at https://bugzilla.samba.org/show_bug.cgi?id=15047, because it's simpler having all the kpasswd patches in one place.
Created attachment 17354 [details] Advisory draft #1 Added an advisory.
Comment on attachment 17354 [details] Advisory draft #1 This looks good (well, it looks bone-chilling, but a really clear read)
Assigning to Jule for the next security release.
Opening security bugs to vendors. Release date is currently proposed to be Wednesday 27 July but bug 15109 will be the authoritative reference on that.
This bug was referenced in samba v4-15-stable (Release samba-4.15.9): b0d3fd37a8884cf18f9c2bffc416035747d49977 e21702d20b6d4507708791c5a6a674b8bdadaab0 f4ea2a80d8440c4c7261229bd9285bce97226094 efb69ab420f2c5a3074fff6192fbc9a1cd387870 3bbb7bc57f0de9dfe8fa979b7e122cafc4f9c139 39db18962f5368957293cf678e4e7249a8b81ca8 3852adddff6df4d9f6f4cc1add11b06c272d29ef b9e880b3d9cf5666947cae60adc0846385b04f54 2815de0510e222bc93f5b602b2cdd5c51f8adeb4 e56d66f729ba1713e59b2fb938cc09e69831ac0e b2c3b060baedf638d7b8ee7f3b2bc1c7f9b695ac 6fc3d93b4fe81be8e8f134c46d461d5815edda91 2ee46c16d2aa706b686b50ccb66a2a3ad9852c50 b1003099c202d05b7d3f570fe313039aebdec3f9 38c83abffd325ee23649c190b8ffb3d27a2bdb68 481a70c37464d356f60a30c5f51ffae755c4e6f0 4b0304ab670a5dc3819f93633c190f722e3906d7 e21efbabccbf9c422347e9e94b3f217186556ee7 b64e1b4a510c81628feeb68af75afd3275ea75c3
This bug was referenced in samba v4-14-stable (Release samba-4.14.14): 1b38a28bcaebdae0128518605a422a194747a60f f6c5a60336de8fd67a2ef371dd2ee4cf75c53904 6305a55870287191ce4268f6af7fe278ca7f2a30 245d9a42329a1bfeb3db8431ef105e7758080e14 f7fad997cc06a14c9ffd101b26e16598f334148b 695c662bdc286d7a4699025f00656f8339ceecd8 ae7dd875cd4362ed4346716db493164c421b889f 13fe7e013eccca2c86258084f4443ddb7abaf089 5c41e20fae268e04aa05e821c7f388ea090727af 668825ad56ff70715c626bc3209a6868409e4969 cf2d5d2ab382ea31e2c14f2da3a575ef0857e126 450ff39d1c9f538bd828b7b2bee75c88d3dc1ee2 29ec8b2369b5f5e2a660a3165d2528982514a0f2 3a8da51396f3bf9d4caf8dbd4e75a0314aa47046 cf9e37604409ba0c3c5904af40beb2975c309ad4 cf749fac346ef59c91a9ea87f5e7ddec2e5649c7 42ba919c06c24c42ef123304de0c2ca8c689591a c0c4b7a4bd229bd36d586faec6249baaba8e7adc 340181bc1100fa31c63af88214a3d8328b944fe9
This bug was referenced in samba v4-16-stable (Release samba-4.16.4): f706dcd5ddc13f7e615a7d503420693d1ee45eb2 3bd5df466cb567be8c673eb20cfe903f1950a700 af53dbec65ca65030d4712acdabbb7505b811611 7c9faf1aacc3c22c0c1a44a7259ddd995bc26c4a a0efc5bc0aeff42563660cd68ba4dcb85d609bc6 7cc2b1ac55390cefca0644534939329b49a9535a 82bfffcdc3cd2ae5f71f5cc18bf862ac88ee038a 5f32710d6787bbf821a37f786a3e82360b7b7660 06c7f3d3f672646b2e0e556693df83761e8dc4e1 c84eb0e673640aeb391766bda50ec7649a75e4d9 4af9286727415485ae82fb68478753e70c0bbe6d 8a4f07c2ca2dc153a3c5fc635ac261d372c62fde 705e7ff46d61338e0529c2ac6ce2245d399d27d5 63d6af6ed70a0e9581f851c46c921f1024c7515d 99bbd95a1d6d96b33e9af310e8c0788440e51845 393c18b53ec88e18239b9fa2c1e6ef2009a75ad5 8d8ffbfc7b567622c5682866bfec650583d026f2 d03021791b8b51f45bfa9007a6b937f5eeba3d8a c9e1949fa8e14a3f2516abb439a2ba83dab418ce 7ee246ef9ca9c057779466bc9d0319606de46eff
This bug was referenced in samba v4-14-test: 1b38a28bcaebdae0128518605a422a194747a60f f6c5a60336de8fd67a2ef371dd2ee4cf75c53904 6305a55870287191ce4268f6af7fe278ca7f2a30 245d9a42329a1bfeb3db8431ef105e7758080e14 f7fad997cc06a14c9ffd101b26e16598f334148b 695c662bdc286d7a4699025f00656f8339ceecd8 ae7dd875cd4362ed4346716db493164c421b889f 13fe7e013eccca2c86258084f4443ddb7abaf089 5c41e20fae268e04aa05e821c7f388ea090727af 668825ad56ff70715c626bc3209a6868409e4969 cf2d5d2ab382ea31e2c14f2da3a575ef0857e126 450ff39d1c9f538bd828b7b2bee75c88d3dc1ee2 29ec8b2369b5f5e2a660a3165d2528982514a0f2 3a8da51396f3bf9d4caf8dbd4e75a0314aa47046 cf9e37604409ba0c3c5904af40beb2975c309ad4 cf749fac346ef59c91a9ea87f5e7ddec2e5649c7 42ba919c06c24c42ef123304de0c2ca8c689591a c0c4b7a4bd229bd36d586faec6249baaba8e7adc 340181bc1100fa31c63af88214a3d8328b944fe9
Removing vendor CC (so that any public comments don't need to be broadcast so widely) and opening these bugs to the public. If you wish to continue to be informed about any changes here please CC individually.
This bug was referenced in samba v4-16-test: f706dcd5ddc13f7e615a7d503420693d1ee45eb2 3bd5df466cb567be8c673eb20cfe903f1950a700 af53dbec65ca65030d4712acdabbb7505b811611 7c9faf1aacc3c22c0c1a44a7259ddd995bc26c4a a0efc5bc0aeff42563660cd68ba4dcb85d609bc6 7cc2b1ac55390cefca0644534939329b49a9535a 82bfffcdc3cd2ae5f71f5cc18bf862ac88ee038a 5f32710d6787bbf821a37f786a3e82360b7b7660 06c7f3d3f672646b2e0e556693df83761e8dc4e1 c84eb0e673640aeb391766bda50ec7649a75e4d9 4af9286727415485ae82fb68478753e70c0bbe6d 8a4f07c2ca2dc153a3c5fc635ac261d372c62fde 705e7ff46d61338e0529c2ac6ce2245d399d27d5 63d6af6ed70a0e9581f851c46c921f1024c7515d 99bbd95a1d6d96b33e9af310e8c0788440e51845 393c18b53ec88e18239b9fa2c1e6ef2009a75ad5 8d8ffbfc7b567622c5682866bfec650583d026f2 d03021791b8b51f45bfa9007a6b937f5eeba3d8a c9e1949fa8e14a3f2516abb439a2ba83dab418ce 7ee246ef9ca9c057779466bc9d0319606de46eff
This bug was referenced in samba v4-15-test: b0d3fd37a8884cf18f9c2bffc416035747d49977 e21702d20b6d4507708791c5a6a674b8bdadaab0 f4ea2a80d8440c4c7261229bd9285bce97226094 efb69ab420f2c5a3074fff6192fbc9a1cd387870 3bbb7bc57f0de9dfe8fa979b7e122cafc4f9c139 39db18962f5368957293cf678e4e7249a8b81ca8 3852adddff6df4d9f6f4cc1add11b06c272d29ef b9e880b3d9cf5666947cae60adc0846385b04f54 2815de0510e222bc93f5b602b2cdd5c51f8adeb4 e56d66f729ba1713e59b2fb938cc09e69831ac0e b2c3b060baedf638d7b8ee7f3b2bc1c7f9b695ac 6fc3d93b4fe81be8e8f134c46d461d5815edda91 2ee46c16d2aa706b686b50ccb66a2a3ad9852c50 b1003099c202d05b7d3f570fe313039aebdec3f9 38c83abffd325ee23649c190b8ffb3d27a2bdb68 481a70c37464d356f60a30c5f51ffae755c4e6f0 4b0304ab670a5dc3819f93633c190f722e3906d7 e21efbabccbf9c422347e9e94b3f217186556ee7 b64e1b4a510c81628feeb68af75afd3275ea75c3
This bug was referenced in samba master: b423c370b9b0f2350f0cc46f0bcb9a3ad57a0fe6 714cadfc4049454d76e37932377cfa3d9a6f464d f152afa74e8ea118e1ff1e526b3855aaaa5e575c ebccd0440aa6739a46e057dac738dc13a7d9a42a 48eb3354c5f823715755c74a96f34c7607e400d3 a5a2fc4259ccdd9409e604756e36ee380c30f896 888d58f43344afd6c199cd62be5e56f0f6174720 18bd6dafb576a58440d5c4ba6fff86dfe510bd98 332fd6032a8a9ccc482c5df4eff82a7d24e5a7ed 6a2ec50bfdb1b1178e764c6395e6220a1400c51f 4212037a6a37080206c8459920087b1a113c3fb5 192d597c2f2025845c3cd478fab9d72299c075bd 86698b313e74c37ba75da22d69b740b812b1c10c 1f7d94b5fcef8e2879f5fe19b9e2bbb979ab7a96 f89e5eff5f5c910b06fab3d1a57fabd53b66f9f0 4e2e767a78b5e94ecc8833ea6cd05f875c37dfed e0c135e6c146b4bbbfbf9642c1b9c2d05c091963 bbad8f1de43d643e20f1a71c3466f08ed7c9d480 827dc6a61e6bd01531da0cc8e10f1e54ad400359 484c6980befb86f7d81d708829ed4ceb819538eb 52dd9f8f835bc23415ec51dcc344478497e208c3
This bug was referenced in samba v4-17-stable: b423c370b9b0f2350f0cc46f0bcb9a3ad57a0fe6 714cadfc4049454d76e37932377cfa3d9a6f464d f152afa74e8ea118e1ff1e526b3855aaaa5e575c ebccd0440aa6739a46e057dac738dc13a7d9a42a 48eb3354c5f823715755c74a96f34c7607e400d3 a5a2fc4259ccdd9409e604756e36ee380c30f896 888d58f43344afd6c199cd62be5e56f0f6174720 18bd6dafb576a58440d5c4ba6fff86dfe510bd98 332fd6032a8a9ccc482c5df4eff82a7d24e5a7ed 6a2ec50bfdb1b1178e764c6395e6220a1400c51f 4212037a6a37080206c8459920087b1a113c3fb5 192d597c2f2025845c3cd478fab9d72299c075bd 86698b313e74c37ba75da22d69b740b812b1c10c 1f7d94b5fcef8e2879f5fe19b9e2bbb979ab7a96 f89e5eff5f5c910b06fab3d1a57fabd53b66f9f0 4e2e767a78b5e94ecc8833ea6cd05f875c37dfed e0c135e6c146b4bbbfbf9642c1b9c2d05c091963 bbad8f1de43d643e20f1a71c3466f08ed7c9d480 827dc6a61e6bd01531da0cc8e10f1e54ad400359 484c6980befb86f7d81d708829ed4ceb819538eb 52dd9f8f835bc23415ec51dcc344478497e208c3
This bug was referenced in samba v4-17-test: b423c370b9b0f2350f0cc46f0bcb9a3ad57a0fe6 714cadfc4049454d76e37932377cfa3d9a6f464d f152afa74e8ea118e1ff1e526b3855aaaa5e575c ebccd0440aa6739a46e057dac738dc13a7d9a42a 48eb3354c5f823715755c74a96f34c7607e400d3 a5a2fc4259ccdd9409e604756e36ee380c30f896 888d58f43344afd6c199cd62be5e56f0f6174720 18bd6dafb576a58440d5c4ba6fff86dfe510bd98 332fd6032a8a9ccc482c5df4eff82a7d24e5a7ed 6a2ec50bfdb1b1178e764c6395e6220a1400c51f 4212037a6a37080206c8459920087b1a113c3fb5 192d597c2f2025845c3cd478fab9d72299c075bd 86698b313e74c37ba75da22d69b740b812b1c10c 1f7d94b5fcef8e2879f5fe19b9e2bbb979ab7a96 f89e5eff5f5c910b06fab3d1a57fabd53b66f9f0 4e2e767a78b5e94ecc8833ea6cd05f875c37dfed e0c135e6c146b4bbbfbf9642c1b9c2d05c091963 bbad8f1de43d643e20f1a71c3466f08ed7c9d480 827dc6a61e6bd01531da0cc8e10f1e54ad400359 484c6980befb86f7d81d708829ed4ceb819538eb 52dd9f8f835bc23415ec51dcc344478497e208c3
Pushed to all relevant branches. Closing out bug report. Many thanks at all!