Print job manipulation
If an attacker can alter print jobs, she fundamentally undermines trust. A user cannot be sure anymore if the document viewed on screen is the same as the hard copy emerging from the printer. The impact depends on the context of the print job and can range from simple pranks to serious business impairment. Two PostScript based techniques are discussed below.
Content Overlay
One simple way to manipulate the appearance of printouts is to use overlays. PCL has a documented function to put overlay macros on top of a document. Unfortunately, this feature is limited to the current print job and cannot be made permanent. PostScript does not offer such functionality by default, however it can be programmed into by redefining the showpage operator which is contained in every PostScript document to print the current page. The attacker can hook in there, execute her own code and then call the original version of the operator. Therefore she can overlay all pages to be printed with a custom EPS file. This hack can be used to add arbitrary graphics or fonts to hard copies of a document. It is handy to play pranks like putting `hax0r slogans` on all sheets – but also for legitimate tasks such as creating letterheads. Pranks range from occasional coffee stains on the sheets of a particular user to the simulation of a near empty toner cartridge. It is also possible to completely alter the appearance of a document by overlaying a blank page and then adding custom content. For a more advanced attack, imagine the victim wants to sell a good to the attacker. Both parties agree on a price and receive a digital copy of the sales agreement. As the attacker knows the exact location of the price in the document, by manipulating the victim's printer she can add a blank rectangle here, including a lower price. If the printout is not re-checked before the contract is signed, the victim might need a good lawyer. This attack works even if the contract document was digitally signed and verified by a print server, because the file itself remains untouched. Obviously, such an approach can only be successful if PostScript is used as printer driver and no StartJobPassword (see credential disclosure) is set.
How to test for this attack?
Use PRET's cross or overlay commands in ps mode, then disconnect and print an arbitrary document:
./pret.py -q printer ps Connection to printer established Welcome to the pret shell. Type help or ? to list commands. printer:/> overlay overlays/smiley.eps printer:/> cross whoa "HACKED" printer:/> exit
Who can perform this attack?
Anyone who can print, for example through USB drive or cable, Port 9100 printing or Cross-site printing.
Content Replacement
Even if an attacker can put an overlay above existing documents, she will not be able to alter specific values in the original document unless its exact structure is known. Sometimes we do not only want to add custom content, but to parse and replace parts of the existing document. Especially replacing text seems to be an attractive function, introducing new possibilities to the attacker as she can go for targeted manipulation or randomly transpose digits and introduce misspellings. The problem of replacing text in PostScript files can be reduced to the problem of extracting strings from the rendered document. This is not trivial, because strings can be dynamically built by the PostScript program itself. Hence, simple parsing and replacing within the document source code is not an option. This issue has been discussed by [1]. They use a PostScript interpreter with a redefined show operator to index documents for the New Zealand Digital Library Project (NZDLP). The show operator accepts a string as input, which is painted to a certain location of the current page. By redefining the operator, text can elegantly be extracted. We use this approach for targeted searching and replacing in strings immediately before they are painted. While this scheme sounds good in theory and was 'surprisingly effective on the 40,000 technical reports` [1] of the NZDLP, it depends on the PostScript code quality generated either directly by an application or by a printing system like CUPS. For example, the approach is successful for LaTeX based PostScript documents which are directly send to the printer while it fails for PostScript files generated by GIMP [2] which instead of strings creates raster graphics of their representation. The same issue occurs for any document format – even PostScript itself – when processed by CUPS. Theoretically such language constructs could also be parsed, this would however go beyond the scope of this work.
How to test for this attack?
Use PRET's replace command in ps mode, then disconnect and print a PostScript document containing ‘DEF’:
./pret.py -q printer ps Connection to printer established Welcome to the pret shell. Type help or ? to list commands. printer:/> replace "ABC" "DEF" printer:/> exit
Who can perform this attack?
Anyone who can print, for example through USB drive or cable, Port 9100 printing or Cross-site printing.
- ↑ 1.0 1.1 Extracting Text from PostScript, C. Nevill-Manning, T. Reed and others, 1997
- ↑ GIMP – GNU Image Manipulation Program, S. Kimball and P. Mattis
