Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix KDC crash when logging PKINIT enctypes #981

Merged
merged 1 commit into from Sep 27, 2019

Conversation

greghudson
Copy link
Member

[It doesn't look like there's any existing way to send PKINIT enctypes in an AS or TGS request with the current code. I tested manually by changing krb5int_parse_enctype_list() to add the enctype I wanted.

While testing this I noted that new enctypes will generate strings like "DEPRECATED:(5000)" in the KDC log, because krb5int_c_deprecated_enctype() returns true for unknown enctypes. This requires some thought; an enctype we don't recognize could be either too old or too new to be on the list. PKINIT enctypes are also marked as deprecated because they were never in the libk5crypto list, and it's unclear whether this is correct.]

Commit a649279 introduced a KDC crash
bug due to transposed strlcpy() arguments. Fix the argument order.

This bug does not affect any MIT krb5 release, but affects the Fedora
krb5 packages due to backports. CVE-2019-14844 has been issued as a
result.

@frozencemetery
Copy link
Contributor

The "DEPRECATED" issue is interesting, but I think the only real worry is that we mark newer enctypes that way.

RFC 4556 section 3.1.4 says this about the pkinit enctypes:

The practice of assigning Kerberos encryption type numbers to indicate support for CMS algorithms is considered deprecated, and new numbers should not be assigned for this purpose. Instead, the supportedCMSTypes field should be used to identify the algorithms supported by the client and the preference order of the client.

But it follows that with:

For maximum interoperability, however, PKINIT clients wishing to indicate to the KDC the support for one or more of the algorithms listed above SHOULD include the corresponding encryption type number(s) in the etype field of the AS-REQ.

Does that meet the krb5 requirements for deprecation? It seems a little handwavy, but my feeling is yes. If not, it may be time to get started on an I-D for their explicit deprecation...

Commit a649279 introduced a KDC crash
bug due to transposed strlcpy() arguments.  Fix the argument order.

This bug does not affect any MIT krb5 release, but affects the Fedora
krb5 packages due to backports.  CVE-2019-14844 has been issued as a
result.

ticket: 8772
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants