Attachment 148037 Details for Bug 228637 – copy of letter sent to security response team

copy of letter sent to security response team

sec_let (text/plain), 4.75 KB, created by Jim Parsons on 2007-02-14 03:54:04 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Jim Parsons

Created: 2007-02-14 03:54:04 UTC

Size: 4.75 KB

patch

obsolete

>This concern regards the conga package set...in particular, the luci 
>server component. Conga is a web-based remote management application, that
>allows cluster and storage configuration to be administered through a
>browser.
>
>BACKGROUND: 
>
>There are two main components of Conga: the remote system agent called 'ricci', 
>and the server component called 'luci'. Luci requires that client browsers 
>use https for connections. A fresh install of luci presents an interface with no
>systems to manage. To manage a remote system or cluster, the system must 
>be added through the interface to a luci server instance.
>
>When a system is added, the user first has the opportunity to review the 
>security certificate on the remote system (avoiding man-in-the-middle exploit)
>before sending the password for the remote system. If the user chooses not
>to review the cert, or if the cert is reviewed and the user selects 'trust' for
>the remote system, the root password is entered in a password text field
>entry widget and submitted as a post through the form mechanism to the luci 
>server. The luci server then uses the password via an ssl conection to 
>authenticate to the remote system, certs are exchanged, and the remote system
>address is included in the luci database so the user can select to administer 
>the system from a pick list of systems in the UI.
>
>In one of the administrator pages where you add an existing cluster to the 
>database to be administered, the root password of one system is entered, and 
>then a checkbox is available where you can say "Use the same password for 
>all cluster nodes" (as this is a common case, and entering the same password 
>ten times for a ten-node cluster is tedious) . The first node is contacted, 
>and the configuration of the cluster returned, and parsed, and then the UI 
>displays a list of all nodes and offers the user the opp to 'Add this Cluster'.
>
>It should be noted that after the initial node is contacted for the cluster
>configuration, that system is immediately 'unauthenticated' from the luci 
>server, so that if the user changes their mind upon seeiing the returned node
>list (maybe they were confused and this is the wrong cluster), there is no
>residual luci cert left on the remote system and their is no entry of the 
>system in the luci server database. Clicking on 'Add this Cluster' initiates
>a fresh authentication transaction with the initial node queried, and
>with all other nodes in the cluster. In addition, the user again has the 
>opportunity to review the certs on the systems in the node list.
>
>PROBLEM:
>
>The password for the remote system(s) is persisted between two page loads in
>the Add System/Cluster task flow. If it were persisted in the server session it
>would not be a problem, but instead it it is returned to the browser as a
>'Value' attribute in a password entry field widget. This means that if the user 
>were to 'View Source', the password would appear as plaintext in the html.
>
>ASSESSMENT THOUGHTS:
>
>Conga uses https...so there is little chance of snooping the wire where the 
>admin app in your browser is running and getting anything meaningful. In
>addition, the luci server sends Pragma: no-cache to the browser, with a max-age
>of 1 second, so in general, storing the page with a password in cache is
>not a concern; except in the IE case listed below. It seems
>that the three chances to exploit this problem are:
>1) An administrator checks the 'Use same password' checkbox, and walks away 
>from the browser session with the list of cluster nodes (detailed above) in 
>the browser window. With this page loaded, another user could happen by and
>choose to 'View Source' and search for the password(s) in the html. Of course,
>if an administrator left themselves logged into a luci server in a browser
>session and walked away, there could be MUCH damage done without the root 
>password...
>2) A remote desktop application is running on the machine used to browse to
>a luci server.
>3) A user is using IE as their browser and they have 'Work Offline' option
>checked, so that when they go offline, all pages viewed are cached and 
>available as source.
>
>Despite what I may naively think are unlikely chances of exploiting this
>problem, our whole team is deeply troubled by this issue - as security has
>been and remains our very first priority in this product (hence, this letter).
>A password should just never be returned to a browser by a server; if needed
>between two pages, it should be persisted using the servers session management 
>mechanism.
>
>It is, of course, too late for rhel5.0 GA...Do you think that it is sufficient
>to document this issue in the release notes, or is a Day Zero Security Errata
>the necessary way to handle this? We are already fixing this in HEAD, so that
>it will not be present in the 4.5 release, or any other future releases.
>
>Thanks and Regards,
>
>-Jim Parsons

Actions: View

Attachments on bug 228637: 148037