Jan 12, 2020

Teradici PcoIP Agents and Clients (Deployed with Amazon Workspaces) – Unquoted Search Path and Potential Abuses (CVE-2019-20362)


SafeBreach Labs discovered a new vulnerability in Teradici PcoIP software which is pre-installed on VMs in Amazon Workspaces.

In this post, we describe the CVE-2019-20362 vulnerability we found in the Teradici PcoIP software. We then demonstrate how this vulnerability could have been exploited by an attacker during a post-exploitation phase, in order to achieve persistence and in some cases defense evasion. The exploitation technique involves implanting an arbitrary unsigned executable which is executed by a signed service that runs as NT AUTHORITY\SYSTEM.

Note: In order to exploit this vulnerability, the attacker needs to have Administrator privileges.

Teradici PcoIP

Teradici developed PC-over-IP (PCoIP) – a proprietary remote display protocol. That is available in hardware and in software. The PC-over-IP (PCoIP) protocol was licensed to VMWare and AWS Amazon Workspaces.:

VMware licensed Teradici’s PCoIP protocol in 2008. It supports PCoIP in VMware Horizon View.

Amazon licensed the PCoIP protocol In 2013 for use in AWS Amazon Workspaces.

Vulnerability Discovery

In our initial exploration of the software, we targeted the “ASLDR Service” (AsLdrSrv .exe), because:

  • It runs as NT AUTHORITY\SYSTEM – the most privileged user account. This kind of service might be interesting to attackers when looking for privilege escalation to SYSTEM, which is very useful and powerful.
  • The executable of the service is signed by “ASUSTek Computer Inc.” If the attacker finds a way for a malicious payload to be executed by AsLdrSrv .exe, the service can be used as an application whitelisting bypass.
  • This service automatically starts once the computer boots, which means that it’s a potential target for an attacker to be used as a persistence mechanism.

In our exploration, we found that once the Teradici PcoIP service was started, the pcoipPrintingsvc.exe signed process was executed as NT AUTHORITY\SYSTEM.

We noticed an interesting behavior once the service’s process was executed.

The pcoipPrintingsvc.exe process looked for missing EXE files before it executed the required one (C:\Program Files (x86)\Teradici\PCoIP Agent\pcoip_vchan_printing_svc.exe)


C:\Program Files (x86)\Teradici\PCoIP.exe

PoC Demonstration

In order to test this privilege escalation vulnerability, we compiled an EXE file (unsigned) which writes the following to the filename of a txt file:

  1. The name of the process which loaded it
  2. The username which executed it

Our arbitrary unsigned EXE file was executed as NT AUTHORITY\SYSTEM by a legitimate process (without changing the service’s path or overwriting any file).

Root Cause Analysis

As can be seen on the screenshot, the path of the PCoIPPrintingSvc is not a quoted string, which is the root cause of the unquoted search path vulnerability.

The final path contains a space (“PcoIP Agent”), and the CreateProcess function (which is called by services.exe) doesn’t know whether it’s part of the path or whether it’s an argument, so it tries to parse it.

According to the CreateProcess function documentation in MSDN, we will see the following:

The lpApplicationName parameter can be NULL. In that case, the module name must be the first white space–delimited token in the lpCommandLine string. If you are using a long file name that contains a space, use quoted strings to indicate where the file name ends and the arguments begin; otherwise, the file name is ambiguous.For example, consider the string “c:\program files\sub dir\program name”. This string can be interpreted in a number of ways. The system tries to interpret the possibilities in the following order:

c:\program.exe c:\program files\sub.exe c:\program files\sub dir\program.exe c:\program files\sub dir\program name.exe

The root cause of this unquoted search path vulnerability is that since the service executable path does not contain a quoted string, the CreateProcess function tries to split it by itself each time it parses a space character:


C:\Program Files (x86)\Teradici\PCoIP.exe

C:\Program Files (x86)\Teradici\PCoIP Agent\pcoip_vchan_printing_svc.exe

Potential Malicious Uses and Impact.

Below we show three possible ways that an attacker could have leveraged the CVE-2019-20362 vulnerability we discovered and documented above.

Defense Evasion / Whitelisting Bypass

The vulnerability gives attackers the ability to execute malicious payloads using a signed service. This ability might be abused by an attacker for different purposes such as execution and evasion, for example: Application Whitelisting Bypass.

Persistence Mechanism

The vulnerability also gives attackers the ability to execute malicious payloads in a persistent way, each time the service is loaded. That means that once the attacker drops a malicious EXE file in one of the paths we mentioned earlier, the service will load the malicious code each time it is restarted. This way the malicious payload might not be detected by security products, because the service process which executes the attacker’s payload is signed and executes it “natively.” No suspicious action is required by the attacker. The service just executes the malicious executable once it is started.

Affected Versions

  • PCoIP Standard Agent for Windows 19.08.0 and earlier
  • PCoIP Graphics Agent for Windows 19.08.0 and earlier
  • PCoIP Client for Windows 19.08.2 and earlier

Available Updates

  • PCoIP Agent (Standard or Graphics) for Windows, 19.08.1
  • PCoIP Agent (Standard or Graphics) for Windows, 19.11 and later
  • PCoIP Client for Windows 19.08.3
  • PCoIP Client for Windows 19.11 and late


Sep 23rd, 2019 – Vulnerability reported to Amazon

Sep 24th, 2019 – Initial response from Amazon

Oct 1st, 2019 – Amazon sent the report to Teradici.

Oct 8th, 2019 – Teradici asked SafeBreach to report the vulnerability on their own website.

Oct 8th, 2019 – SafeBreach reported the vulnerability to Teradici.

Oct 10th, 2019 – Teradici said they do not have a public vulnerability disclosure process, and that they can’t discuss anything which is related to Amazon with SafeBreach.

Oct 14th, 2019 – SafeBreach mentioned their disclosure policy to Teradici and asked for more details: “Our responsible disclosure policy is inspired by Google Project Zero: Bugs found by the SafeBreach Lab team are reported to the manufacturer and only made publicly visible once a patch has been released or if 90 days have passed without a patch being released.”

Oct 14th, 2019 – SafeBreach asked if Teradici is planning to fix the vulnerability.

Oct 24th, 2019 – Amazon notified SafeBreach that they will update their WorkSpaces environments by November 1st, 2019, using a custom patched version (

Oct 30th, 2019 – SafeBreach asked Teradici for details again.

Nov 14th, 2019 – SafeBreach asked Teradici for updates.

Dec 4th, 2019 – Teradici said that SafeBreach can publish their advisory, without any further details (SafeBreach did not know if the vulnerability was patched at this time.)

Dec 6th, 2019 – Teradici released a security advisory[1]. (SafeBreach only found it in January, as Teradici did not inform us.)

Jan 8th, 2019 – MITRE issued CVE-2019-20362.



Get the latest
research and news