Difference between revisions of "Countermeasures"
| Line 1: | Line 1: | ||
| − | + | Most attacks against printers are enabled because there is no clear distinction between [[Fundamentals#Page_Description_Languages|page description]] and [[Fundamentals#Printer_Control_Languages|printer control]] functionality. Using the very same channel for '''data''' (to be printed) and '''code''' (to control the device) makes printers insecure by design. Potentially harmful commands can be executed by anyone who has the right to print. Thus there is no silver bullet to counter such design-immanent flaws. There are however various short- and long-term recommendations, best practices and workarounds to mitigate the risks. | |
| − | + | ||
| − | Most attacks against printers are enabled because there is no clear distinction between [[page description]] and [[printer control]] functionality. Using the very same channel for '''data''' (to be printed) and '''code''' (to control the device) makes printers insecure by design. Potentially harmful commands can be executed by anyone who has the right to print. Thus there is no silver bullet to counter such design-immanent flaws. There are however various short- and long-term recommendations, best practices and workarounds to mitigate the risks. | + | |
== Vendors == | == Vendors == | ||
| − | Printer vendors have gotten themselves into a situation that is not easy to solve. Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers and updating the PostScript standard is probably not an option. Additional security flaws are introduced through undocumented PJL extensions, service codes and further proprietary features. In general there is a lot of security by obscurity in the printing industry. Reverse engineering however is not black magic anymore. Vendors need to accept that – sooner or later – someone will discover their | + | Printer vendors have gotten themselves into a situation that is not easy to solve. Cutting support for established and reliable languages like [[PostScript]] from one day to the next would break compatibility with existing printer drivers and updating the PostScript standard is probably not an option. Additional security flaws are introduced through undocumented [[PJL]] extensions, service codes and further proprietary features. In general there is a lot of security by obscurity in the printing industry. Reverse engineering however is not black magic anymore. Vendors need to accept that – sooner or later – someone will discover their ‘hidden functions’ and should instead focus on open, well-studied standards to improve printer security. When it comes to firmware updates and software packages, digital signatures are often advocated as the single countermeasure. If used correctly, only files originating from the entity in possession of the private key can be installed on the device. |
| − | Code signing however also means technically restricting users to run vendor software | + | Code signing however also means technically restricting users to run vendor software <ref>This issue has also been discussed by the FSF when HP announced to introduce code signing for their printers: ‘[https://www.fsf.org/blogs/licensing/restricted-printers Fixing rogue printers: don't trade one security threat for another]’</ref>. Certainly there are legitimate reasons to execute custom code on a printer. An example has been given by <ref>''Distribuição Balanceada de Jobs em uma Rede de Impressoras'', L. Waechter, 2005</ref> who extended HP LaserJets to support load-balancing. The [https://en.wikipedia.org/wiki/OpenWrt OpenWrt] success story demonstrated how to improve the often limited functionality of embedded devices and there is no valid reason why printers should be excluded from the benefits of free software. Vendors should therefore take secure alternatives to code signing into account. For example the window of vulnerability can be limited to a local attacker if firmware updates required a confirmation key pressed on the printer's control panel. Further non-code signing based approaches like unique default passwords can be adapted from best practices in the world of home routers. |
== Admins == | == Admins == | ||
| Line 15: | Line 13: | ||
== Users == | == Users == | ||
| − | Employees should be trained to never leave the copy room unlocked and report suspicious printouts like [https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] headers to the administrator. All other dispensable hard copies should be shred, even if they apparently do not contain confidential data. | + | Employees should be trained to never leave the copy room unlocked and report suspicious printouts like [https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP] headers to the administrator as they may be traces of a [[cross site printing] attack. All other dispensable hard copies should be shred, even if they apparently do not contain confidential data. |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | |||
| − | + | ---- | |
| − | + | ||
Revision as of 21:14, 14 January 2017
Most attacks against printers are enabled because there is no clear distinction between page description and printer control functionality. Using the very same channel for data (to be printed) and code (to control the device) makes printers insecure by design. Potentially harmful commands can be executed by anyone who has the right to print. Thus there is no silver bullet to counter such design-immanent flaws. There are however various short- and long-term recommendations, best practices and workarounds to mitigate the risks.
Vendors
Printer vendors have gotten themselves into a situation that is not easy to solve. Cutting support for established and reliable languages like PostScript from one day to the next would break compatibility with existing printer drivers and updating the PostScript standard is probably not an option. Additional security flaws are introduced through undocumented PJL extensions, service codes and further proprietary features. In general there is a lot of security by obscurity in the printing industry. Reverse engineering however is not black magic anymore. Vendors need to accept that – sooner or later – someone will discover their ‘hidden functions’ and should instead focus on open, well-studied standards to improve printer security. When it comes to firmware updates and software packages, digital signatures are often advocated as the single countermeasure. If used correctly, only files originating from the entity in possession of the private key can be installed on the device.
Code signing however also means technically restricting users to run vendor software [1]. Certainly there are legitimate reasons to execute custom code on a printer. An example has been given by [2] who extended HP LaserJets to support load-balancing. The OpenWrt success story demonstrated how to improve the often limited functionality of embedded devices and there is no valid reason why printers should be excluded from the benefits of free software. Vendors should therefore take secure alternatives to code signing into account. For example the window of vulnerability can be limited to a local attacker if firmware updates required a confirmation key pressed on the printer's control panel. Further non-code signing based approaches like unique default passwords can be adapted from best practices in the world of home routers.
Admins
Network administrators should never leave their printers accessible from the internet and disable raw port 9100/tcp printing if not required. While this does not prevent most of the presented attacks, it complicates them and in particular mitigates the attackers ability to leak data. A more secure but also more expensive approach is to completely sandbox all printing devices into a separate VLAN, only accessible by a hardened print server. If supported by the device, strong passwords should be set for PostScript startjob and system parameters, PJL disk lock and control panel lock as well as the embedded web server. Additionally, malicious PJL commands can be blocked using an IDS/IPS. Note however that such signature-based approaches are doomed to fail for PostScript which offers various code obfuscation techniques.
Users
Employees should be trained to never leave the copy room unlocked and report suspicious printouts like HTTP headers to the administrator as they may be traces of a [[cross site printing] attack. All other dispensable hard copies should be shred, even if they apparently do not contain confidential data.
- ↑ This issue has also been discussed by the FSF when HP announced to introduce code signing for their printers: ‘Fixing rogue printers: don't trade one security threat for another’
- ↑ Distribuição Balanceada de Jobs em uma Rede de Impressoras, L. Waechter, 2005
