This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 1077446 - [ovirt][webadmin] Session fixation in ovirt webadmin
[ovirt][webadmin] Session fixation in ovirt webadmin
Product: oVirt
Classification: Community
Component: ovirt-engine-webadmin (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.4.1
Assigned To: Alexander Wels
Pavel Stehlik
: Security
Depends On:
Blocks: 1150424
  Show dependency treegraph
Reported: 2014-03-17 23:20 EDT by lzhuang
Modified: 2014-10-08 05:24 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1150424 (view as bug list)
Last Closed: 2014-05-08 09:37:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 25959 None None None Never
oVirt gerrit 26806 ovirt-engine-3.4 MERGED userportal, webadmin: refresh session on login Never

  None (edit)
Description lzhuang 2014-03-17 23:20:28 EDT
Description of problem:
Since new session id is not generated every time users login, authentication can be bypassed through session fixation attacks in the situation where attackers are able to fixate another user's session id. Once user logs in with the session id, attackers could also access the whole site as that user.

Version-Release number of selected component (if applicable):
oVirt 3.4.0-5 beta3

How reproducible:

Steps to Reproduce:
1. At host A, get a new session ID by accessing /ovirt-engine/webadmin/#login with any existing cookie removed
2. At host B, access /ovirt-engine/webadmin/#login, set JSESSIONID with the one got in host A
3. At host B, log in with admin(or any user) account
4. At Host A, verify if the session is considered as authenticated

Actual results:
User at host A can access the application bypassing authentication.

Expected results:
At any point at which a user interacting with the application transactions from being anonymous to being defined, the application should issue a fresh session token.

Additional info:
Comment 1 Kurt Seifried 2014-03-24 15:03:50 EDT
This would normally be protected by wrapping the session in HTTPS, correct?
Comment 2 Kurt Seifried 2014-03-24 15:45:42 EDT
Also is the session ID properly terminated if the user hits the log out button? Or can they still login using the old session ID?
Comment 3 Alexander Wels 2014-03-24 16:15:27 EDT
Answer to comment #1:
I don't believe session fixation is prevented by using https.

Answer to comment #2:
When the user hits the logout button their session is removed from the backend session map. In order to do anything your session must exist in that map. I don't see a session.invalidate() in the logout method.

In short yes, I believe the session is terminated, but we should probably do a invalidate on the http session just to be sure. In case we ever store anything important in the http session instead of relying on the existence of the http session in the backend map.
Comment 5 Sandro Bonazzola 2014-04-18 04:11:25 EDT
All referenced pathches have been merged, shouldn't this be in modified state?
Comment 6 Sandro Bonazzola 2014-05-08 09:37:05 EDT
This is an automated message

oVirt 3.4.1 has been released:
 * should fix your issue
 * should be available at your local mirror within two days.

If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.