Password Recovery function immediately changes password without confirming by email

Bug #675372 reported by Bob Iwamoto
266
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Eucalyptus
Fix Released
Undecided
Dmitrii Zagorodnov

Bug Description

Environment: OSS 2.0.1 + CentOS 5.5

Issue:
Password Recovery function on Admin UI immediately changes password without confirming by email. The password should be changed by clicking the link in the confirmation email.

Reproduce:
1. Go to Admin UI (https://(CLC IP addresss):8443).
2. Click on [Recover] link.
3. Fill in all necessary fields, and click on [Recover Password].
4. Login with new password without confirming by email.

Thanks,
Bob

Daniel Nurmi (nurmi)
Changed in eucalyptus:
assignee: nobody → Dmitrii Zagorodnov (dmitrii)
Revision history for this message
Daniel Nurmi (nurmi) wrote :

patch is attached that applies cleanly against:

lp:ubuntu/maverick/eucalyptus

revno 173. This is a complete patch that resolves this security problem and has been tested against the corresponding upstream version of eucalyptus 2.0

Revision history for this message
C de-Avillez (hggdh2) wrote :

Confirmed issue on a brand-new install of Maverick Eucalyptus (2.0+bzr1241-0ubuntu4).

Installed Eucalyptus 2.0+bzr1241-0ubuntu4.1 and rebooted all machines to start fresh. Then I:

1. tested logging in with the test user I created and the new password: success
2. logged out, and selected "Recover the password";
3. Entered userId and new password, selected "Recover password": FAIL (Error! Insufficient parameters)
3. Again selected "Recover the password"
4. Entered email address and new password, selected "Recover password": FAIL (Error! Insufficient parameters)

C de-Avillez (hggdh2)
tags: added: qa verification-failed
Changed in eucalyptus:
status: New → Incomplete
status: Incomplete → New
Revision history for this message
Dmitrii Zagorodnov (dmitrii) wrote :

Carlos,

Something isn't quite right. The new password-recovery procedure does not ask you for the new password until you click on a confirmation link in the email message. When you click on "Recover password", the system should ask you for login and email address, both of which are required. Is that not what you see? In that case, either you are not fully re-deploying the code after applying the patch or your browser has the old Javascript client-side code cached. Could check on that? Thanks!

Revision history for this message
C de-Avillez (hggdh2) wrote :

Hi Dmitrii,

No, that was not what I saw -- so it stands to reason it was probably the cache biting me. Will test again when I get back from Turkey Day.

Thanks for the heads up.

Revision history for this message
Dave Walker (davewalker) wrote :

Just as a belated update, the caching seems to be server side.

Tested using two different browsers:
Firefox before the upgrade
 -> Firefox after the upgrade (old login view seen)
Chromium after the upgrade (old login view seen)

Restart eucalyptus... same behavior.

Restart server (!), new login view seen. Clearly, another service or some cache is cleared on boot. We should really try and reproduce this behavior.

################

The secondary issue which is concerning me, is the email From: field uses "n/a@neptune" (where neptune is the local hostname).... This will fail with many mail servers, and the initial (post upgrade) login of admin suggests the admin password will be used via the "admin-email-change-text" text.

Thanks

Revision history for this message
Dave Walker (davewalker) wrote :

Regarding the second point, I just attempted it again.. and it did use the correct From: address. :/

Revision history for this message
C de-Avillez (hggdh2) wrote :

Retested, brand new install of Maverick and Euca:

1. on Euca 2.0+bzr1241-0ubuntu4 (standard Maverick) added a new user, and immediately went to "Recover password". Reset the password
2. Confirmed the new password immediately works.

3. Upgraded Euca to 2.0+bzr1241-0ubuntu4.1 (which forces an application restart), and immediately went to "Recover password". The *same* page as before the update (with the new password fields) is shown.
4. Started Chromium, and went to "Recover password". The *same* page as before the update (with the new password fields) is shown.

Now, I *never* used Chromium to access Euca (in fact, I almost never used Chromium at all). Ergo, this is caching server-side.

Looking at the server... this seems to be under /var/run/eucalyptus. I will reboot now, and check again.

Revision history for this message
C de-Avillez (hggdh2) wrote :

Indeed, after a server restart /var/run/eucalyptus is cleaned up (and, in fact, I do not see any of the *.cache.* files I saw before).

Going into "Recover password" again -- there is no prompt for new password; now there are prompts only for userId and email address (both now are required; before the update *either* userId *or* email address were required.

The email is generated providing a link to update the password. The 'From' field is correctly set.

So... it works. There is this bit about server-side caching: I do not see the /var/run/eucalyptus/*.cache.* files anymore, so something else changed. But needing to restart the server to clean up the "old" cache seems excessive.

Now, for a regression test.

Revision history for this message
C de-Avillez (hggdh2) wrote :

No regressions seen on a 500-instances run.

C de-Avillez (hggdh2)
tags: added: verification-done
removed: verification-failed
Revision history for this message
Dave Walker (davewalker) wrote :

Would -> rm /var/run/eucalyptus/*.cache.* , be enough to clear the server side caching and mean that a reboot isn't required?

Revision history for this message
Dmitrii Zagorodnov (dmitrii) wrote :

Thanks for testing it, Carlos! And your analysis, Dave, is spot on. Specifically, here is what I would suggest adding to post-install script:

  - stop the CLC
  - rm -rf /var/run/eucalyptus/webapp
  - start the CLC

The cache files you were seeing are in 'webapp' and we might as well wipe out all of them to be safe. The CLC will repopulate that directory.

As for the "n/a" email address, I suspect you were seeing that at a point when admin's email address has not been set yet. If password recovery is initiated after fully configuring the system, this should not happen.

Revision history for this message
Dave Walker (davewalker) wrote :
Revision history for this message
C de-Avillez (hggdh2) wrote :

Confirmed the new version works correctly. This is now 'verification-done', really ;-)

Revision history for this message
Kees Cook (kees) wrote :
Changed in eucalyptus:
status: New → Fix Released
visibility: private → public
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers