Enabling print scripting, device scripting and advanced scripting features

PaperCut MF and NG versions 19.2.7, 20.1.6, 21.2.10, (and 22.0.0 and later - coming soon!) include an upgraded version of the Rhino JavaScript engine (release note reference PO-816). As a result of this, print scripting and device scripting are sandboxed by default, and can now be made even more secure with the options below.

Scripting is now more secure by default

While print scripting and device scripting are powerful and flexible features, they also bring additional risks if not managed and controlled properly. If you’re running one of the versions above, we are making you safer with:

• An upgraded version of Rhino (the JavaScript engine) with all the latest security patches.
• Script Sandboxing is enabled by default - preventing scripts being able to execute commands outside of the immediate print-event context, e.g. executing OS-level commands. This can limit vulnerabilities that may be found in the future, while allowing print and device scripts to execute safely.
• The ability to disable print scripts and device scripts entirely. If you’re not using scripting, the ability to switch off print scripting and device scripting can reduce the impact of any future vulnerabilities discovered in Rhino.js.

Are you using print scripting or device scripting?

To tell if you are using print scripting or device scripting in your environment, check to see if you have checked the ‘Enable print script’ or ‘Enable device script’ box for any of your printers or devices:

• Printers > [select printer] > Scripting > Enable print script
• Devices > [select device] > Scripting > Enable device script

Upgrading from previous versions

When upgrading from previous versions of PaperCut MF/NG, to 19.2.7, 20.1.6, 21.2.10 or 22.0.0 and later:

• Scripting is enabled by default
• Sandboxing is enabled by default

This is achieved by the following default config key settings:

• print-and-device.script.enabled set to Y (print scripting and device scripting enabled)
• device.script.sandboxed set to Y (sandboxing for device scripts enabled)
• print.script.sandboxed set to Y (sandboxing for print scripts enabled)

If you are using print scripting or device scripting

If you are using print scripting or device scripting, there is nothing further to do, unless you are in the unusual situation of Using extended Java classes in scripts (see the section at the end of this article).

If you are not using print scripting or device scripting

If you are not using print scripting or device scripting, we highly recommend disabling print scripting and device scripting completely. Use the config editor (under Options > Config Editor) to switch off scripting by setting the following key:

• print-and-device.script.enabled to N (print scripting and device scripting disabled)

While print and device scripting is even safer with the sandboxed environment, it is good practice to disable it, if you’re not using the feature at all.

Performing a new installation

If you are newly installing PaperCut MF/NG with versions 19.2.7, 20.1.6, 21.2.10 or 22.0.0 and later:

• Scripting is disabled by default
• Sandboxing is enabled by default

This is achieved by the following default config key settings:

• print-and-device.script.enabled set to N (print scripting and device scripting disabled)
• device.script.sandboxed set to Y (sandboxing for device scripts enabled)
• print.script.sandboxed set to Y (sandboxing for print scripts enabled)

If you are using print scripting or device scripting

If you are using print scripting or device scripting, you will need to manually enable print scripting and device scripting. Use the config editor (under Options > Config Editor) to enable scripting by setting the following key:

• print-and-device.script.enabled to Y (print scripting and device scripting enabled)

If you are not using print scripting or device scripting

If you are not using print scripting or device scripting, there is nothing further required. Your configuration is already set to the most secure (scripting disabled, and sandboxing enabled).

Using extended Java classes in scripts

To understand if you’re using extended classes, generally if you are using classes outside of dates, numbers and strings (those listed on the Print script API reference or Device script API reference) then you may be using extended classes. These may include calling OS-level commands or accessing non-type classes from your print or device script.

Generally this is rare!

If you are using extended Java classes in print scripting or device scripting, you will need to use the config editor (under Options > Config Editor) to disable sandboxing.

Only change whichever key(s) are necessary:

• device.script.sandboxed to N (if you’re using device scripts with extended Java classes)
• print.script.sandboxed to N (if you’re using print scripts with extended Java classes).

We recommend these keys are set to Y (sandboxing enabled) unless absolutely necessary.

If you experience failures in your scripts or workflows, set these sandboxing keys to N to test.

Troubleshooting the scripting engine

If you do not have print scripting and device scripting enabled, and you attempt to edit a Print Script or Device Script, you’ll see a warning in the admin interface: Print and Device scripts are currently not enabled. Print and device scripting can be turned on in the config editor:

You will need to use the config editor (under Options > Config Editor) to update the key print-and-device.script.enabled to Y (enabling print scripting and device scripting).

Troubleshooting extended Java class script failures

If you are attempting to use an extended Java class in your script, but you have Sandboxing enabled, the non-extended parts of the script will run as normal, however the script will not run the extended class.

In the Application Log (under Logs > Application Log), you will see an error The print script encountered an error when running [function] for job on printer [printer name]… Error: ReferenceError: [class] it not defined. The error will then list the line number where the issue occurred in the print script:

Note: in the screenshot above, the script is using the actions.log.info(message) method (documented on the Print Scripting API page) to log the message ‘script starting’ at the start of the script.

FAQs

Q Does this mean that scripting is insecure or dangerous?

No! With the scripting engine upgrade we are defaulting to additional protection within the scripting environment. Not only will you have the latest Rhino.js security patches included, but by default scripts will be sandboxed. This can help limit the damage that could be done if 3rd party or other vulnerabilities are discovered in the future.

Documented print script APIs and device script APIs will continue to run without any issues. Same functionality, but with additional protection!

Q What exactly is ‘Sandboxing’?

Device Scripting and Print Scripting are powerful and useful, but their flexibility and power also introduce some security risks.

Sandboxing means that the scripting engine keeps scripts isolated from the server operating system, and limits scripts from exceeding the scope of their intended use.

Q What version of Rhino.js is in use?

In previous versions of PaperCut NG and MF we were using Rhino version 1.7.7.2. With versions 19.2.7, 20.1.6, 21.2.10, and 22.0.0 and later we are now using Rhino version 1.7.14.

Q If I make use of extended scripts, is it safe to disable sandboxing?

We highly recommend enabling sandboxing (it is enabled by default for upgrades and new installations), However if you are needing to use extended classes, disabling sandboxing is an option (see above).

The upgraded version of Rhino includes the latest Rhino.js security patches, and regardless of your sandboxing setting you will be protected from the PaperCut vulnerability labelled PC-18750 and Spring4Shell.

Q What happens if I disable scripting by mistake, and I have a script enabled on a printer?

If you have a script enabled on a printer, and then you set print-and-device.script.enabled to N, the Application Server will process the job as though the script doesn’t exist. Depending on the contents of the script, it could fail in different ways. For example if a print script triggers a popup with a warning to the user, the popup will no longer appear and the job will be processed as though the script doesn’t exist.

Q Am I vulnerable to PC-18750 or Spring4Shell if I enable scripting, or disable sandboxing?

No - fixes for PC-18750 and Spring4Shell are included in versions 19.2.7, 20.1.6, 21.2.10, and 22.0.0 and later, and they cannot be disabled through configuration. If you enable scripting and disable sandboxing, you are still protected from these vulnerabilities.

Q I saw versions 19.2.6, 20.1.5 and 21.2.9 available at one point - what happened?

We published maintenance releases 19.2.6, 20.1.5 and 21.2.9 on May 18th 2022. We then became aware that a small number of customers with a specific database configuration had to roll back after encountering an upgrade error, so we pulled these maintenance releases from our website to avoid impacting any additional customers. We then identified and fixed the issue with these builds, and have released the new (fixed) builds of 19.2.7, 20.1.6 and 21.2.10. We apologize for the confusion here - it wasn’t our best moment.

The same security fixes that were in the previous (pulled) builds are now in the fixed builds available on the website. If you are not using MS SQL Server as your database, and you upgraded to one of the now-pulled builds, you’ll be able to continue running that build without any issues.

Q I’m using javascript for card number conversions - will this stop working if I switch off print and device scripting?

No! If you are using the advanced device key ext-device.card-no-converter to call a script to convert card numbers, this will continue to work successfully, even if you have set print-and-device.script.enabled to N. See your PaperCut embedded device manual for more information on this key.

---

Categories: How-to Articles, Scripting and APIs