 |  |
17.6. Printing Protocols
One specialized form of file transfer is printing, where you are sending files to a printer instead of to another general-purpose computer. Although people tend to think of printing as relatively safe, in fact, it involves most of the same risks as other file transfer protocols, and printers have most of the capabilities of other computing devices.You need to realize that many modern network printing devices respond to protocols other than the dedicated printing protocols discussed here. For instance, they may have administrative interfaces that use Telnet or HTTP; they may auto-configure interfaces with DHCP; they may accept file transfers via FTP; and they will certainly respond, not necessarily correctly, to at least some ICMP. These extra protocols may introduce entirely new classes of vulnerability. For instance, one plotter has a network interface that not only allows you to telnet to the plotter, but then allows you to telnet from the plotter to other hosts. (Apparently, the easiest way to get an intelligent interface was to simply take it, lock, stock, and barrel, from a network hub made by the same company -- except that a network hub can reasonably be expected to do this sort of thing, while few people suspect a plotter of also having network management capabilities and a guest login.) You should carefully examine the network capabilities and protections of printing devices before putting them on unprotected networks.
Because modern PostScript printers can be intelligent Ethernet devices with their own disks, it is theoretically possible for a rogue print job to turn one into a network sniffing device. In practice, this is a baroquely complex approach; attackers aren't very likely to succeed at it. However, more mundane denial of service attacks on printers are eminently possible and in fact have been known to happen.
Some are merely annoying, such as simply printing page after page of garbage (or, better yet, something offensive to the victim or the victim's coworkers) until the printer runs out of paper. But a few of them are serious, and the nastiest of them are enabled by a security feature in PostScript. PostScript was designed to protect certain dangerous commands by requiring a password before they were executed. This password is stored in an EEPROM chip on the printer and is factory-set to "0" on every brand of PostScript printer. It's always the same because it must always be the same. Some of the commands that the PostScript designers considered dangerous are routinely used by standard PostScript drivers, and if you change the password, those drivers will no longer work. Because, in order to reset it, you need either the old password or a hardware method to override the EEPROM, a program that uses the well-known "0" password to reset the password to something unknown can make printers effectively unusable until new EEPROMs are sent from the factory. (Some printers will run without the EEPROM, with an effective password of 0.) Removing or replacing the EEPROM resets not only the password, but also the printer ID and the page count; if you have fonts licensed to the printer, they will have to be relicensed. Since the last wave of such attacks, licensing of fonts to individual printers has become uncommon, reducing the attack's popularity. On the other hand, there are likely to be other, equally annoying PostScript attacks in the future.
The intelligence and vulnerability of PostScript devices makes it important to protect your printers from Internet access. Make sure you have blocked any remote printing protocols your machines and printers use. You will need to check every printer type and every machine type separately.
17.6.1. lpr and lp
The BSD lpr printing system is very similar to the BSD "r" commands (rsh, rlogin, rcp, rdump) discussed in Chapter 18, "Remote Access to Hosts". Unlike the "r" commands, lpr authorizes hosts, not individual users, and it will accept jobs from hosts in /etc/printers.equiv as well as /etc/hosts.equiv.There have been a number of security problems with lpr and its associated printing commands. Some of these are inherent in the design of lpr, which provides no user authentication and no data protection. Most of them, however, are implementation problems, including buffer overflows, printers, and spooling systems that crash on invalid or dubious input, and ways of using the printer system's administrative privileges to print out, overwrite, or delete files that would be otherwise inaccessible. Several lpr problems give remote attackers the ability to run any command as root. You should carefully limit access to lpr print servers and run current versions of the printing system.
The System V lp printing system doesn't really have a remote printing component. When it does remote printing, it usually does it by handing the job off to a BSD lpr printing system, or by using the BSD rsh command (which is often called remsh on System V systems because such systems have another program called rsh that does something else entirely).
When jobs are actually printed via lp or lpr, they are normally run through printer-specific filters, which translate the user-readable data into a format the printer will accept. Even when the printing system itself is secure, the printer filter can introduce new security problems. If you are accepting print jobs from possibly hostile sources, you should be extremely careful about the printer filters that you run and the permissions that they have.
17.6.1.1. LPRng
A freely available printing system called LPRng (for "lpr next generation"), originally designed by Patrick Powell, addresses a number of the problems with lpr. It adds support for both authentication and encryption of printer jobs, while still providing backward compatibility with lpr. It uses the same ports as lpr.
17.6.1.2. Packet filtering characteristics of lpr
lpr is TCP-based. Servers use port 515. Clients use random ports below 1024, just like the BSD "r" commands (for further information about the BSD "r" commands, see Chapter 18, "Remote Access to Hosts"). For historical reasons, some clients use ports only between 721 and 731 (this behavior is documented in the RFC that discusses lpr, but in practice few servers require it).| Direction | SourceAddr. | Dest.Addr. | Protocol | SourcePort | Dest.Port | ACKSet | Notes |
|---|---|---|---|---|---|---|---|
| In | Ext | Int | TCP |
<1024[77]
|
515 |
[78]
|
Incoming lpr, client to server |
| Out | Int | Ext | TCP | 515 | <1024[77] | Yes | Incoming lpr, server to client |
| Out | Int | Ext | TCP | <1024[77] | 515 | [78] | Outgoing lpr, client to server |
| In | Ext | int | TCP | 515 | <1024[77] | Yes | Outgoing lpr, server to client |
[77]May be restricted to 721-731.
[78]ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.
17.6.1.3. Proxying characteristics of lpr
lpr is a store-and-forward protocol, capable of being configured to do its own proxying. You can simply run a standard lpr configuration on your proxy server and configure it to drive whatever printers you like or pass jobs to another server. This does not provide security improvements over direct lpr, but it will let it cross a nonrouting host.
17.6.1.4. Network address translation characteristics of lpr
lpr does not use embedded IP addresses and will work with network address translation systems without problems. However, print jobs will normally contain information about internal hostnames.
17.6.1.5. Packet filtering and proxying characteristics of lp
lp itself provides no remote printing support. It handles printing across the network by using either rsh, which is covered in with the other BSD "r" commands, or lpr. To determine what your printer configuration is using, configure a remote printer and read its interface file (which is usually stored in /usr/spool/lp/interfaces/printername). Some vendors also provide novel remote printing systems for use with lp ; consult your vendor documentation for information.
17.6.2. Windows-based Printing
Windows operating systems use three main kinds of network-based printing protocols. Windows NT and Windows 95 and above are capable of using lpr as a network printing protocol. In addition, two Windows-native network printing protocols are based on SMB, a LanMan version (which uses specialized printing calls) and a CIFS version (which uses a named pipe into the spooler system and general transaction calls). These protocols have some special security implications in addition to the general issues with SMB. Most clients are set so that if a print server claims to have an upgraded version of a printer driver, the client will accept and run the new software. This is one of the few cases where a server can actually force a client to download and run arbitrary code via SMB without a user's consciously asking for something to be executed. While lpr outbound (from an internal client to an external print server) is relatively secure, outbound SMB printing is even less secure than inbound SMB printing.
17.6.3. Other Printing Systems
Given the deficiencies of both lp and lpr, many Unix vendors implement their own solutions to remote printing. Other platforms may support lp, lpr, a separate protocol, or some combination. Because it has its own protocol, which is somewhat easier to implement than rsh, lpr is more popular than lp on non-Unix systems, but many of them have their own protocols. Some printers are network devices in their own right, sometimes speaking lp or lpr directly, and sometimes (particularly older printers) speaking a protocol developed by the printer manufacturer.For the most part, the wide variety of other network printing protocols that are out there share a common feature; they're no more secure than lpr. Most of them are not even as secure as lpr (if you can reach the system with a print request in the right protocol, it will print it).
The IETF is working on a protocol called the Internet Printing Protocol (IPP), which is designed to be used across the Internet. This protocol is not yet in widespread use, although it is provided with Windows 2000 and is expected to become more popular as Windows 2000 comes into use. IPP is based on HTTP and may be run on the normal HTTP port or on port 631. IPP encryption is provided by running it over HTTPS instead of HTTP. Authentication may be provided either by using HTTPS with client certificates, or by using any HTTP authentication method. See Chapter 15, "The World Wide Web", for more information about HTTP and HTTPS.
Hewlett-Packard printers also support a network printing interface that has become a de facto standard, although it barely qualifies as a protocol. The printer accepts printer jobs on TCP port 9100, much the same way it would over a serial or parallel connection. Each TCP connection is a separate job, and the printer simply processes the data as it receives it, returning any error codes. This obviously provides no encryption or authentication.
17.6.4. Summary of Recommendations for Printing Protocols
|  | |
| 17.5. Summary of Recommendations for File Sharing |  | 17.7. Related Protocols |
