Recently, a security researcher made an irresponsibly premature public disclosure of a security weakness in the rPath Appliance Platform Agent on his personal blog. rPath was investigating the issue with him, but instead of responding to rPath's request for information, he published his analysis publicly. rPath is currently working on software updates to address this concern.

While those software updates are being written, rPath is providing detailed information on the scope of the weakness so that developers and users can determine whether their appliances are vulnerable, and if so, take appropriate defensive measures until software updates are made available.

Summary of Analysis

Unless the appliance explicitly enables the "rootpw" plugin for setting the system root password and explicitly adds a service which enables remote root login, the appliance is not affected.

The attack is not generic; an attacker has to target both a specific running vulnerable appliance image and a specific administrator during a time-limited authenticated session.

Full Analysis

In the disclosure, three weaknesses were suggested: lack of password verification for some critical actions (specifically, setting the system root password), cross-site request forgery vulnerability in the rPath Appliance Platform Agent "rootpw" plugin, and exposed salted hashed passwords.

The administrative password in the rPath Appliance Platform Agent provides full control of the system. It is, effectively, equivalent to the system root password, with respect to the capabilities of the rPath Appliance Platform Agent. That password must be guarded similarly to a root login password, and active sessions must be guarded similarly to active root login shell sessions. For this reason, administrative sessions time out after 10 minutes of inactivity.

Currently, the "rootpw" plugin that sets the system root password (which is not a default component of the rPath Appliance Platform Agent) does not require additional authentication or authorization from the administrator if the request is made from a browser with a valid administrative session. To enhance security, certain critical actions (including but not limited to setting the system root password) will be modified to re-validate the administrative password. This will prevent an intruder from being able to perform these actions by using an unattended administrative session in the administrator's web browser.

Note that the rPath Appliance Platform does not enable incoming ssh connections by default, nor does it by default enable any other incoming network service that provides root access, and the rPath Appliance Platform Agent does not enable setting the system root password by default. Appliances that do not explicitly enable root login are not vulnerable to remote attack even if the root password is set; appliances that do not explicitly enable the "rootpw" plugin are not vulnerable to this attack against the rPath Appliance Platform Agent.

The second weakness is the cross-site request forgery (CSRF) vulnerability. This weakness allows an attacker to reset a root password, if he or she knows the hostname of a specific system to attack and can entice an administrative user with an active login session to a vulnerable rPath Appliance Platform Agent to visit an attacker-provided URL. For example, if the administrator has an email client (web mail or otherwise) which displays HTML email through the same browser session used for the administrative login, and the attacker sends the administrator an HTML email including that link (usually as a 1-pixel image with that link as the source of the image). This attack requires that a vulnerable "rootpw" plugin is enabled on the system under attack, and is specific to an individual appliance and an individual administrator with an active session. Additionally, most web mail clients do not display images included in email by default. The targeted administrator will almost always need to click on a link or choose to display the images in an email in order for the browser to visit the URL that changes the root password.

The third suggested weakness, with regard to exposed salted hashed passwords, is simply incorrect. The salted hashed passwords are equivalent to the salted hashed passwords stored in the /etc/shadow file and are similarly protected by standard file permissions. This is not a fault in system design or implementation; the fault is in the analysis by the security researcher in question. His analysis is that an attacker who has already attained root privileges on a system under attack can provide a changed password. rPath's analysis is that an attacker who has already attained root privileges on a system under attack has already subverted the system and can make arbitrary changes; precisely which changes the attacker chooses to make are not a relevant security issue.

Reporting Security Issues to rPath

rPath takes security issues very seriously, and welcomes comments, concerns, and critiques from responsible members of the security community. There are two appropriate ways to notify rPath of a security issue in rPath products and technologies.

• You may send an email to security@rpath.com. A member of our security team will respond, and will ensure that your report is handled appropriately.
• You may file an issue in the rPath Issue Tracking System at https://issues.rpath.com/ by creating an account, clicking on "CREATE NEW ISSUE", selecting the product or technology from the drop-down menu, and selecting a Security Level of "Reporter and rPath Security Team". If you are not sure which product or technology to choose, just guess -- we can fix it later. This allows you to participate more directly in our internal discussions about resolving the issue. (If you choose to send email to security@rpath.com, we will still open an issue in the rPath Issue Tracking System, but we cannot include you in the discussion unless you have created an account.)

In either case, rPath will work with you to analyze the issue and coordinate a disclosure date.