Print Job Retention
From http://hacking-printers.net/wiki/index.php/Print_job_retention
Last updated
From http://hacking-printers.net/wiki/index.php/Print_job_retention
Last updated
Some printers have stored print jobs accessible from the web server. Usually however, job retention must be explicitly activated for a certain print job and can be done using standard PJL commands or proprietary PostScript code. Jobs are then kept in memory and can be reprinted from the control panel.
Legitimate job retention can be enabled for the current document by setting the PJL HOLD variable as shown below:
Hold jobs are kept in memory and can be reprinted from the printer's control panel. This feature is supported by various printers, however as it seems only some Epson devices allow permanent job retention beeing set using @PJL DEFAULT HOLD=ON.
How to test for this attack?
Use holdcommand from in pjl mode and to check if permanent job retention can be set:
PostScript offers similar functionality which however is model- and vendor-specific. For the HP LaserJet 4k series and various Kyocera printers, job retention can be enabled by prepending the following commands to a PostScript document:
How to test for this attack?
With the capability to hook into arbitrary PostScript operators it is possible to manipulate and access foreign print jobs. To parse the actual datastream send to the printer, one can apply a pretty cool feature of the PostScript language: to read its own program code as data using the currentfile operator. This way, the whole datastream to be processed by the PostScript interpreter can be accessed by reading and stored to a file on the printer device. If the printer does not offer file system access, captured documents can be stored in memory, for example within permanent PostScript dictionaries.
One practical problem is to decide which operator should be hooked as one does not gain access to the datastream until this operator is processed by the PostScript interpreter. As an attacker wants to capture print jobs from the very beginning, the redefined operator must be the very first operator contained in the PostScript document. Fortunately all documents printed with CUPS are pressed into a fixed structure beginning with currentfile /ASCII85Decode filter /LZWDecode filter cvx exec. Based on the assumption of such a fixed structure, the attacker can capture documents from the beginning and execute (aka print) the file afterwards. For printing systems other than CUPS this attack should also be possible, but operators need to be adapted. Note that the PostScript header which usually includes media size, user and job names cannot be captured using this method because we first hook into at the beginning of the actual document. Another generic strategy to hook into at the beginning of every print job is to set the BeginPage system parameter, if supported by the printer (most printer do). This vulnerability has presumably been present in printing devices for decades as solely language constructs defined by the PostScript standard are abused.
Now, print arbitrary documents (make sure PRET is disconnected to not block the printing channel). Afterwards, you can list, fetch or reprint captured documents:
While it is theoretically possible to permanently enable PostScript job retention using the operator, this setting is explicitly reset by CUPS at the beginning of each print job using << /Collate false >> setpagedevice. To counter this protection mechanism however, the attacker can permanently redefine the setpagedevice operator to have no effect at all.
Use holdcommand from in ps mode:
It is possible but uncommon to activate job retention in the printing dialog as discussed above. With PostScript however, one has complete access over the current print job and with the operator, it is even possible to break out of the server loop and access future jobs. Such functionality has the potential to capture all documents if PostScript is used as a printer driver.
Use capture command from in ps mode: