Le vendredi 23 mai 2025, 22:42:56 heure d’été d’Europe centrale Bastien Roucaries a écrit : > 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. I have changed the default to no and updated changelog and NEWS Could you check the language ? Thanks > > > > Regards, > > > > -Roberto
Attachment:
signature.asc
Description: This is a digitally signed message part.