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 the module 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 Apache modules 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 CGI program or module, so weaknesses in Anyterm do not put your system at any higher risk than weaknesses in any other CGI program or module would.
The keystrokes sent to Anyterm may be encoded in the URIs that are requested by the browser. 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. (This is less of a problem with version 1.1.11 and newer, where POST requests are used by default; however, POST cannot be used with all browsers.)
The keystrokes and terminal contents that pass through the Anyterm module are potentially subject to snooping. For example, a process could attach to the shared memory region and observe the keystroke fifo and screen storage. This is possible even when SSL and/or SSH are being used.
In order to attach to the shared memory region a process needs to be running as the same user as the Anyterm module. This is why this is a particular concern, while it is not for a SSH daemon: Anyterm runs as your web server's user, as do other CGI programs. So 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 anygetty 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 fixed-size shared memory region is full.
Some way of reserving a number of sessions for priviledged users could be useful.
anygetty requires write access to utmp, the file that records who is logged in. Since anygetty (normally) runs as the same user as all other CGI programs and modules, this means thay any CGI program can alter utmp. The utmp man page contains the following warning:
"Warning: utmp must not be writable, because many system programs (foolishly) depend on its integrity. You risk faked system logfiles and modifications of system files if you leave utmp writable to any user."
The alternative is to make anygetty setuid or setgid. This could be more dangerous, since it means that any vulnerabilities in anygetty could be used to execute arbitary code with elevated priviledges. But perhaps simply making anygetty setgid to the group owning utmp is a safe option.
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 anygetty, 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_auth_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. However, versions of Anyterm before 1.1.11 did not support POST requests, or only supported them in a way that did not have this non-logging property. By default, 1.1.11 and newer do use POST requests, though this is configurable.
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 Anyterm's .htaccess file so that it sets this variable for Anyterm module accesses:
See the Apache documentation for more information.
Some of the risks can be reduced if your Anyterm installation runs in a separate HTTP daemon from your other web content - see the deployment page for some possible configurations. Specifically, the two servers can run as different users. This prevents CGI programs installed by other users or subverted by external attackers from snooping on the Anyterm activity. Beware of logging of proxied requests by the first server if you use that configuration.
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.