[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future of kerberised telnet, login, rsh, ftp?
>>>>> "Brian" == Brian May <firstname.lastname@example.org> 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
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
However, some commands don't require the check_login "symbol", these
ALLO (it returns a message that it was ignored)
STAT (if filename not given)
NOOP (prints successful message)
error (not sure what this is)
(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
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:
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 <email@example.com>