Bug 585952 - CVE-2010-4664 ConsoleKit: Policy restrictions break-out via remote Virtual Network Computing (VNC) session [rhel-6.0]
CVE-2010-4664 ConsoleKit: Policy restrictions break-out via remote Virtual Ne...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ConsoleKit (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Michal Sekletar
Frantisek Sumsal
:
Depends On:
Blocks: CVE-2010-4664 662543
  Show dependency treegraph
 
Reported: 2010-04-26 10:20 EDT by Pierre Ossman
Modified: 2016-05-10 20:58 EDT (History)
11 users (show)

See Also:
Fixed In Version: ConsoleKit-0.4.1-4.el6
Doc Type: Bug Fix
Doc Text:
Cause: Bug which caused that remote-sessions (vnc sessions) were marked as local. Consequence: A valid, authenticated system user could use this flaw to escalate their privileges (become member of more privileged policy group) by initiating a remote VNC session. Fix: Added additional logic to the code which causes that newly created session is marked as local only if it originates from existing local session. Result: vnc sessions are no longer marked as local to the system.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-10 20:58:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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
FreeDesktop.org 28377 None None None Never
Red Hat Product Errata RHBA-2016:0942 normal SHIPPED_LIVE ConsoleKit bug fix update 2016-11-24 18:09:27 EST

  None (edit)
Description Pierre Ossman 2010-04-26 10:20:08 EDT
Description of problem:
ConsoleKit misrepresents a session as being local when it isn't. Might have security implications.

Version-Release number of selected component (if applicable):
ConsoleKit-0.4.1-3.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1. ssh to machine (i.e. non-local)
2. run vncserver
3. connect to the started VNC server
  
Actual results:
Session inside vnc is considered local

Expected results:
Session inside vnc is NOT considered local

Additional info:
[tltest@rhel6beta Desktop]$ ck-list-sessions 
Session17:
	unix-user = '42'
	realname = '(null)'
	seat = 'Seat1'
	session-type = 'LoginWindow'
	active = TRUE
	x11-display = ':1'
	x11-display-device = '/dev/tty7'
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2010-04-26T14:01:34.386600Z'
	login-session-id = '4294967295'
	idle-since-hint = '2010-04-26T14:06:34.697758Z'
Session22:
	unix-user = '500'
	realname = '(null)'
	seat = 'Seat4'
	session-type = ''
	active = FALSE
	x11-display = ':2'
	x11-display-device = ''
	display-device = ''
	remote-host-name = ''
	is-local = TRUE
	on-since = '2010-04-26T14:14:50.193960Z'
	login-session-id = '1509'

(Session22 is the VNC one, and Session17 is GDM)

Note that avoiding ConsoleKit in the VNC startup doesn't give much as the user can easily do ck-launch-session inside VNC later anyway.
Comment 2 RHEL Product and Program Management 2010-04-26 11:15:10 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 jmccann 2010-06-02 19:30:47 EDT
So the reason for this is that the session is actually running locally.  The X server process and the session leader are both local to the system.

Running vncserver is more or less functionally equivalent to logging in from GDM, using vino (or similar) to export your user session over the network.  That session would have is-local=true as well even though it is available remotely.

One detail here is that the seat-id is not Seat1.  This can be used to assign authorization policies (afaik policykit supports this) in addition to the is-local property.

For auditing purposes you can track the user login that started the vncserver using the login-session-id.

Theoretically, if we deem it necessary, we can trace the vncserver session back to the ssh login using the login-session-id and mark any session that derives from a remote login to also be remote.
Comment 4 jmccann 2010-06-02 20:14:24 EDT
Other options in addition to trying to reverse map the login-session-id include:

 * Adding an additional check for the XFree86_VT property on the root window
 * Allowing only privileged callers to start sessions with is-local=true

I'm leaning toward the second at the moment.
Comment 5 Pierre Ossman 2010-06-03 08:15:54 EDT
(In reply to comment #3)
> So the reason for this is that the session is actually running locally.  The X
> server process and the session leader are both local to the system.
> 

So what's non-local in that meaning? XDMCP with the X server running elsewhere? And what's the value in that definition?

From what I've seen, people interpret "local" as meaning "has physical access to the machine" and become more lenient with security. That definition makes more sense as it focuses on where the user is located rather then the technical detail of whether it is VNC or X11 packets that are going over the network.

> Running vncserver is more or less functionally equivalent to logging in from
> GDM, using vino (or similar) to export your user session over the network. 
> That session would have is-local=true as well even though it is available
> remotely.

Not really. That scenario requires you to first log in locally.

(Although it would be nice if the system could detect that the user is now no longer at the machine, but accessing it remotely)

A more fair comparison would be to log in over ssh with X11 forwarding to a remote X server.

> 
> One detail here is that the seat-id is not Seat1.  This can be used to assign
> authorization policies (afaik policykit supports this) in addition to the
> is-local property.
> 

How do you tell the difference from a multi-seat machine and one with remote access in that case?

> For auditing purposes you can track the user login that started the vncserver
> using the login-session-id.
> 
> Theoretically, if we deem it necessary, we can trace the vncserver session back
> to the ssh login using the login-session-id and mark any session that derives
> from a remote login to also be remote.    

Since is-local has security implications, the default should really be to have it false and only set it to true when we're really, _really_ sure that the user is locally at the machine (i.e. can be traced to a local tty).
Comment 6 Pierre Ossman 2010-06-03 08:17:21 EDT
(In reply to comment #4)
> Other options in addition to trying to reverse map the login-session-id
> include:
> 
>  * Adding an additional check for the XFree86_VT property on the root window

What will prevent someone from adding that to a remotely started X server?

>  * Allowing only privileged callers to start sessions with is-local=true
> 
> I'm leaning toward the second at the moment.    

Sounds safer, but how does that clash with the plan to have Xorg be root-less?
Comment 15 Pierre Ossman 2010-08-19 07:49:03 EDT
Any progress here? I'm not allowed to read the upstream bug entry, so I can't see if there is anything happening there.
Comment 16 Pierre Ossman 2010-09-18 07:05:22 EDT
Now that the upstream bug is resolved, could we get an updated package for rhel6 to test with?
Comment 18 Pierre Ossman 2010-12-23 04:06:02 EST
Ping! Comment? 6.1?
Comment 19 RHEL Product and Program Management 2011-01-07 10:53:07 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.
Comment 20 Josh Bressers 2011-04-07 13:05:05 EDT
This is public via the upstream bug. I'm opening this up.

I've assigned this bug CVE-2010-4664
Comment 21 Michal Sekletar 2015-10-14 05:30:45 EDT
Backporting upstream commit 4f88228f31a63c026c424a92827f26ad7535275c should fix this.
Comment 23 Frantisek Sumsal 2016-03-02 04:16:56 EST
1) Reproducer
# yum -y groupinstall "X Window System"
# yum -y install tigervnc-server xterm
# echo 'VNCSERVERS="0:root"' >> /etc/sysconfig/vncservers
# vncpasswd
## <enter password>
# vncserver :0
## Connect to vncserver via another machine (vncviewer)
## and run ck-launch-session
# ck-list-sessions

2) Output
a) Old package (ConsoleKit-0.4.1-3.el6.x86_64)
# ck-list-sessions
Session3:
	unix-user = '0'
	realname = 'root'
	seat = 'Seat4'
	session-type = ''
	active = FALSE
	x11-display = ':0'
	x11-display-device = ''
	display-device = '/dev/pts/1'
	remote-host-name = ''
	is-local = TRUE
	on-since = '2016-03-02T09:02:38.362275Z'
	login-session-id = '27'

b) New package (ConsoleKit-0.4.1-5.el6.x86_64)
# ck-list-sessions
Session2:
	unix-user = '0'
	realname = 'root'
	seat = 'Seat3'
	session-type = ''
	active = FALSE
	x11-display = ':0'
	x11-display-device = ''
	display-device = '/dev/pts/1'
	remote-host-name = ''
	is-local = FALSE
	on-since = '2016-03-02T09:14:03.494951Z'
	login-session-id = '1'
Comment 25 errata-xmlrpc 2016-05-10 20:58:29 EDT
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://rhn.redhat.com/errata/RHBA-2016-0942.html

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