CVE-2020-27949 PoC — Apple Kernel 安全漏洞

Source

Associated Vulnerability

Readme

# Reading and writing memory of other processes using fasttrap
The `/dev/fasttrap` device for creating trap nodes in user-space processes for 
the `pid` and `objc` providers has the permissions `666`. In contrast to 
`/dev/dtrace`, which is also `666`, fasttrap lacks a permission check. This 
allows any process to issue a `FASTTRAPIOC_MAKEPROBE` or `FASTTRAPIOC_GETINSTR`
ioctl.  
An attacker can create probes in any other process for any memory 
location using `FASTTRAPIOC_MAKEPROBE`. On activation of these probes, the 
values at the specified memory location is replaced with a trap instruction 
(`0xCC` on x86) and the original value is placed in a shadow memory. Retrieving 
the original value is possible with the `FASTTRAPIOC_GETINSTR` ioctl. This 
allows the attacker to read arbitrary memory of another process by placing 
multiple traps.

This vulnerability is tracked as CVE-2020-27949, [fixed in macOS Big Sur 11.1,
Security Update 2020-001 Catalina, Security Update 2020-007 Mojave
](https://support.apple.com/HT212011).

## Disclosure Timeline
* 2020-07-07 -> Initial disclosure to Apple Product Security.
* 2020-07-08 <- Investigation confirmation.
* 2020-10-28 -> Request for status update.
* 2020-12-07 <- Notification about upcoming update that addresses issue.
* 2020-12-14 <- Update released.

## Requirements
* Attacker can execute code with regular user permissions (non-elevated)
* Probes in the victim process must be enabled (i.e. the victim must be run 
under DTrace)

## Tested system configurations
- SIP is on (no exceptions)
- 10.15.5 on iMac Late 2012
- 10.15.5 on MacBook Pro 2020

## Impact
* Attacker can read memory of other processes executed under DTrace without 
elevated permissions. Even reading memory from processes running as root is 
possible.
* Attacker can write the trap instruction value (`0xCC` on x86) to any memory 
location of other processes executed under DTrace without elevated permissions. 
Even writing memory to processes running as root is possible. As part of other
instructions or jump addresses, the victim's control flow can be altered,
allowing escalation of privileges.

## Expectations
As a user, I expect that enabling DTrace only allows processes with root 
permissions to trace, instrument, or modify other processes. DTrace is a 
valuable tool for administrative tasks offering tools like `dtruss`, `iotop`, 
etc.

## Exploit details
Our victim (`target`) is an executable running as root. The 
attacker (`memaccess`) is an executable running with regular user 
permissions. The tracing script `libc_monitor.d` records the number of calls to 
functions in the `libsystem_c.dylib` shared object (this is just a 
simple example of an administrative script a machine owner might run).  

1. Victim is executed
2. The attacker creates a probe with victim's PID and a memory location they 
are interested in.
3. The attacker waits for DTrace to trace the victim process. This could 
happen as part of an administrative operation where the machine owner wants to 
trace functions in the victim process (e.g. `libc_monitor.d`).
4. When DTrace starts tracing the victim, the previously created probes will be
enabled, thus, replacing the original memory values.
5. The attacker uses `FASTTRAPIOC_GETINSTR` to read the memory values of the 
created probes.  
  
Step 4 replaces memory in the victim process with the trap instruction value. 
Depending on the application, an attacker can use this to write a previously 
known value to a critical memory location. For example, the attacker could 
control the seed of an RNG or replace cryptographic keys in a process.  
  
Note: The attacker never requires elevated or root permissions.  
Note 2: Self-written DTrace scripts are not required. For example, `dapptrace` 
also uses the `pid` provider to trace any function.

## Proposed Fix
Implement privilege checks in `/dev/fasttrap` like in `/dev/dtrace` or remove 
the world-writable permission.  

Note: We did not check the released fix.

## Instructions
1. Ensure, that DTrace is available and working correctly
2. Run `target` and follow the instructions on-screen

File Snapshot

 [4.0K]  /data/pocs/4b62dff4cf3938ec5b064ab150e521818eb3cd39
├── [ 216]  CMakeLists.txt
├── [3.3K]  exploit.cpp
├── [ 154]  libc_monitor.d
├── [1.0K]  LICENSE
├── [4.0K]  README.md
├── [1.1K]  shared.cpp
├── [ 363]  shared.h
└── [ 866]  target.cpp

0 directories, 8 files

Remarks