[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ctrl+C currupts FTP so it cannot decrypt messages
Problem appears on OSF/1 and Ultrix. Not tested yet on Linux. Heimdal 0.1m.
ftp> open snoopy.apana.org.au
Connected to snoopy.apana.org.au.
220 snoopy FTP server (Version 6.00+heimdal-0.1m) ready.
Trying GSSAPI...
---> AUTH GSSAPI
---> ADAT YIICXQYJKoZIhvcSAQICAQBuggJMMIICSKADAgEFoQMCAQ6iBwMFACAAAACjggF4YYIBdDCCAXCgAwIBBaEQGw5DSE9DQklULk9SRy5BVaIlMCOgAwIBAaEcMBobA2Z0cBsTc25vb3B5LmFwYW5hLm9yZy5hdaOCAS4wggEqoAMCAQOhAwIBAaKCARwEggEYX/a2HKQgOH5YJc5jsTlJ5C//C73b2v4lZusO/ekuPjsoO1pvpol2YQg6b/lkXFhfghaom3Bdmba8MPUyGEN0/KOM1aDokHkigsxrKzjKO0UaGy5Ld6PLRWAujF9Zz9kmyULYl9L/n2Lh7xO7nVysNpbtPvFwB9k/8+lQrhBmqUmvtkWBnFmcbBz/ZEyJBT+itF52/aSIaQiYTXE6qd/oCifjazxXsDhpqsKUsdWSMsnPZCfVweZazduhQ9RXonb//USqnsY2f3+YXYyXpckEON2o0rAHfBBMEfFFF72OArhd6Quevkr0orIeDxTELfPGlsF5VMtNS4Rlxhj2FKGs7VEH6odulVBis+jhb+1WgzvLHkDMDXFZnqSBtjCBs6ADAgEDooGrBIGoqPHNM/eUCUAsp3fVAVEBdYLrczLYR7NRruzOWVdpZB/dtk+MC/+UBIxRMPkrzqxAHEQzIDAhyedT0T2NIMpecc1qCRV3C/VrofyQFgeyRq8K2GI6EQU7md0LyCxFJhT4Je6EJt8OPDh+iy64o6tGmk8x4OXbuvm8/cpMBsUa67HjtW3h7RcIaT45ZoZsUjdJ3X+5RTzwm1oGnEWd4r4+Yfl4B1L95OR/
Authentication successful.
Name (snoopy.apana.org.au:bam):
---> USER bam
S:232-Linux snoopy 2.2.6 #2 Fri Apr 23 21:35:43 EST 1999 i486 unknown
S:232-
S:232-Copyright (C) 1993-1999 Software in the Public Interest, and others
S:232-
S:232-Most of the programs included with the Debian GNU/Linux system are
S:232-freely redistributable; the exact distribution terms for each program
S:232-are described in the individual files in /usr/doc/*/copyright
S:232-
S:232-Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
S:232-permitted by applicable law.
S:232 User bam logged in.
---> SYST
S:215 UNIX Type: L8
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> prot private
---> PBSZ 1048576
---> PROT P
S:200 Data protection is private.
ftp> hash
Hash mark printing on (1024 bytes/hash mark).
ftp> cd examples
---> CWD examples
S:250 CWD command successful.
ftp> get user.c
local: user.c remote: user.c
---> TYPE I
S:200 Type set to I.
---> EPRT |1|130.194.1.7|4683|
S:200 EPRT command successful.
---> RETR user.c
S:150 Opening BINARY mode data connection for 'user.c' (15025 bytes).
########
receive aborted
waiting for remote to finish abort
S:631 YEsGCSqGSIb3EgECAgIBAAD/////CS7nfiIRga/YA8QweETT0eXsFl5RntCMMjI2IFRyYW5zZmVyIGNvbXBsZXRlLg0KCAgICAgICAg=
S:631 YEsGCSqGSIb3EgECAgIBAAD/////ptrpwz5K5+Ib05qiTwcj6NqiIyBFwscvMjI1IEFCT1IgY29tbWFuZCBzdWNjZXNzZnVsLg0KAgI=
8192 bytes received in 13.7 seconds (597 byte/s)
ftp> dir
---> TYPE A
S:631 YEMGCSqGSIb3EgECAgIBAAD/////x9Gq7dHrKMnCY/d74RdfX1sf0+BbwYXIMjAwIFR5cGUgc2V0IHRvIEEuDQoEBAQE
---> EPRT |1|130.194.1.7|4688|
S:631 YEsGCSqGSIb3EgECAgIBAAD/////sLPsue7Fq1QmFba2gGvsJC8g8hZ/C/0mMjAwIEVQUlQgY29tbWFuZCBzdWNjZXNzZnVsLg0KAgI=
ftp>
getreply() calls sec_read_msg() to decrypt message.
sec_read_msg() calls base64_decode() - I think this is OK.
sec_read_msg() calls gss_decode() (indirectly via pointer).
gss_decode() calls gss_unwrap(), which appears to return at this point:
if (memcmp (p, seq_data, 8) != 0) {
return GSS_S_BAD_MIC;
}
gss_decode() returns -1
sec_read_msg() returns -1
getreply() ignores the error and continues to process it.
Big Question: What could currupt the program state in such a way to do
this for all subsequent calls to the decryption routine? What is the
GSS_S_BAD_MIC error?
Smaller detail: getreply should probably detect the error, and change
lead string from S: to !!: to indicate that the message wasn't
decrypted (this already occurs when the message received is not
decrypted when it should have been - why isn't the reponse
ignored altogether?).
--
Brian May <bmay@csse.monash.edu.au>