RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2162455 - KDB: RC4 key creation not allowed in FIPS:AD-SUPPORT-LEGACY mode
Summary: KDB: RC4 key creation not allowed in FIPS:AD-SUPPORT-LEGACY mode
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: krb5
Version: 9.2
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Julien Rische
QA Contact: Filip Dvorak
URL:
Whiteboard:
Depends On: 2166603
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-01-19 16:06 UTC by Filip Dvorak
Modified: 2023-02-16 15:39 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-02-16 15:38:58 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FREEIPA-9364 0 None None None 2023-01-19 16:09:46 UTC
Red Hat Issue Tracker RHELPLAN-145821 0 None None None 2023-01-19 16:09:50 UTC

Description Filip Dvorak 2023-01-19 16:06:59 UTC 
Description of problem:
The creating KDC db via kdb5_util failed when the "arcfour-hmac" was used.

Version-Release number of selected component (if applicable):
RHEL-9.2.0-20230115.7
krb5-server-1.20.1-3.el9.x86_64
crypto-policies-20221215-1.git9a18988.el9.noarch

How reproducible:
always

Steps to Reproduce:
1.fips-mode-setup --enable
2.update-crypto-policies --set FIPS:AD-SUPPORT-LEGACY
3. set krb5

   sed -i "s/\[libdefaults\]/[libdefaults]\n default_realm = TEST.COM/" /etc/krb5.conf
   sed -i "s/\[realms\]/[realms]\n TEST.COM = {\n  kdc = $KDC_HostName\n  admin_server = $KDC_HostName\n }/" /etc/krb5.conf
   sed -i "s/\[domain_realm\]/[domain_realm]\n .$KDC_DomainName = TEST.COM\n $DKC_DomainName = TEST.COM/" /etc/krb5.conf

kdc.conf
master_key_type = aes256-cts-hmac-sha384-192
supported_enctypes = aes256-cts:normal aes128-cts:normal aes256-cts-hmac-sha384-192:normal aes128-cts-hmac-sha256-128:normal arcfour-hmac:normal

Actual results:
# kdb5_util create -s -P <passwd> -r <REALM> -k arcfour-hmac
Initializing database '/var/kerberos/krb5kdc/principal' for realm '',
master key name 'K/M@REALM'
double free or corruption (fasttop)
Aborted (core dumped)

Expected results:
KDC db should be created or there should be an error message "kdb5_util: Cryptosystem internal error"

Additional info:
Comment 4 Julien Rische 2023-02-01 10:27:16 UTC 
With krb5-1.20.1-5.el9, the error is a double free:

# /usr/sbin/kdb5_util create -s -P Secret123 -k arcfour-hmac
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'TEST.COM',
master key name 'K/M'
double free or corruption (fasttop)
Aborted (core dumped)

Here is valgrind output:

# valgrind --track-origins=yes --keep-stacktraces=alloc-and-free -- /usr/sbin/kdb5_util create -s -P Secret123 -k arcfour-hmac

...
==3559== Invalid free() / delete / delete[] / realloc()
==3559==    at 0x48470E4: free (vg_replace_malloc.c:872)
==3559==    by 0x48826B9: krb5_dbe_free_key_data_contents (kdb5.c:127)
==3559==    by 0x4883B06: krb5_db_free_principal (kdb5.c:844)
==3559==    by 0x1183F5: add_principal.constprop.0 (kdb5_create.c:476)
==3559==    by 0x118837: kdb5_create (kdb5_create.c:292)
==3559==    by 0x10E869: main (kdb5_util.c:344)
==3559==  Address 0x67a7260 is 0 bytes inside a block of size 42 free'd
==3559==    at 0x48470E4: free (vg_replace_malloc.c:872)
==3559==    by 0x48811C8: krb5_dbe_def_encrypt_key_data (encrypt_key.c:111)
==3559==    by 0x1184B4: add_principal.constprop.0 (kdb5_create.c:427)
==3559==    by 0x118837: kdb5_create (kdb5_create.c:292)
==3559==    by 0x10E869: main (kdb5_util.c:344)
==3559==  Block was alloc'd at
==3559==    at 0x484486F: malloc (vg_replace_malloc.c:381)
==3559==    by 0x4881105: krb5_dbe_def_encrypt_key_data (encrypt_key.c:92)
==3559==    by 0x1184B4: add_principal.constprop.0 (kdb5_create.c:427)
==3559==    by 0x118837: kdb5_create (kdb5_create.c:292)
==3559==    by 0x10E869: main (kdb5_util.c:344)
...
Comment 5 Julien Rische 2023-02-02 09:55:15 UTC 
I created bug 2166603 to handle the double free issue, which is different from:

kdb5_util create -s -P <password> -k arcfour-hmac-md5
Loading random data
Initializing database '/var/kerberos/krb5kdc/principal' for realm 'TEST.COM',
master key name 'K/M'
kdb5_util: Cryptosystem internal error while adding entries to the database

Encryption type arcfour-hmac-md5 should be supported for crypto-policy "FIPS:AD-SUPPORT-LEGACY".

This error is already happening with krb5-1.19.1-24.el9_1, but is hidden by the double free error with krb5-1.20.1-3.el9.
Comment 6 Julien Rische 2023-02-02 17:47:09 UTC 
The "Cryptosystem internal error" is due to the fact OpenSSL EVP fetching function for SHA-1, MD5, and MD4 are called with the default provider, which does not allow these digest algorithms in FIPS mode:
https://github.com/krb5/krb5/blob/krb5-1.20.1-final/src/lib/crypto/openssl/hmac.c#L106

#0  krb5int_hmac_keyblock (hash=hash@entry=0x7ffff7e89e60 <krb5int_hash_md5>, keyblock=keyblock@entry=0x55555558f530, data=data@entry=0x7fffffffdd40, num_data=num_data@entry=1, output=output@entry=0x7fffffffdd30) at openssl/hmac.c:177
#1  0x00007ffff7e7ac29 in usage_key (hash=hash@entry=0x7ffff7e89e60 <krb5int_hash_md5>, session_keyblock=session_keyblock@entry=0x55555558f530, usage=usage@entry=0, enc=0x7ffff7e89e80 <krb5int_enc_arcfour>, out=<optimized out>, out=<optimized out>) at krb/enc_rc4.c:64
#2  0x00007ffff7e80c1b in krb5int_arcfour_encrypt (ktp=<optimized out>, key=0x55555558f530, usage=0, ivec=0x0, data=0x7fffffffde60, num_data=<optimized out>) at krb/enc_rc4.c:178
#3  0x00007ffff7e7d71c in krb5_k_encrypt (context=context@entry=0x555555574e20, key=0x55555558f530, usage=usage@entry=0, cipher_state=cipher_state@entry=0x0, input=input@entry=0x7fffffffdf80, output=output@entry=0x7fffffffdf90) at krb/encrypt.c:72
#4  0x00007ffff7e7e518 in krb5_c_encrypt (context=context@entry=0x555555574e20, keyblock=keyblock@entry=0x55555556d630 <master_keyblock>, usage=usage@entry=0, cipher_state=cipher_state@entry=0x0, input=input@entry=0x7fffffffdf80, output=output@entry=0x7fffffffdf90) at krb/encrypt.c:91
#5  0x00007ffff7f9115d in krb5_dbe_def_encrypt_key_data (context=0x555555574e20, mkey=0x55555556d630 <master_keyblock>, dbkey=0x55555556d630 <master_keyblock>, keysalt=0x0, keyver=1, key_data=0x555555579000) at encrypt_key.c:109
#6  0x00005555555644b5 in add_principal (context=0x555555574e20, princ=<optimized out>, op=MASTER_KEY, pblock=0x55555556d5e0 <rblock>) at kdb5_create.c:427
#7  0x0000555555564838 in kdb5_create (argc=<optimized out>, argv=0x5555555758f0) at kdb5_create.c:292
#8  0x000055555555a86a in main (argc=<optimized out>, argv=<optimized out>) at kdb5_util.c:344

We should be using a lib-local OpensSSL context loading the legacy provider to fetch algorithms in this case.
Comment 7 Julien Rische 2023-02-03 17:40:26 UTC 
After fixing the MD5 digest fetching issue, the error remains, but is caused by a different call:
https://github.com/krb5/krb5/blob/krb5-1.20.1-final/src/lib/crypto/openssl/hmac.c#L156

#0  krb5int_hmac_keyblock (hash=hash@entry=0x7ffff7e89e60 <krb5int_hash_md5>, keyblock=keyblock@entry=0x55555558f120, data=data@entry=0x7fffffffdd30, num_data=num_data@entry=1, output=output@entry=0x7fffffffdd20) at openssl/hmac.c:188
#1  0x00007ffff7e7c3e9 in usage_key (hash=hash@entry=0x7ffff7e89e60 <krb5int_hash_md5>, session_keyblock=session_keyblock@entry=0x55555558f120, usage=usage@entry=0, enc=0x7ffff7e89e80 <krb5int_enc_arcfour>, out=<optimized out>, out=<optimized out>) at krb/enc_rc4.c:64
#2  0x00007ffff7e80dcb in krb5int_arcfour_encrypt (ktp=<optimized out>, key=0x55555558f120, usage=0, ivec=0x0, data=0x7fffffffde50, num_data=<optimized out>) at krb/enc_rc4.c:178
#3  0x00007ffff7e7d8cc in krb5_k_encrypt (context=context@entry=0x555555574e20, key=0x55555558f120, usage=usage@entry=0, cipher_state=cipher_state@entry=0x0, input=input@entry=0x7fffffffdf70, output=output@entry=0x7fffffffdf80) at krb/encrypt.c:72
#4  0x00007ffff7e7e6c8 in krb5_c_encrypt (context=context@entry=0x555555574e20, keyblock=keyblock@entry=0x55555556d630 <master_keyblock>, usage=usage@entry=0, cipher_state=cipher_state@entry=0x0, input=input@entry=0x7fffffffdf70, output=output@entry=0x7fffffffdf80) at krb/encrypt.c:91
#5  0x00007ffff7f9115d in krb5_dbe_def_encrypt_key_data (context=0x555555574e20, mkey=0x55555556d630 <master_keyblock>, dbkey=0x55555556d630 <master_keyblock>, keysalt=0x0, keyver=1, key_data=0x555555579150) at encrypt_key.c:109
#6  0x00005555555644b5 in add_principal (context=0x555555574e20, princ=<optimized out>, op=MASTER_KEY, pblock=0x55555556d5e0 <rblock>) at kdb5_create.c:427
#7  0x0000555555564838 in kdb5_create (argc=<optimized out>, argv=0x5555555758f0) at kdb5_create.c:292
#8  0x000055555555a86a in main (argc=<optimized out>, argv=<optimized out>) at kdb5_util.c:344

I suspect the EVP_MAC_fetch() call has to use a lib-local context with legacy provider too.
Comment 8 Julien Rische 2023-02-16 15:38:58 UTC 
We made a confusion in this bug: the test case shows that creating a KDB with an RC4 encryption type master key fails on RHEL9 in FIPS:AD-SUPPORT-LEGACY mode. This is the expected behavior, because RC4 is allowed in FIPS mode only for creating keys that are used as they are by Samba in some scenarios, but never used for actual encryption/decryption operations.

The "Cryptosystem internal error" raised when trying to create a KDB is not caused by the creation of the RC4 master key itself, but by the encryption/decryption of the KDB. This operation should remain impossible.
Note You need to log in before you can comment on or make changes to this bug.