CVE-2017-17807 in Linux
Summary
by MITRE
The KEYS subsystem in the Linux kernel before 4.14.6 omitted an access-control check when adding a key to the current task's "default request-key keyring" via the request_key() system call, allowing a local user to use a sequence of crafted system calls to add keys to a keyring with only Search permission (not Write permission) to that keyring, related to construct_get_dest_keyring() in security/keys/request_key.c.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 01/18/2023
The vulnerability identified as CVE-2017-17807 represents a critical access control flaw within the Linux kernel's key management subsystem, specifically affecting versions prior to 4.14.6. This issue resides in the KEYS subsystem which is responsible for managing cryptographic keys and credentials within the kernel space. The vulnerability stems from a missing access control check during the process of adding keys to a task's default request-key keyring, creating a pathway for privilege escalation and unauthorized key manipulation. The flaw is particularly concerning because it allows a local user to bypass intended permission boundaries that should prevent modification of keyrings where only Search permission is granted.
The technical implementation of this vulnerability occurs within the construct_get_dest_keyring() function located in security/keys/request_key.c, which handles the destination keyring selection process for request_key() system calls. When a user process invokes request_key() to create or access a key, the kernel should verify that the calling process has appropriate write permissions to the target keyring before allowing modifications. However, due to the missing access control check, the kernel fails to validate these permissions, enabling unauthorized key additions to keyrings where only search capabilities are permitted. This oversight creates a fundamental breach in the kernel's permission model, as the system call sequence can effectively escalate privileges by adding keys to restricted keyrings without proper authorization.
The operational impact of this vulnerability extends beyond simple privilege escalation, as it enables local users to potentially manipulate the key management system in ways that could compromise system security. An attacker could exploit this vulnerability to add malicious keys to keyrings that should be protected from modification, potentially leading to credential theft, unauthorized access to encrypted data, or the ability to bypass security controls that depend on keyring integrity. The vulnerability is particularly dangerous in multi-user environments or systems where keyrings are used for authentication and authorization purposes, as it allows attackers to circumvent the intended security boundaries that protect these critical system components. This flaw directly relates to CWE-284, which describes improper access control, and aligns with ATT&CK technique T1548.001 for privilege escalation through kernel exploits.
Mitigation strategies for CVE-2017-17807 require immediate kernel updates to version 4.14.6 or later, where the missing access control check has been properly implemented. System administrators should prioritize patching affected systems, particularly those running older kernel versions or custom kernel builds that may not have received the relevant security fixes. Additionally, organizations should implement monitoring for suspicious keyring modifications and review keyring permissions to ensure that only authorized processes can modify critical keyrings. The vulnerability demonstrates the importance of comprehensive access control validation in kernel subsystems and highlights the need for regular security audits of core kernel components. Defense in depth strategies should include limiting local user privileges where possible and implementing proper keyring access controls to minimize the potential impact of such vulnerabilities. The fix implemented in kernel version 4.14.6 properly validates permissions during keyring operations, ensuring that the request_key() system call respects the existing permission model and prevents unauthorized modifications to keyrings with restricted access levels.