On Fri, May 23, 2025 at 02:20:15PM +0200, Bastien Roucaries wrote: > Hi, > > Can someone test and review krb5. > > I have done some test but idea are welcome. >
Hi Bastien, I have reviewed the patch for CVE-2025-3576 as you have backported it to bullseye. The patch itself looks good, and it appears that only minimal adaptations were required. However, I have many questions concerning the suitability of this change for LTS. I read the entire article by Tervoort, "Kerberos’ RC4-HMAC broken in practice: spoofing PACs with MD5 collisions". Based on having looked at the changes, reading about the mechanics of the exploit itself, and also the practical experience of Microsoft in dealing with this issue within their ecosystem, I am of the opinion that this might best be left unfixed. My rationale includes: - the impracticality of the attack itself - the very limited impact that can be achieved even if successfully exploited - the availability of a workaround - the possibility of fairly disruptive problems The impracticality and limited impact are not necessarily good justifications (on their own or even together) for not fixing this particular vulnerability, since over time bad actors could make the attack more practical and could discover ways to achieve more malicious effects. However, those two points do indicate that we have time to consider a thoughtful approach to this. If I read the article correctly, then a workaround does in fact exist today: a concerned administrator could simply configure a KDC to not make use of RC4 and MD5 for issuing tickets and to reject requests involving those same algorithms. For example, an administrator could configure the libdefaults configuration variable 'permitted_enctypes' to only include the AES types, which effectively defeats this attack. The author also linked to a news article describing some issues that Microsoft experienced related to the deployment of their mitigation for this CVE. This is notable because the Microsoft ecosystem is mostly closed, and Microsoft themselves exercise substantial influence over many facets of the systems that run their software. In the case of MIT Kerberos on Debian, we are not in such a position. This seems to me a reason to think that we face an even greater possibility of some sort of disruptive problem affecting users. Now, I don't think that all of that necessarily precludes deploying the fix for this CVE. However, I think it does require that it be done with great care. Because of the way that the fix is implemented upstream (default/forced disablement of certain ciphers, which can only be undone by explicitly setting a particular configuration value), this is not the sort of thing that we can consider for bullseye until it is in bookworm. To me, that specifically requires that the krb5 maintainers be in agreement with fixing this in bookworm and then landing the fix in bookworm first (since that it is already in unstable and trixie). Once that happens, then we can consider landing the fix in bullseye and older. Have you communicated with the maintainers of krb5 to know how they feel about fixing this in bookworm? Additionally, we need to consider whether (for the sake of compatibility) we should implement the fix but with the added change of treating the two new configuration values (allow_des3 and allow_rc4) as defaulting to 'true' rather than 'false'. I'm not entirely certain about the suitability of this (so a robust discussion is definitely required with a good representation of opinions), but the advantage of this is that while it leaves the default behavior as it currently is (i.e., allows the now deprecated algorithms), it provides a simpler/easier way for administrators to opt-out: by setting the new configuration variables to 'false'. This has the further advantage that administrators who choose not to do this (i.e., leave the default of 'true' for accepting these algorithms) end up getting opted-in during a subsequent upgrade to a newer krb5, and administrators who choose to do this (i..e., change the behavior to 'false' for rejecting these algorithms) are protected now and continue to be protected after upgrading. Naturally, this needs to be weighed against what other distros have done or plan to do. The information I could find (for RedHat and Ubuntu) indicates that neither of them have taken any action yet on this vulnerability. And, of course, the agreement of the krb5 maintainers would be just as important for going this route, as the fix would still need to land in bookworm first of all. If for some reason making any sort of change ends up not being feasible, then another possible avenue is to make the recommendation to update the configuration via a NEWS entry. This entry could be staged in debian/NEWS on the branches for bookworm, bullseye, etc., and then whenever the next fix is made that requires a DSA or DLA, that NEWS update would be included. So, if you still think that this worth tackling then I recommend contacting the maintainers and starting the conversation with them. Regards, -Roberto -- Roberto C. Sánchez
