Re: Future of kerberised telnet, login, rsh, ftp?

[Brian May <bam@snoopy.apana.org.au>]

>>>>> "Brian" == Brian May <bam@snoopy.apana.org.au> writes:

    Brian> I don't use telnet, rsh, ftpd any more. I generally use
    Brian> ssh, sftp, etc instead. I feel safer using these tools,
    Brian> because I think security bugs will be found faster in ssh,
    Brian> as it gets more use, and hence more inspection, then the
    Brian> tools in Heimdal (not that openssh doesn't get its fair
    Brian> share of security bugs).

To expand on this, I remember looking at the code years ago, and found
parts of the code which I questioned security-wise, but got IIRC got
no response.

It concerned me for example that an attacker could inject an
non-encrypted (hence non-signed) packet to an ftp server, and have it
processed normally, despite encryption (whether safe,confidential,or
private) being turned on by the client.

In fact, my reading of the code suggests that ftpd works as follows:

1. ftpd.c:main calls yyparse()

2. yyparse calls yylex() to read the command and break it into tokens.

3. yylex() does not do any decrypting of the data or validation
   checking. It gets the string as is.

4. for every token it is passed to the grammar.

Some of the grammar rules require the check_login "symbol" which
requires the check_secure "symbol". It is here where it checks to
ensure the command was encrypted as required. It only makes this check
if the authentication process is complete. (I will assume that there
is nothing an attacker could by injecting commands before
authentication is complete because presumably the user isn't logged in
yet anyway).

However, some commands don't require the check_login "symbol", these
include:

USER
PASS
PORT
EPRT
TYPE
STRU
MODE
ALLO (it returns a message that it was ignored)
STAT (if filename not given)
ABOR (???)
HELP
NOOP (prints successful message)
FEAT
OPTS
SITE HELP
SITE IDLE
SITE URL
QUIT
error (not sure what this is)
REST
AUTH
ADAT
CCC
PROT

(I haven't researched the complete list of commands, some might be OK)

There are commands here which I consider a concern, for instance an
attacker could issue a PROT command and turn off all security. Or
there are many DOS attacks possible (e.g. login as another user).
(Note: the responses would still be encrypted if encryption is turned
on).

Note: The (AUTH,USER,*) command is required so the user can initially
login. However, it is also allowed, in insecure form, after a
connection has already been established.

5. The following commands don't check the check_login symbol but this
is OK, the command indicates encrypted data follows:

MIC
CONF
ENC

This data is decrypted and returned (via global buffer) in the next
call to ftpd_getline, and processed using the same grammar.


Disclaimer: None of this has been confirmed yet by anyone
else. However, *if* this is a valid security concern, and I found it,
how many other security issues might there be that I haven't found?

IMHO, the problem is that there is only one grammar, and it is used
for all connections, both encrypted and non-encrypted.


I seem to remember I had concerns with other programs, e.g. rsh (I
submitted patches to fix certain bugs), but I can't remember if any of
these concerns were security related.

It is another thing I prefer about ssh, security happens at the lowest
possible layer, so there is no chance an attacker can inject unwanted
data into the data stream.
-- 
Brian May <bam@snoopy.apana.org.au>