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.

The rPath Appliance Agent, an application framework for administering Software Appliances in all their forms (Hardware, Software and Virtual), has been updated. This version contains a few bug fixes, and some new features. Please note, rAA 2.0.x are available on raa.rpath.org@rpath:raa-2, so please update your groups.

• A side effect of using the Python logging module means that previously log files that were rotated were not closed. The running raa-service and raa-web-scgi daemons continued to write to the deleted file causing log file data loss and the file system to misreport free disk space. A signal (SIGUSR2) is now passed to raa-service and raa-web-scgi to close the files and reopen. The logrotate script has been modified appropriately. (RAA-471)
• The raa-service daemon now handle SIGHUP in addition to SIGUSR1 to restart itself.
• With newest Conary, updatetroves XMLRPC API will return whether updates will invalidate rollbacks (RAA-320).
• New callbacks added in Conary as part of pre/post script implementation are now supported in rAA (RAA-320).
• All XMLRPC requests must now go through /xmlrpc/ See the example scripts. (RAA-390).
• Move raa_service.conf to raa-branding

For a full list of changes, please see the NEWS file contained in the source or binary distribution.

The rPath Appliance Agent, an application framework for administering Software Appliances in all their forms (Hardware, Software and Virtual), has been updated. This version contains mostly bug fixes, one critical. We advise all appliance builders to recook their groups with this update.

• The rAA web side will now handle backwards system time changes, and scheduled tasks will be run correctly (RAA-453).
• Fixed a bug that caused errors if the conary configuration or the proxy configuration plugins are disabled.
• Changed the web access log to record which xmlrpc method is being called.
• DatabaseLocked errors will now be logged to the web log making debugging them possible.
• The network plugin now validates input and resets any fields with invalid data. (RAA-143, RAA-461)
• Don't set the height/width of the corpLogo, making rAA easier to rebrand.
• Fixed a bug in the schedule retrieval code that caused the same execution id to be assigned to multiple instances of a schedule instance. Also, in some cases the execution id didn't match any rows to retrieve extra task information. This caused scheduling races, which in combination with tasks that fail for some other reason caused a 5 second interval notification loop.
• Fixed bug that prevented users from adding a new user or group via the usermanagement plugin under IE (RAA-426).
• Fixed bug that prevented users from assigning multiple groups to an user via the usermanagement plugin under Firefox 2 and IE 6/7 (RAA-433).
• Added modal confirmation dialog for deleting users and groups in the usermanagement plugin (RAA-382).
• The style for links in the body of pages are now more browser-like.
• Enabling/disabling the NTP configuration checkbox in the Time Zone plugin will now set the focus to the ntp server textbox on IE (RAA-408).
• Display a message alerting users about possible services timeouts due to time and/or date changes done to the system via the Time Zone plugin; Removed reduntant OK button after saving information.
• Fixed some user facing messages in the SSLCert plugin which were created in the backend service, making them non-localizable so that they are now created in the web service.
• Uploading a new certificate through the SSLCert plugin now restarts the lighttpd process. Please note that existing connections will continue using the old certificate, but subsequent calls will use the new cert. (RAA-292)
• Fixed startup so that when errors occur during daemon startup, they are displayed, either on the screen (when it occurs before logging is configured) or in the log file. (RAA-372)
• Added version information to the logs when services start up. (RAA-389)
• Uploading a backup file to restore will now warn about the reboot at the end of the restore process. (RAA-294)
• A bug in the identity subsystem prevented users from being removed from groups once assigned.
• rAA signature threshold code has been removed. Please use the forthcoming conary configuration plugin instead, though the UI may in the future support modifying that option.
• Remove the database handle before getting forked, so it's not shared between processes.
• rAA will no longer restart unfinished tasks when it is restarted. (RAA-399)
• The generic data table now supports the JSON type.
• Both the web side and the service side of a plugin can now use self.plugins to access exposed methods other plugins. (RAA-384, RAA-416)
• The user management plugin XMLRPC example script has been updated to work for the new version of the plugin.
• The service side will now contact the web side using 127.0.0.1 instead of localhost, thus rAA will now work correctly on appliances that require localhost be mapped to the external IP address. (RAA-423)
• The update troves plugin now stores the Conary transaction count if Conary supports it. (RAA-421)
• A brand new update troves plugin is enabled for users of Conary 1.1.18+. It has the same look, but also supports updates from rBA-created install media and an extra XMLRPC method to allow downloading an update to the local machine before updating. (RAA-370)
• The update troves plugin exposes a new XMLRPC method to find rBA-created install media.

For a full list of changes, please see the NEWS file contained in the source or binary distribution.

To update rAA on your system, check for and apply updates through the rAA System Updates plugin.

The rPath Appliance Agent, an application framework for administering Software Appliances in all their forms (Hardware, Software and Virtual), has been updated. This version contains mostly bug fixes, and minor enhancements.

• Schedule icon in the Manage Services plugin now works under IE7 (RAA-280).
• The timezone plugin now reports the proper timezone information for virtual appliances built on rBuilder.
• The tail code for displaying logs was rewritten to be more succinct.
• rAA will now display an error page with clickable links to navigate away when a plugin causes an internal server error. If rAA isn't available, then the LightTPD error page will also show some content. (RAA-256)
• If an internal server error happens during an AJAX call, the server will return the traceback, and the Javascript will display that. (RAA-256)
• If Javascript cannot parse of AJAX content, it will now display the message from the server instead of 'syntax error'. (RAA-151)
• The system updates plugin will now leave only a configurable number of kernels behind. If it's configured to be 0, then the pinned status will not be touched. (RAA-163)
• The system updates plugin will now display messages from tag handlers. (RAA-295)
• The front-page no longer displays an error when trying to fetch installed troves when multiple flavors of the same trove are installed. (RAA-238)

For a full list of changes, please see the NEWS file contained in the source or binary distribution.

To update rAA on your system, check for and apply updates through the rAA System Updates plugin.

The rPath Appliance Agent, an application framework for administering Software Appliances in all their forms (Hardware, Software and Virtual), has been updated. This version contains mostly bug fixes, and minor enhancements.

• Enhanced the log viewer plugin to support the viewing of multiple logfiles, as well as adding the capability of viewing the appliance logs (rAA logs). See the logs.cfg file for example configuration. (RAA-309)
• The backup plugin now correctly handles an already mounted filesystem via a bindmount. (RAA-297)
• The network configuration plugin now uses a modal dialog box to prompt for user input. (RAA-338)
• There's a new javascript class available to plugins to create modal dialog boxes.

For a full list of changes, please see the NEWS file contained in the source or binary distribution.

To update rAA on your system, check for and apply updates through the rAA System Updates plugin.