Log In [secure]
Log In [http]
A Terminal Anywhere
This page is not intended to be a complete analysis of Anyterm's security implications. Rather, it just points out some of the more obvious issues and some ways of mitigating them. If you are aware of any other problems or solutions then do please get in touch.
Anyterm's code has not been audited for security. It is almost certainly possible to cause it to crash by sending it invalid input, and experience suggests that this sort of weakness can also be exploited to allow arbitary code execution.
Note that all CGI applications and similar programs are subject to this sort of problem, though some are better written than others. The Anyterm code does not run with a higher priviledge level than any other web application, so weaknesses in Anyterm do not put your system at any higher risk than weaknesses in any other web application would.
The keystrokes sent to Anyterm may be encoded in the URIs that are requested by the browser. (By default Anyterm uses HTTP POST requests, which are not logged, but POST cannot be used with all browsers.) So if Apache's logging is enabled, anyone with access to the log files may be able to observe the characters that were sent, including any passwords, even when an encrypted connection is used. Apache is normally configured so that logging is enabled and log files are world-readable.
The keystrokes and terminal contents that pass through the proxy server are potentially subject to snooping. For example, a user could attach a debugger to Apache. This is possible even when SSL and/or SSH are being used.
In order to attach a debugger a process needs to be running as the same user as Apache. This is why this is a particular concern, while it is not for a SSH daemon: A CGI program installed by a local user, or a vulnerable CGI program subverted by an external attacker, could be used to collect passwords.
When 'ssh localhost' or similar is used to log in, authentication is carried out after a session has been established. It is therefore possible for an attacker to deny legitimate access to a server by making many connections, until the limit on the number of sessions is reached.
The advantage of using authentication at the HTTP level is that it happens before the Anyterm code is executed at all. Using HTTP Auth is therefore an effective way of avoiding giving attackers access to potentially-vulnerable code and denial of service attacks. I recommend HTTP Auth for all Anyterm installations that offer login.
A practical drawback is that the username and password need to be entered twice, once to the HTTP Auth dialog and a second time to 'ssh localhost', and two password databases need to be maintained. The former problem is partially addressed by the %u expansion in anyterm_commnad; the latter can be solved by using mod_authnz_pam to implement HTTP Auth.
Normally, Apache does not log the data accompanying a POST request, so they are more suitable for sensitive data than the alternative GET requests. Anyterm does use POST requests except for some browsers where this is not possible.
To disable logging, first modify your Apache logging directives in your main Apache configuration so that they do not log if an environment variable (e.g. "DONTLOG") is set, as follows:
Then edit your server configuration so that it sets this variable for Anyterm module accesses:
See the Apache documentation for more information.
One strategy to reduce the threat of snooping is to use one-time passwords - this makes any snooped passwords useless to the attacker. The best-known one-time password system is OPIE, and it can be used in the PAM authentication framework. You can either print out a page of pre-computed one-time passwords, or use something like a PDA to compute them based on a challenge from the login program and a secret passphrase. A practical example of how to configure this would be welcomed.
Joining my.anyterm.org means that you don't need to install anything on your system: you point your browser at an Anyterm installation running on our server, from where you can SSH or telnet on to your own system. This eliminates the risks associated with installing new software on your own servers, though you do need to trust that we won't be reading your passwords.