Print job manipulation - Revision history

84.153.135.135: /* Content Replacement */

2017-01-31T10:29:00Z

‎Content Replacement

Admin at 17:51, 23 January 2017

2017-01-23T17:51:27Z

Admin at 17:21, 23 January 2017

2017-01-23T17:21:29Z

Admin at 17:17, 23 January 2017

2017-01-23T17:17:34Z

Admin at 17:06, 23 January 2017

2017-01-23T17:06:32Z

Admin: Created page with "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 f..."

2017-01-23T17:05:25Z

Created page with "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 f..."

New page

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 [[PostScript#Operator redefinition|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 <ref name="nevill1997extracting">''[https://pdfs.semanticscholar.org/494d/24a72be788a91a6ca45373c2d33013f33395.pdf Extracting Text from PostScript]'', C. Nevill-Manning, T. Reed and others, 1997</ref>. 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` <ref name="nevill1997extracting"/> 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'' <ref>''[https://www.gimp.org/ GIMP – GNU Image Manipulation Program]'', S. Kimball and P. Mattis</ref> 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]].

----

@@ Line 25: / Line 25: @@
 == 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 ones does 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 <ref name="nevill1997extracting">''[https://pdfs.semanticscholar.org/494d/24a72be788a91a6ca45373c2d33013f33395.pdf Extracting Text from PostScript]'', C. Nevill-Manning, T. Reed and others, 1997</ref>. 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. This approach can also be used 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’ <ref name="nevill1997extracting"/> 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'' <ref>''[https://www.gimp.org/ GIMP – GNU Image Manipulation Program]'', S. Kimball and P. Mattis</ref> 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 and should be subject of further research.
+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 ones does 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 <ref name="nevill1997extracting">''[https://pdfs.semanticscholar.org/494d/24a72be788a91a6ca45373c2d33013f33395.pdf Extracting Text from PostScript]'', C. Nevill-Manning, T. Reed and others, 1997</ref>. 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. This approach can also be used 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’ <ref name="nevill1997extracting"/> 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 sent to the printer while it fails for PostScript files generated by ''GIMP'' <ref>''[https://www.gimp.org/ GIMP – GNU Image Manipulation Program]'', S. Kimball and P. Mattis</ref> 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 and should be subject of further research.
 '''How to test for this attack?'''

@@ Line 5: / Line 5: @@
 [[File:Overlay.jpg|thumb|Smiley overlay attack on others' jobs]]
-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 [[PostScript#Operator redefinition|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.
+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 [[PostScript#Operator redefinition|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?'''
@@ Line 25: / Line 25: @@
 == 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 ones does 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 <ref name="nevill1997extracting">''[https://pdfs.semanticscholar.org/494d/24a72be788a91a6ca45373c2d33013f33395.pdf Extracting Text from PostScript]'', C. Nevill-Manning, T. Reed and others, 1997</ref>. 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. This approach can also be used 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` <ref name="nevill1997extracting"/> 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'' <ref>''[https://www.gimp.org/ GIMP – GNU Image Manipulation Program]'', S. Kimball and P. Mattis</ref> 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 and should be subject of further research.
+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 ones does 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 <ref name="nevill1997extracting">''[https://pdfs.semanticscholar.org/494d/24a72be788a91a6ca45373c2d33013f33395.pdf Extracting Text from PostScript]'', C. Nevill-Manning, T. Reed and others, 1997</ref>. 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. This approach can also be used 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’ <ref name="nevill1997extracting"/> 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'' <ref>''[https://www.gimp.org/ GIMP – GNU Image Manipulation Program]'', S. Kimball and P. Mattis</ref> 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 and should be subject of further research.
 '''How to test for this attack?'''

@@ Line 25: / Line 25: @@
 == 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 ones does 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 <ref name="nevill1997extracting">''[https://pdfs.semanticscholar.org/494d/24a72be788a91a6ca45373c2d33013f33395.pdf Extracting Text from PostScript]'', C. Nevill-Manning, T. Reed and others, 1997</ref>. 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. This approach can also be used 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` <ref name="nevill1997extracting"/> 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'' <ref>''[https://www.gimp.org/ GIMP – GNU Image Manipulation Program]'', S. Kimball and P. Mattis</ref> 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.
+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 ones does 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 <ref name="nevill1997extracting">''[https://pdfs.semanticscholar.org/494d/24a72be788a91a6ca45373c2d33013f33395.pdf Extracting Text from PostScript]'', C. Nevill-Manning, T. Reed and others, 1997</ref>. 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. This approach can also be used 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` <ref name="nevill1997extracting"/> 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'' <ref>''[https://www.gimp.org/ GIMP – GNU Image Manipulation Program]'', S. Kimball and P. Mattis</ref> 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 and should be subject of further research.
 '''How to test for this attack?'''

← Older revision		Revision as of 17:17, 23 January 2017
Line 2:		Line 2:

	== Content Overlay ==		== Content Overlay ==
		+
		+	[[File:Overlay.jpg\|thumb\|Smiley overlay attack on others' jobs]]

	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 [[PostScript#Operator redefinition\|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.		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 [[PostScript#Operator redefinition\|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.