Bug 1223802 (CVE-2015-3206)

Summary:	CVE-2015-3206 python-kerberos: checkPassword() does not verify KDC authenticity
Product:	[Other] Security Response	Reporter:	Martin Prpič <mprpic>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	abokovoy, jrusnack, rcritten, rmainz
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-07-09 21:28:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1223808, 1223809
Bug Blocks:	1223806

Description Martin Prpič 2015-05-21 13:17:59 UTC

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.

Comment 1 Martin Prpič 2015-05-21 13:24:24 UTC

Created python-kerberos tracking bugs for this issue:

Affects: fedora-all [bug 1223808]
Affects: epel-5 [bug 1223809]

Comment 2 Martin Prpič 2015-05-21 13:28:00 UTC

KDC support was implemented in pykerberos with:

https://github.com/02strich/pykerberos/commit/02d13860b25fab58e739f0e000bed0067b7c6f9c

Comment 5 Rob Crittenden 2015-07-09 20:58:16 UTC

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.

Comment 6 Kurt Seifried 2015-07-09 21:27:02 UTC

(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.

Comment 7 Kurt Seifried 2015-07-09 21:28:44 UTC

Statement:

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/.