The python-kerberos checkPassword() function does not verify that the KDC that it is authenticating with is the one that it intended to communicate with. This could allow a man-in-the-middle attacker to spoof a KDC when an application using python-kerberos attempts to verify a password via the checkPassword() function.
This issue is tracked upstream in https://www.calendarserver.org/ticket/833 , however it was resolved by documenting the shortcomings of the checkPassword() function: https://pypi.python.org/pypi/kerberos .
The pykerberos library (https://pypi.python.org/pypi/pykerberos), a fork of python-kerberos, does include KDC validation support. This change should be backported to python-kerberos to avoid various other application that rely on checkPassword() from having to replace the checkPassword() with a more secure alternative.
Created python-kerberos tracking bugs for this issue:
Affects: fedora-all [bug 1223808]
Affects: epel-5 [bug 1223809]
KDC support was implemented in pykerberos with:
Can someone explain what the security issue is?
It isn't like the password is sent in clear text, so no worries there.
All checkPassword() does is return a boolean yes/no, so at worst you get a bad answer back on whether the password is right or not. You'd get real confirmation if the user actually tried to do something with it.
In any case, the solution won't fix the majority of cases since it requires a keytab to do the verification. If a user already had a keytab why are they using a password? If they don't have a keytab, they probably don't have read access to /etc/krb5.keytab, so they're still hosed.
(In reply to Rob Crittenden from comment #5)
> Can someone explain what the security issue is?
> It isn't like the password is sent in clear text, so no worries there.
> All checkPassword() does is return a boolean yes/no, so at worst you get a
> bad answer back on whether the password is right or not. You'd get real
> confirmation if the user actually tried to do something with it.
The problem is we can't guarantee that, there are possible scenarios (unlikely, but not impossible) that could allow exploitation of this. Additionally this is a security feature that fails to work as advertised (e.g. similar to failing to do SSL hostname checks), thus qualifying for a CVE on both counts.
Having said all this, it is difficult at best to exploit and this issue will be closed as WONTFIX.
This issue affects the versions of python-kerberos as shipped with Red Hat Enterprise Linux 5, 6, and 7. Red Hat Product Security has rated this issue as having Moderate security impact. Additionally this issue is difficult to exploit in most common scenarios (due to the need for a valid Kerberos TGT)c For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.