Re: krb5 review
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
Reply to: