Bug 1077446

Summary: [ovirt][webadmin] Session fixation in ovirt webadmin
Product: [Retired] oVirt Reporter: lzhuang <lzhuang>
Component: ovirt-engine-webadminAssignee: Alexander Wels <awels>
Status: CLOSED CURRENTRELEASE QA Contact: Pavel Stehlik <pstehlik>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.4CC: acathrow, alonbl, awels, djorm, ecohen, gklein, huiwang, iheim, jechoi, khong, mgoldboi, sbonazzo, sraje, suli, yeylon, yuzheng
Target Milestone: ---Keywords: Security
Target Release: 3.4.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1150424 (view as bug list) Environment:
Last Closed: 2014-05-08 13:37:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1150424    

Description lzhuang 2014-03-18 03:20:28 UTC
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:
100%

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 19:03:50 UTC
This would normally be protected by wrapping the session in HTTPS, correct?

Comment 2 Kurt Seifried 2014-03-24 19:45:42 UTC
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 20:15:27 UTC
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 08:11:25 UTC
All referenced pathches have been merged, shouldn't this be in modified state?

Comment 6 Sandro Bonazzola 2014-05-08 13:37:05 UTC
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.