Ticket History #6893: error codes from error responses can be discarded when there's e-data

From krb5-bugs-incoming-bounces@PCH.mit.edu Mon Apr 4 18:19:32 2011
Return-Path: <krb5-bugs-incoming-bounces@PCH.mit.edu>
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90])
by krbdev.mit.edu (Postfix) with ESMTP id 00CB03DED8;
Mon, 4 Apr 2011 18:19:31 -0400 (EDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id p34MJVCe006784;
Mon, 4 Apr 2011 18:19:31 -0400
Received: from mailhub-dmz-3.mit.edu (MAILHUB-DMZ-3.MIT.EDU [18.9.21.42])
by pch.mit.edu (8.13.6/8.12.8) with ESMTP id p34MA7wd005402
for <krb5-bugs-incoming@PCH.mit.edu>; Mon, 4 Apr 2011 18:10:07 -0400
Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU
[18.7.68.37])
by mailhub-dmz-3.mit.edu (8.13.8/8.9.2) with ESMTP id p34M9be9007597
for <krb5-bugs@mit.edu>; Mon, 4 Apr 2011 18:10:07 -0400
X-AuditID: 12074425-b7c8cae00000429f-24-4d9a41c532d9
Authentication-Results: symauth.service.identifier; spf=pass; senderid=pass
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP
id 21.2B.17055.5C14A9D4; Mon, 4 Apr 2011 18:10:14 -0400 (EDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com
(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p34MA5FX006461
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
for <krb5-bugs@mit.edu>; Mon, 4 Apr 2011 18:10:05 -0400
Received: from blade.bos.redhat.com (blade.bos.redhat.com [10.16.19.220])
by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
id p34MA4E3017700
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <krb5-bugs@mit.edu>; Mon, 4 Apr 2011 18:10:05 -0400
Received: from blade.bos.redhat.com (localhost.localdomain [127.0.0.1])
by blade.bos.redhat.com (8.14.4/8.14.3) with ESMTP id p34MAZ7n004279
for <krb5-bugs@mit.edu>; Mon, 4 Apr 2011 18:10:35 -0400
Received: (from nalin@localhost)
by blade.bos.redhat.com (8.14.4/8.14.4/Submit) id p34MAZGc004278;
Mon, 4 Apr 2011 18:10:35 -0400
Date: Mon, 4 Apr 2011 18:10:35 -0400
Message-Id: <201104042210.p34MAZGc004278@blade.bos.redhat.com>
To: krb5-bugs@mit.edu
Subject: error codes from error responses can be discarded when there's e-data
From: nalin@redhat.com
X-send-pr-version: 3.99
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileJIrShJLcpLzFFi42K52LJdRveY4yxfg7OdkhYND4+zOzB6NJ05
yhzAGMVlk5Kak1mWWqRvl8CV0T7jGXvBJf6KgwfvsjYw9vJ0MXJySAiYSLzv7mACsRkFvCXe
XD3ODhEXk7hwbz0biC0kcIJR4sIy5S5GLiB7I5PEoUN9TBDOEiaJF0uvM0I4QFWXj29gh3Ba
GSVa3y0Em8sioCLRf6GBGcTmFbCTOLn1MSuILSIgKvHy7zEWEFtYwE/i/NvTYHE2oN035p1i
hdgtJdF+aTrYHcwCLBJ/3mxggbhPXGLH9tNQt2pLNMyazDKBUXABI8MqRtmU3Crd3MTMnOLU
ZN3i5MS8vNQiXQu93MwSvdSU0k2MwEATYndR3cE44ZDSIUYBDkYlHt41L2b6CrEmlhVX5h5i
lORgUhLlneUwy1eILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK/1H6By3pTEyqrUonyYlDQHi5I4
73xJdV8hgfTEktTs1NSC1CKYLBMH+yFGGQ4OJQneUyCTBYtS01Mr0jJzSpDVcIIILpA1PEBr
ekEKeYsLEnOLM9Mhik4x6nK8uDVxH6MQS15+XqqUOG8QMO6FBECKMkrz4IaBkkb9////LzHK
SgnzMjIwMAjxAF0DDASEPCjpvGIUBwaAMK8zyBSezLwSuE2vgI5gAjqiWhnsiJJEhJRUAyP/
tcD10QKndI7Z1fdYL+/JPX3gX6RU2cvGY80LE6+nlmkXbzOsWWxz+7tsyZTN3G25i4sOxN54
43XpR4vMqqKIQwk9F7g3X83rmc2muvTzl5PzZlZ9191sfSabcT+vweGljIE7jGRehnpeX7lo
qrOs+4vGH1t/7JbidrlauCf3S/ntUrkoCwElluKMREMt5qLiRABvds+qFQMAAA==
X-Mailman-Approved-At: Mon, 04 Apr 2011 18:19:30 -0400
X-BeenThere: krb5-bugs-incoming@mailman.mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Reply-To: nalin@redhat.com
Sender: krb5-bugs-incoming-bounces@PCH.mit.edu
Errors-To: krb5-bugs-incoming-bounces@PCH.mit.edu



System: Linux blade.bos.redhat.com 2.6.38-1.fc15.x86_64 #1 SMP Tue Mar 15 05:29:00 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Architecture: x86_64

When a client chpw request elicits an error response, if the
error includes e-data, the server-provided error code is
discarded and KRB5KRB_AP_ERR_MODIFIED is returned. This can be
confusing if you're trying to diagnose a password-changing
error.
Arrange for a UDP server to responds to password change requests
with KRB5KRB_AP_ERR_REPEAT messages. If it includes any e-data
in the error messages, the client application will only get
KRB5KRB_AP_ERR_MODIFIED results from the password change
function.
This patch modifies the krb5int_rd_chpw_rep() so that it will
only return KRB5KRB_AP_ERR_MODIFIED if the length verification
fails and the response packet can't be parsed as an error
message.

Index: src/lib/krb5/krb/chpw.c
===================================================================
--- src/lib/krb5/krb/chpw.c (revision 24839)
+++ src/lib/krb5/krb/chpw.c (working copy)
@@ -111,15 +111,11 @@
if ((ret = krb5_rd_error(context, packet, &krberror)))
return(ret);

- if (krberror->e_data.data == NULL)
- ret = ERROR_TABLE_BASE_krb5 + (krb5_error_code) krberror->error;
- else
- ret = KRB5KRB_AP_ERR_MODIFIED;
+ ret = ERROR_TABLE_BASE_krb5 + (krb5_error_code) krberror->error;
krb5_free_error(context, krberror);
return(ret);
- } else {
- return(KRB5KRB_AP_ERR_MODIFIED);
}
+ return(KRB5KRB_AP_ERR_MODIFIED);
}

Are you actually seeing unframed KRB-ERROR responses with e_data? If so,
from what server, and what's in the e_data?

The intention of the code is to work around the specific interoperability
bug where an AD server returns an unframed KRB-ERROR message with no
e_data, which was a specific observed behavior. If there are servers
returning unframed KRB-ERROR messages with e_data, we need to figure out
how to process it. The current code intentionally treats the packet as
garbage (because plen is wrong and the circumstances don't meet the
specific interop workaround).

I think the correct way to handle an unframed KRB-ERROR response
containing e_data is to handle it as if it were a framed KRB-ERROR
response. Currently, that means ignoring the error code and instead
returning success with the numeric result code in the e_data.

Unfortunately, the way the code is currently structured, it would be a
little tricky to bypass the vno/ap_rep.length logic to get to the code for
handling a framed KRB-ERROR, so this will require some restructuring.

Refactor krb5int_rd_chpw_rep() and make it properly handle both framed
and unframed KRB-ERROR messages. Eliminate krb5int_rd_setpw_rep() and
krb5int_setpw_result_code_string() by making the chpw versions of
those functions handle RFC 3244 replies.


https://github.com/krb5/krb5/commit/328eb9db6a2b03f0724e9e5c3fa724bc5e30aaa4
Commit By: ghudson
Revision: 24899
Changed Files:
U trunk/src/lib/krb5/krb/chpw.c
U trunk/src/lib/krb5/krb/int-proto.h
U trunk/src/lib/krb5/os/changepw.c