- X Marks the Hole
- Law of the Jungle—Physical Security
- Physical Actions
- Selected Short Subjects
- Terminal Device Attacks
- Disk Sniffing
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.5 Terminal Device Attacks
DANGER LEVEL 
Several attacks are described here that assault either your terminal device itself or software associated with it, either present in the kernel or in xterm. The most severe of these, function key hijacking, while a threat on older UNIX systems and some modern UNIX systems, is not a threat on properly configured Linux systems. This is due to one of Linux's enhancements. These attacks are rarely seen but should be guarded against.
3.5.1 Function Key Hijacking
DANGER LEVEL
This threat is not a problem on a properly configured Linux box where each user's tty device is mode 620 (or 600) with a group of tty. The write command, which users may use to communicate with each other in real time, should be set-GID to tty so that it may initiate a conversation. It converts nonprintable characters to harmless printable sequences. If you make the mistake of allowing your tty device to be mode 622, the following attack is possible with some ancient serial CRT devices.
One of the helpful features of some serial CRTs is the capability to reprogram the function keys under software control. A simple sequence started with the Escape character would do the job. As you can see, another user could write to your tty device and program your function keys without your knowing it. This has been used to breach security. This would be as easy as reprogramming a function key to say
cp /bin/sh /tmp/.sh;chmod 4777 /tmp/.sh
It may require prepending this with the shell escape sequence of the victim's favorite editor and, possibly, also with what they expect the key to do. On some CRTs even the arrow keys and Insert/Delete keys are programmable. Some terminals also have an "Answerback" feature that is programmed with an escape sequence sent to the terminal. When a different escape sequence is sent to it, it will repeat the programmed sequence, without any of the terminal's keys being pressed. Thus, if this user's tty device allows writing (mode 622), any cracker with write capability, such as anyone with local write access, can "own" that user. If a cracker can "break" a CGI program to get this write access, this becomes a remote exploit. If that user is root, the machine is "owned."
The Linux console and xterm are not vulnerable to this programmable function key attack, but it would be a risk for those that use certain brands of actual terminals on serial lines. The only workarounds for those with susceptible terminals is to ensure that tty devices are mode 600, not the normal 622. This is discussed in "Stopping Access to I/O Devices" on page 268.
This will not prevent the reprogramming of function keys by an evil user before he logs out. This could be fixed in the "cl" (clear screen) variable (setting) in the termcap entry for each susceptible terminal used by your users. You would have the "cl" variable send the sequence appropriate for a particular terminal to reprogram its function keys back to normal. This string will be output when the system generates the login prompt for the next user.
3.5.2 Compose Key Vulnerability
DANGER LEVEL
The loadkeys program may be used to program the Compose key used to generate accented characters. Anyone who has read access to /dev/console may do this. Because there is only one set of keys for all the virtual consoles, these settings live beyond one logging out of /dev/console.
This does constitute a vulnerability. I do not know of a solution, short of a kernel modification or disabling logins on the console.
3.5.3 The xterm Change Log File Vulnerability
DANGER LEVEL
The section 4 manual page for console_codes states:
The program xterm (in vt100 mode) recognizes ...
ESC ] 4 6 ; name BEL
Change log file to name (normally disabled by a compile-time option)
This means that if this feature is not "disabled by a compile-time option," an escape sequence will switch the log file to name. Normally, it is disabled because it is so dangerous. All you need to do is to cat a file with these characters in it, causing them to be sent to the screen, and if someone evil created the file, they can overwrite any of the user's files.
The sparse documentation does not indicate if you need to enable logging initially. Although a search of related documentation did not find mention of a command-line flag or other way to enable logging under Linux, I have used this logging feature on some UNIX systems.
A quick test, using cat to send this escape sequence to the screen, did not seem to have this vulnerability. The exceptionally cautious will want to inspect the source that xterm was built with, and possibly even build it themselves.