RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 585952 - CVE-2010-4664 ConsoleKit: Policy restrictions break-out via remote Virtual Network Computing (VNC) session [rhel-6.0]
Summary: CVE-2010-4664 ConsoleKit: Policy restrictions break-out via remote Virtual Ne...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ConsoleKit
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Michal Sekletar
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
Depends On:
Blocks: CVE-2010-4664 662543
TreeView+ depends on / blocked
 
Reported: 2010-04-26 14:20 UTC by Pierre Ossman
Modified: 2016-05-11 00:58 UTC (History)
11 users (show)

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.
Clone Of:
Environment:
Last Closed: 2016-05-11 00:58:29 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 28377 0 None None None Never
Red Hat Product Errata RHBA-2016:0942 0 normal SHIPPED_LIVE ConsoleKit bug fix update 2016-11-24 23:09:27 UTC

Description Pierre Ossman 2010-04-26 14:20:08 UTC
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 Program Management 2010-04-26 15:15:10 UTC
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 23:30:47 UTC
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-03 00:14:24 UTC
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 12:15:54 UTC
(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 12:17:21 UTC
(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 11:49:03 UTC
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 11:05:22 UTC
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 09:06:02 UTC
Ping! Comment? 6.1?

Comment 19 RHEL Program Management 2011-01-07 15:53:07 UTC
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 17:05:05 UTC
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 09:30:45 UTC
Backporting upstream commit 4f88228f31a63c026c424a92827f26ad7535275c should fix this.

Comment 23 Frantisek Sumsal 2016-03-02 09:16:56 UTC
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-11 00:58:29 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://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.