Bug 1631150 - [Security] New user can steal already opened spice session from previous user
Summary: [Security] New user can steal already opened spice session from previous user
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: rhv-security
Version: 4.1.11
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.3.6
: 4.3.0
Assignee: Doran Moppert
QA Contact: Polina
URL:
Whiteboard:
Depends On:
Blocks: 1547768 gss_rhv_4_3_4
TreeView+ depends on / blocked
 
Reported: 2018-09-20 06:06 UTC by Abhishekh Patil
Modified: 2020-08-03 15:38 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-10 15:36:58 UTC
oVirt Team: Virt
Target Upstream Version:
Embargoed:
lsvaty: testing_plan_complete-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1700092 0 high CLOSED "Console Disconnect Action" is not locking Windows based VMs and normal users are able to steal previous user sessions. 2023-09-14 05:27:00 UTC
Red Hat Product Errata RHEA-2019:3010 0 None None None 2019-10-10 15:37:11 UTC

Internal Links: 1700092

Comment 8 Ryan Barry 2018-10-08 13:15:34 UTC
Has the customer updated to 4.2.6? Can they enable strict user checking?

Comment 9 Abhishekh Patil 2018-10-16 00:35:45 UTC
Hi,

Yes, this happens even after enabling strict user checking.

Comment 23 Michal Skrivanek 2018-11-12 15:29:07 UTC
ping?

Comment 27 Polina 2018-11-19 08:45:07 UTC
just wanted to note that in VM Portal the view is correct - user1 sees the VMs allocated by him, and user2 sees his vms.

Comment 29 Polina 2018-11-19 16:33:58 UTC
ok. It means that the Test2 results are correct. It doesn't explain though the 'Actual Result_1:', right? According to this result, user1 sees only one pool vm instead of two vms allocated for him in the response to Get vms API. Please update me if it must be inserted a separate issue or it is related to this bz.

Comment 31 Ryan Barry 2019-01-21 14:53:31 UTC
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both

Comment 33 Ryan Barry 2019-04-23 21:46:18 UTC
(In reply to Polina from comment #29)
> ok. It means that the Test2 results are correct. It doesn't explain though
> the 'Actual Result_1:', right? According to this result, user1 sees only one
> pool vm instead of two vms allocated for him in the response to Get vms API.
> Please update me if it must be inserted a separate issue or it is related to
> this bz.

Pool VMs are not selected deterministically, since it is assumed that any VM in the pool is usable (which is the primary use case of pools)

If you run the query repeatedly, do you always get the same VM? If not, I'd suggest that we close CURRENTRELEASE based on the results from comment#26

Comment 34 Polina 2019-04-24 15:13:06 UTC
Hi Ryan,

I re-tested in 4.3.3-5 and also in 4.2.8.7-0.1.el7ev .It behaves as expected. GET request with the specific user authorization just gets response as expected. I think it could be a problem with max parameter in the query filter which limited the number of shown VMs (GET https://{{host}}/ovirt-engine/api/vms;max=8?search=SORTBY%20NAME%20ASC authorized for user1). Anyway now could be verified.

Comment 35 Marina Kalinin 2019-04-30 15:37:32 UTC
Just to clarify, from reading this bug, it seems to be only for Pool VMs and for API calls only.
Maybe this should be reflected in the title. Otherwise it is a bit confusing and makes it sound like Spice sessions can be stolen in general.

Comment 36 Sandro Bonazzola 2019-06-26 14:14:47 UTC
Doran, this bug is on security component and not attached to any errata. According to comment #34 the issue doesn't reproduce on 4.3.3-5 and also in 4.2.8.7-0.1.el7ev.
Can you close this bug?

Comment 37 Marina Kalinin 2019-06-28 20:31:55 UTC
I think it is on the virt team.
Ryan, Polina, do you think this bug shoudl be closed current release?

Comment 38 Ryan Barry 2019-06-28 21:26:48 UTC
I'll add to errata, since it's d/s

Comment 40 Daniel Gur 2019-08-28 13:14:32 UTC
sync2jira

Comment 41 Daniel Gur 2019-08-28 13:19:34 UTC
sync2jira

Comment 43 errata-xmlrpc 2019-10-10 15:36:58 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:3010


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