Le vendredi 23 mai 2025, 21:34:26 heure d’été d’Europe centrale Roberto C. Sánchez a écrit : > 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?
Bookworm was fixed by PU > > 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'. Agreed with this > 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. Already done But will prefer to put default to false <= bulleyes > > So, if you still think that this worth tackling then I recommend > contacting the maintainers and starting the conversation with them. > > Regards, > > -Roberto
signature.asc
Description: This is a digitally signed message part.
