[20554] in Kerberos_V5_Development
Re: KDC audit plugin potential use-after-free
daemon@ATHENA.MIT.EDU (Alexander Bokovoy via krbdev)
Wed Dec 10 02:30:55 2025
Date: Wed, 10 Dec 2025 09:30:42 +0200
To: Greg Hudson <ghudson@mit.edu>
Cc: =?utf-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCR0LDQutCw0L3QvtCy0YHQutC40Lk=?=
<skotttt228@gmail.com>,
krbdev@mit.edu
Message-ID: <aTkhovXe/xePOqtF@redhat.com>
MIME-Version: 1.0
In-Reply-To: <22c2f09d-b810-49b2-a597-c2ab780140b6@mit.edu>
Content-Disposition: inline
From: Alexander Bokovoy via krbdev <krbdev@mit.edu>
Reply-To: Alexander Bokovoy <abokovoy@redhat.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Срд, 10 сне 2025, Greg Hudson wrote:
>On 12/9/25 09:58, Александр Бакановский wrote:
>>Hello! While working with audit plugin I found 2 use-after-free issues
>
>I am always interested to hear about people's uses of the audit code.
>We never made it public, and I considered removing it a few years ago,
>but I decided to leave it in after learning that Oracle makes use of
>it in their fork.
FreeIPA uses audit plugins to provide counters for successful and
unsuccessful authentication attempts per client principal.
Samba AD uses audit plugins to do the same, reset or increase bad
password authentication counts per client principal.
While we can perform these through the policy plugin as well, audit
plugin usage seems a clearer place.
Heimdal version of Samba AD also performs extensive audit logging with
the data from the request, namely IP addresses, PA type, and some
internal information about the object used as a client principal. We
haven't ported this yet to MIT Kerberos version but plan to do so.
On FreeIPA side we were planning to add the same logging for different
events as well.
>>1. So right before passing a state.reply to a kau_as_req() audit function
>>it frees state.reply.enc_part.ciphertext.data so from the plugin side we
>>can use-after-free (which happened to me:))
>>https://github.com/krb5/krb5/blob/master/src/kdc/do_as_req.c#L334
>
>Out of curiosity, what interest does an audit module have in the raw
>ciphertext of the encrypted part of the reply?
>
>Regardless, I agree that the cleanup should be moved later. It's not
>safe to leave a dangling pointer inside a structure that continues to
>see use, especially by third-party code.
>>2. For TGS_REP there also an issue
>>https://github.com/krb5/krb5/blob/master/src/kdc/do_tgs_req.c#L1087 - here
>>reply.ticket is a reference to a ticket_reply
>>https://github.com/krb5/krb5/blob/master/src/kdc/do_tgs_req.c#L1125 - here
>>reply is passed to an audit plugin in a kau_tgs_req()
>>https://github.com/krb5/krb5/blob/master/src/kdc/do_tgs_req.c#L1129 -
>>cleanup happens here
>>
>>However from the audit plugin perspective ticket.enc_part is already free'd
>
>I'm not following this one. It seems like ticket_reply.enc_part is
>cleaned up after the last use of ticket and reply. au_state continues
>to be used after tgs_issue_ticket() returns, but it shouldn't
>reference any dangling pointers as au_state->reply is nulled at line
>1125. I can't get much from the stack traces in the valgrind output
>due to lack of debugging symbols.
>
>Is it possible you're seeing this with an older version of the code?
>1.20 had a similar pattern to the AS code, where
>ticket_reply.enc_part.ciphertext and reply.enc_part.ciphertext are
>cleaned up before a call to kau_tgs_req() with au_state->reply set to
>&reply.
>
>_______________________________________________
>krbdev mailing list krbdev@mit.edu
>https://mailman.mit.edu/mailman/listinfo/krbdev
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
