Ticket History #2726: ftpd replies lose final character when encrypted.

From krb5-bugs-incoming-bounces@mit.edu Tue Sep 28 18:29:27 2004
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by krbdev.mit.edu (8.9.3p2) with ESMTP
id SAA29648; Tue, 28 Sep 2004 18:29:27 -0400 (EDT)
Received: from pch.mit.edu (localhost [127.0.0.1])
by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8SMTQZZ011466
for <krb5-send-pr@krbdev.mit.edu>; Tue, 28 Sep 2004 18:29:26 -0400 (EDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
[18.7.21.83])
by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id i8SLuCZZ010067
for <krb5-bugs-incoming@PCH.mit.edu>;
Tue, 28 Sep 2004 17:56:13 -0400 (EDT)
Received: from mxout1.cac.washington.edu (mxout1.cac.washington.edu
[140.142.32.134])i8SLuBof015921
for <krb5-bugs@mit.edu>; Tue, 28 Sep 2004 17:56:11 -0400 (EDT)
Received: from flwright.u.washington.edu (flwright.u.washington.edu
[140.142.14.163])ESMTP id i8SLuA4x025910
for <krb5-bugs@mit.edu>; Tue, 28 Sep 2004 14:56:10 -0700
Received: (from donn@localhost)i8SLuAbj016060;
Tue, 28 Sep 2004 14:56:10 -0700
Date: Tue, 28 Sep 2004 14:56:10 -0700
Message-Id: <200409282156.i8SLuAbj016060@flwright.u.washington.edu>
To: krb5-bugs@mit.edu
From: donn@u.washington.edu
X-send-pr-version: 3.99
X-Scanned-By: MIMEDefang 2.42
X-Mailman-Approved-At: Tue, 28 Sep 2004 18:29:22 -0400
Subject: ftpd GSS encrypted controls 1 char short.
X-BeenThere: krb5-bugs-incoming@mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: donn@u.washington.edu
Sender: krb5-bugs-incoming-bounces@mit.edu
Errors-To: krb5-bugs-incoming-bounces@mit.edu


University of Washington
(Any)
System: AIX flwright 3 4 00033194A400


FTP protocol control lines lose the last character when encrypted.
For example, we'll get "215 UNIX Type: L\r\n" when we should get
"215 UNIX Type: L8\r\n".

This seems to cause surprisingly little trouble, but we did have
one client that seemed to be having problems parsing the 227 PASV
response.
Monitor decrypted traffic from server.

*** appl/gssftp/ftpd/ftpd.c.dist Mon Sep 13 14:35:28 2004
--- appl/gssftp/ftpd/ftpd.c Tue Sep 28 12:32:28 2004
***************
*** 1852,1858 ****
int conf_state;

in_buf.value = in;
! in_buf.length = strlen(in);
maj_stat = gss_seal(&min_stat, gcontext,
clevel == PROT_P, /* private */
GSS_C_QOP_DEFAULT,
--- 1852,1858 ----
int conf_state;

in_buf.value = in;
! in_buf.length = strlen(in) + 1;
maj_stat = gss_seal(&min_stat, gcontext,
clevel == PROT_P, /* private */
GSS_C_QOP_DEFAULT,

On Tuesday, September 28, 2004, at 04:48 PM, Tom Yu via RT wrote:


Yes, I have had a chance to look at it more carefully and
I apologize for mischaracterizing the problem. It is actually
that ftpd doesn't send the terminal NUL byte in a gss_sealed
message -- in krb5-1.3.xx, when it used to in krb5-1.2.xx.

The application is a GSSAPI FTP proxy, that relays FTP protocol
from a localhost port to the remote FTP port and inserts GSSAPI
authentication and control channel encryption. We use it with
Microsoft Windows applications that do their own FTP, particularly
web development tools. The code certainly could have been written
to anticipate this change, but of course it wasn't and eventually
it uses the returned length when it appends the "\r\n".

Donn Cave, donn@u.washington.edu