On 2/19/26 14:29, Russ Allbery wrote: It's been some years since I've worked on Kerberos extensively, but I still maintain some Kerberos-related software and may be able to provide some context here. I have not been closely tracking developments in keyring formats and do not know how usable KEYRING caches are these days, so I may get some of these details wrong. Excellent, someone with more and/or more-recent knowledge on the topic!  :-) Jacob Bachmeyer<jcb62281 () gmail com> writes: On Thu, Feb 05, 2026 at 10:24:03AM +0100, Raul Vega wrote: The core of this vulnerability is a semantic failure in object lifecycle management. While the Kerberos protocol is syntactically secure, current Linux implementations fail to semantically bound the identity token (bearer ticket) to the process lifetime. Which process lifetime are we talking about here? My understanding is that the context of this report is services running with Kerberos credentials. [...]

[...]

In other words, this is a valid concern, but it's kind of a minor one. Having ticket caches lying around that live beyond the lifetime of the service creates some additional security risk, but in most cases it's less than the necessary security risk of having a keytab on the system that can be used to create new ticket caches at any time. [...] Exactly.  The risks here are already well-known; the report is bogus. [...] Arguable, but that is why you are supposed to invoke kdestroy in your logout script. A more typical design at institutions that use Kerberos heavily is to acquire Kerberos tickets on login via PAM (usually with sssd these days) and destroy them on logout via PAM as well so that users do not have to handle this in their shell files.

By weaponizing the "Crash and Trash" scenario, an attacker can transform a transient authentication secret into a persistent forensic artifact. This allows an unprivileged local attacker???or a remote attacker via an RCE/LFI chain???to bypass Kerberos protocol guarantees and achieve complete network-wide identity theft. Those are certainly all words. Some of them are even security-related. Exactly what LLMs are good at.  :-) [...] Exploitation: An LFI (Local File Inclusion) vulnerability in a web application can be used to "pull the trash" from /tmp, granting the attacker a valid TGT (Ticket Granting Ticket) with a ~10-hour TTL. Only if DAC is not being used properly.  If you are running a web application as root, you have bigger problems than stolen Kerberos tickets. I think the concern here is that the web application has its own tickets, which necessarily must be accessible to the web application. Therefore, if there is a vulnerability in the web application, that can be used to exfiltrate the Kerberos tickets for the web application.

Put that way, this is trivially and obviously correct. Maybe storing the tickets in a file in the file system makes it moderately easier to exfiltrate them given some sort of limited security flaw and keyring ticket caches might be less vulnerable, but this is highly speculative and depends on the exact nature of the vulnerability.

[...] 2. Memory Lifecycle Failure (Crash and Trash) When an application handling Kerberos authentication crashes, the system generates a core dump (if enabled).

The Semantic Gap: The credential remains in the heap or stack during the crash. Because many distributions do not restrict access to core dumps or leave them in unencrypted storage, these secrets become "trash" that is readily harvestable via standard string extraction. If, and only if, the application crashed during the authentication, or did not take proper steps to discard the credential after using it.  Again, this is (probably) an application bug, although I am not familiar enough with the Kerberos libraries to say what extent of care is taken to extinguish no-longer-needed in-memory copies of tickets. Yeah, this is just every piece of software in existence that manages its own secure credentials. The same can be said of software using X.509 credentials as well. If you want to use a differnet security system that stores all keys in a TPM, that may be the right choice in some security models, but that just means Kerberos is not a good fit for you.

Note that service tickets usually have much shorter lifetimes than TGTs, since they only need to be valid long enough to "run" from the KDC to the service, presenting the ticket at the latter. This varies a lot, and in my experience a more typical setup is for both TGTs and service tickets to have the same lifetimes. Regardless, though, for tickets for services that are managed externally, one can use a tool like kstart to regularly refresh the ticket cache, in which case you can set a short lifetime on both.

Or am I misremembering this part of Kerberos? If I remember correctly, stealing anything other than a TGT is useless, since service tickets are encrypted under a key in the TGT and contain a session key for talking to that service. No, this is not correct: If you have possession of the service ticket, you can authenticate as the user to that specific service. You do not need the TGT. Otherwise, limited ticket forwarding would not work.

-- Jacob