Source: security@debian.org
The sg implementation in the Linux kernel through 4.9 does not properly restrict write operations in situations where the KERNEL_DS option is set, which allows local users to read or write to arbitrary kernel memory locations or cause a denial of service (use-after-free) by leveraging access to a /dev/sg device, related to block/bsg.c and drivers/scsi/sg.c. NOTE: this vulnerability exists because of an incomplete fix for CVE-2016-9576.
Local privilege escalation is possible due to a flaw in the Linux kernel's SCSI generic (sg) implementation. This vulnerability allows attackers with access to a /dev/sg device to potentially read and write arbitrary kernel memory, leading to system compromise or a denial-of-service condition through a use-after-free scenario.
Step 1: Device Access: The attacker gains access to a /dev/sg device. This typically requires local user access, which could be obtained through other vulnerabilities or social engineering.
Step 2: Crafting the Request: The attacker crafts a malicious request to the /dev/sg device. This request will likely involve specific SCSI commands or parameters designed to trigger the vulnerability.
Step 3: Triggering the Flaw: The crafted request is sent to the /dev/sg device, which then interacts with the sg driver in the kernel. The driver processes the request, potentially leading to the use-after-free or arbitrary memory write condition.
Step 4: Memory Manipulation: The attacker leverages the vulnerability to either read sensitive kernel memory or overwrite kernel data. This could involve manipulating pointers, overwriting function pointers, or corrupting kernel data structures.
Step 5: Privilege Escalation/DoS: If successful, the attacker can either escalate their privileges to root (by overwriting a function pointer with a malicious payload) or cause a denial-of-service (by corrupting kernel memory, leading to a system crash).
The vulnerability stems from an incomplete fix for CVE-2016-9576. The sg implementation, specifically within block/bsg.c and drivers/scsi/sg.c, fails to properly restrict write operations when the KERNEL_DS option is set. This allows a local user to bypass intended memory access restrictions. The root cause is a lack of proper bounds checking or validation of user-supplied data when interacting with the /dev/sg device. This can lead to a use-after-free condition, where memory is accessed after it has been freed, or the ability to overwrite kernel memory. The incomplete fix likely missed a specific code path or edge case related to how the sg driver handles write requests, allowing the attacker to manipulate memory addresses and potentially execute arbitrary code in the kernel context. The vulnerability leverages the SCSI generic interface, which is designed for communication with SCSI devices, but can be exploited through crafted requests to the /dev/sg device.
While no specific APTs are directly linked to this CVE, any threat actor with the capability to develop or acquire exploits for local privilege escalation would be a potential threat. This vulnerability could be leveraged by attackers to gain root access after initial compromise. This CVE is not listed on the CISA KEV list.
Monitor system logs for unusual activity related to /dev/sg devices. Look for unexpected read/write operations or error messages.
Analyze SCSI command requests sent to /dev/sg devices for suspicious patterns or malformed data.
Implement kernel auditing to track access to /dev/sg devices and monitor for suspicious system calls.
Monitor for kernel crashes or unexpected system behavior that could indicate a use-after-free or memory corruption issue.
Use file integrity monitoring tools to detect changes to kernel modules or critical system files.
Apply the latest security patches for the Linux kernel. Ensure the kernel version is up-to-date to include the fix for CVE-2016-10088.
Restrict access to /dev/sg devices. Limit access to only necessary users or groups.
Implement kernel hardening techniques, such as enabling kernel address space layout randomization (KASLR) and other security features.
Regularly audit system logs and monitor for suspicious activity related to SCSI devices and kernel operations.
Consider disabling the SCSI generic driver (sg) if it is not required by the system. This will mitigate the attack surface.