Search Engine: Elastic

Article ID: 119125, created on Dec 12, 2013, last review on Jul 14, 2018

  • Applies to:
  • Operations Automation


There is a vulnerability in the Parallels Operations Automation (POA) NG Shared Hosting module (all nodes in Standalone mode and nodes with the Director role in Cluster mode are affected) for Providers who offer SSH access to NG webspaces for end-customers.

The issue was reproduced on the stock NG Hosting platform and verified as bug POA-82209.

RISK: Potentially, any end-customer with SSH access enabled on their NG subscription can get "root" access to NG webservers by:

  1. Enabling SSH on NG websites, specifying the existing local username (presented in the "/etc/passwd" or "/etc/shadow" file, e.g., "root").
  2. Waiting for the tasks to complete.
  3. Changing the password of the user.
  4. Waiting for tasks to complete.
  5. Seeing that the password of the local user is changed, and that it allows the end-customer to log in via SSH as "root."


Bug POA-82209.


Fixed in 5.5.3

The only workaround available is to prevent the creation of Web Hosting SSH users with names matching those of standard existing system users and local accounts (created by the Provider for server maintenance) with the SSH login ability.

To apply the workaround:

  1. Upload the attached fix_users_on_NG.sql SQL script to the POA Management Node (OSS Core server).

  2. Execute the following command on the POA Management Node:

    # psql -Uplesk -h`hostname` -f fix_users_on_NG.sql
  3. If execution fails with the "DETAIL: Key (login)=(<username>) already exists" error (this also means that the system is possibly compromised), then:

    1.1. Find the webspace with the relevant SSH user and change the username through the POA Customer Control Panel.

    To find the webspace ID, make the following selection from the POA database:

    SELECT * FROM apache_ssh_access WHERE login='`<username>`';

    The homedir_id parameter in the SQL query output is the ID of the customer's webspace.

    1.2. Go to step #2.

Note: Script inserts are only related to Linux system accounts (root, mysql, etc.). It is necessary to also make the same inserts for local system accounts that the Provider is using for maintenance of webservers (if any).

5356b422f65bdad1c3e9edca5d74a1ae caea8340e2d186a540518d08602aa065 e12cea1d47a3125d335d68e6d4e15e07

Email subscription for changes to this article
Save as PDF