| To: | krb5-bugs@mit.edu |
| From: | Miro Juri¹iæ <meeroh@meeroh.org> |
| Date: | Wed, 25 Aug 2004 02:08:52 -0400 |
| Subject: | 1.3.x ftpd breaks after "PASS" |
The ftpd in Athena 9.3 (which zacheiss tells me is 1.3.x) breaks after
seeing a PASS command with no arguments when using krb4 or gssapi auth.
To reproduce:
1. % ssh athena.dialup.mit.edu
2. % ftp -u ftp.dialup.mit.edu
ftp connects
3. > user foo
ftp responds: 331 Password required for foo. Password:
4. hit enter
ftp hangs
This is causing Fetch 4 to completely fail when using krb4 auth or when
using gssapi auth without forwardable tickets, because in those two
cases Fetch always sends a PASS command with no argument (I believe
Fetch does this to work around some unrelated bug in some other server
software).
According to zacheiss:
meeroh
--
<http://web.meeroh.org/> | KB1FMP
"Clue meter is reading zero." -- Alice
seeing a PASS command with no arguments when using krb4 or gssapi auth.
To reproduce:
1. % ssh athena.dialup.mit.edu
2. % ftp -u ftp.dialup.mit.edu
ftp connects
3. > user foo
ftp responds: 331 Password required for foo. Password:
4. hit enter
ftp hangs
This is causing Fetch 4 to completely fail when using krb4 auth or when
using gssapi auth without forwardable tickets, because in those two
cases Fetch always sends a PASS command with no argument (I believe
Fetch does this to work around some unrelated bug in some other server
software).
According to zacheiss:
Show quoted text
> As it happens, the ftpd in MIT krb5 1.3.x is doing something wrong; it
> looks like the problem is that ftpd.c:kpass() function calls
> krb5_get_in_tkt_with_password(), and in between 1.2.x and 1.3.x this
> was
> reimplemented in terms of the get_init_creds() API. Sending it an
> empty
> string for the password is causing it to call krb5_prompter_posix(),
> which the client isn't expecting, giving a stack trace like:
>
> (gdb) where
> #0 0xb745269e in __read_nocancel () from /lib/tls/libc.so.6
> #1 0xb73ef838 in _IO_file_read_internal () from /lib/tls/libc.so.6
> #2 0xb73eeb4e in _IO_new_file_underflow () from /lib/tls/libc.so.6
> #3 0xb73f124d in _IO_default_uflow_internal () from /lib/tls/libc.so.6
> #4 0xb73f0efd in __uflow () from /lib/tls/libc.so.6
> #5 0xb73e4eba in _IO_getline_info_internal () from /lib/tls/libc.so.6
> #6 0xb73e4db3 in _IO_getline_internal () from /lib/tls/libc.so.6
> #7 0xb73e3cac in fgets () from /lib/tls/libc.so.6
> #8 0xb757ba7d in krb5_prompter_posix (context=0x80b01e0, data=0x0,
> name=0x0, banner=0x0, num_prompts=1, prompts=0xbfff80e0) at
> prompter.c:84
> #9 0xb7560a24 in krb5_get_as_key_password (context=0x80b01e0,
> client=0x80b8510, etype=1, prompter=0xb757b840 <krb5_prompter_posix>,
> prompter_data=0x0,
> salt=0xbfff8590, params=0xbfff8580, as_key=0xbfff8570,
> gak_data=0xbfff8ab0) at gic_pwd.c:61
> #10 0xb7560250 in krb5_get_init_creds (context=0x80b01e0,
> creds=0xbfff9b60, client=0x80b8510, prompter=0xb757b840
> <krb5_prompter_posix>, prompter_data=0x0,
> start_time=0, in_tkt_service=0x80b7c68
> "krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU", options=0xbfff8680,
> gak_fct=0xb75608d4 <krb5_get_as_key_password>,
> gak_data=0xbfff8ab0, use_master=0, as_reply=0x0) at
> get_in_tkt.c:1026
> #11 0xb75616d7 in krb5_get_in_tkt_with_password (context=0x80b01e0,
> options=0, addrs=0x0, ktypes=0x0, pre_auth_types=0x0,
> password=0x80b7fb8
> "", ccache=0x80b8378,
> creds=0xbfff9b60, ret_as_reply=0x0) at gic_pwd.c:455
> #12 0x0804dcf5 in kpass (name=0x80b8148 "zacheiss", passwd=0x80b7fb8
> "")
> at ftpd.c:1009
> #13 0x0804df2d in pass (passwd=0x80b7fb8 "") at ftpd.c:1121
> #14 0x08052790 in yyparse () at ftpcmd.y:221
> #15 0x0804ce51 in main (argc=3, argv=0xbfffa354, envp=0xbfffa364) at
> ftpd.c:565
> looks like the problem is that ftpd.c:kpass() function calls
> krb5_get_in_tkt_with_password(), and in between 1.2.x and 1.3.x this
> was
> reimplemented in terms of the get_init_creds() API. Sending it an
> empty
> string for the password is causing it to call krb5_prompter_posix(),
> which the client isn't expecting, giving a stack trace like:
>
> (gdb) where
> #0 0xb745269e in __read_nocancel () from /lib/tls/libc.so.6
> #1 0xb73ef838 in _IO_file_read_internal () from /lib/tls/libc.so.6
> #2 0xb73eeb4e in _IO_new_file_underflow () from /lib/tls/libc.so.6
> #3 0xb73f124d in _IO_default_uflow_internal () from /lib/tls/libc.so.6
> #4 0xb73f0efd in __uflow () from /lib/tls/libc.so.6
> #5 0xb73e4eba in _IO_getline_info_internal () from /lib/tls/libc.so.6
> #6 0xb73e4db3 in _IO_getline_internal () from /lib/tls/libc.so.6
> #7 0xb73e3cac in fgets () from /lib/tls/libc.so.6
> #8 0xb757ba7d in krb5_prompter_posix (context=0x80b01e0, data=0x0,
> name=0x0, banner=0x0, num_prompts=1, prompts=0xbfff80e0) at
> prompter.c:84
> #9 0xb7560a24 in krb5_get_as_key_password (context=0x80b01e0,
> client=0x80b8510, etype=1, prompter=0xb757b840 <krb5_prompter_posix>,
> prompter_data=0x0,
> salt=0xbfff8590, params=0xbfff8580, as_key=0xbfff8570,
> gak_data=0xbfff8ab0) at gic_pwd.c:61
> #10 0xb7560250 in krb5_get_init_creds (context=0x80b01e0,
> creds=0xbfff9b60, client=0x80b8510, prompter=0xb757b840
> <krb5_prompter_posix>, prompter_data=0x0,
> start_time=0, in_tkt_service=0x80b7c68
> "krbtgt/ATHENA.MIT.EDU@ATHENA.MIT.EDU", options=0xbfff8680,
> gak_fct=0xb75608d4 <krb5_get_as_key_password>,
> gak_data=0xbfff8ab0, use_master=0, as_reply=0x0) at
> get_in_tkt.c:1026
> #11 0xb75616d7 in krb5_get_in_tkt_with_password (context=0x80b01e0,
> options=0, addrs=0x0, ktypes=0x0, pre_auth_types=0x0,
> password=0x80b7fb8
> "", ccache=0x80b8378,
> creds=0xbfff9b60, ret_as_reply=0x0) at gic_pwd.c:455
> #12 0x0804dcf5 in kpass (name=0x80b8148 "zacheiss", passwd=0x80b7fb8
> "")
> at ftpd.c:1009
> #13 0x0804df2d in pass (passwd=0x80b7fb8 "") at ftpd.c:1121
> #14 0x08052790 in yyparse () at ftpcmd.y:221
> #15 0x0804ce51 in main (argc=3, argv=0xbfffa354, envp=0xbfffa364) at
> ftpd.c:565
meeroh
--
<http://web.meeroh.org/> | KB1FMP
"Clue meter is reading zero." -- Alice