Bug 1856774 (CVE-2020-14353)

Summary:	CVE-2020-14353 kernel: keys: for keyctl prevent creating a different user's keyrings in RHEL-6.10
Product:	[Other] Security Response	Reporter:	Alex <allarkin>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	acaringi, allarkin, aquini, bhu, blc, bmasney, brdeoliv, carnil, cye, dbohanno, dhoward, dvlasenk, esammons, esandeen, fhrbata, hkrzesin, iboverma, jarod, jfaracco, jlelli, joe.lawrence, jross, jshortt, jstancek, kcarcia, kernel-mgr, lcapitulino, lgoncalv, lzampier, matt, mcressma, mlangsdo, mleitner, mmilgram, nmurray, pmatouse, ptalbert, qzhao, rparrazo, rrobaina, rt-maint, rvrbovsk, rysulliv, scweaver, sukulkar, williams, wmealing, ycote, ykopkova, zhijwang
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	rhel-7.5 that is kernel-3.10.0-794.el7 and all higher	Doc Type:	If docs needed, set a value
Doc Text:	[REJECTED CVE] A keys creation with an incorrect permissions flaw was found in the Linux kernel’s keyctl subsystem. This flaw allows a local user to create user session keyrings for another user. The highest threat from this vulnerability is to integrity.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-07-14 13:28:03 UTC	Type:	---
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:	1775606

Description Alex 2020-07-14 12:38:29 UTC

Unprivileged user can create (using keyctl) user session keyrings for another user. This is problematic because these "fake" keyrings won't have the right permissions. In particular, the user who created them first will own them and will have full access to them via the possessor permissions, which can be used to compromise the security of a user's keys.

Upstream patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=237bbd29f7a049d310d907f4b2716a7feef9abf3

If being used by root-level processes, then could be used securely without possibility of leaking keys between users
(see http://kernsec.org/pipermail/linux-security-module-archive/2017-September/003318.html ),
so likely this is the task for modules and programs (for rhel6) to use keyctl kernel functionality securely (the implicit creation method) without such usage of user-space keyring keys.

Comment 1 Alex 2020-07-14 12:38:35 UTC

Acknowledgments:

Name: Eric Biggers (Google)

Comment 3 Alex 2020-07-14 12:38:41 UTC

External References:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=237bbd29f7a049d310d907f4b2716a7feef9abf3
http://kernsec.org/pipermail/linux-security-module-archive/2017-September/003318.html

Comment 9 Salvatore Bonaccorso 2020-08-07 07:40:02 UTC

The CVE assigned here seem a duplicate of the already assigned CVE-2017-18270.

Comment 11 Petr Matousek 2020-08-12 12:06:00 UTC

(In reply to Salvatore Bonaccorso from comment #9)
> The CVE assigned here seem a duplicate of the already assigned
> CVE-2017-18270.

Salvatore, it is, indeed. thank you for the heads up!

*** This bug has been marked as a duplicate of bug 1580979 ***

Comment 18 Alex 2020-08-13 11:59:34 UTC

Statement:

This flaw was found to be a duplicate of CVE-2017-18270. Please see https://access.redhat.com/security/cve/CVE-2017-18270 for information about affected products and security errata.