None
An information disclosure vulnerability exists in the call fault reporting functionality of DCERPC library as used in Apple macOS 12.6.1 that can lead to use of uninitialized memory. A specially-crafted network packet can cause parts of uninitialized memory to be disclosed. An authenticated remote attacker can send a network request to trigger this vulnerability. A local attacker can write to a local socket to trigger this vulnerability.
The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.
Apple macOS 12.6.1
macOS - https://apple.com
5.3 - CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
CWE-457 - Use of Uninitialized Variable
DCERPC is a remote procedure call protocol that is the basis for RPC functionality on Windows. DCERPC framework on macOS implements this protocol and enables interoperability of Windows network services on macOS. For example, it is used on top of SMB, through which support for Active Directory is implemented. DCERPC framework is employed by rpcsvchost binary, which opens a number of UNIX sockets that expose different RPC functionality.
When replying to an invalid request packet with a fault, DCERPC framework will prepare the following structure to be sent:
struct
{
rpc_cn_common_hdr_t common_hdr;/* 00:16 common to all packets */
unsigned32 alloc_hint; /* 16:04 allocation hint */
/* 20:02 pres context, ie. drep */
rpc_cn_pres_context_id_t pres_cont_id;
unsigned8 alert_count; /* 22:01 pending alert count */
unsigned8 reserved; /* 23:01 alignment pad */
unsigned32 status; /* 24:04 runtime fault code or zero */
unsigned32 reserved2; /* 28:04 alignment pad m.b.z. */
stub_data_t stub_data; /* 32:yy stub data */
/* restore 4-byte alignment */
/* rpc_cn_auth_tlr_t auth_tlr; */ /* if auth_len != 0 */
} hdr;
Preparation of the packet to be dispatched happens in send_call_fault_action_rtn, which will call rpc__cn_transmit_buffers after setting the relevant structure fields. In rpc__cn_transmit_buffers we see following code:
if (call_rep->alloc_hint != 0)
{
RPC_CN_PKT_ALLOC_HINT (header_p) = call_rep->alloc_hint;
call_rep->alloc_hint -= (RPC_CN_CREP_ACC_BYTCNT (call_rep) - RPC_CN_CREP_SIZEOF_HDR (call_rep));
}
True branch above is hit if call_rep->alloc_hint is non zero and the value is copied into the packet to be sent. However, with a specific RPC request packet call_rep->alloc_hint can remain uninitialized, in which case 4 bytes of uninitialized heap data can be included in the packet to be sent.
This can be readily observed if the DCERPC server rpcsvchost is run with debug heap like so:
MALLOC_FILL_SPACE=1 DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib /usr/libexec/rpcsvchost -nolaunchd netlogon.bundle
Executing the proof of concept code will show something like the following hex dump:
0500 - version
0323 - packet type (fault) and flags
10000000
2000 - packet size
0000 - auth size
01000000 - call id
aaaaaaaa - alloc hint (leaked bytes)
000000000200011c00000000 - rest of the packet
With debug heap, allocated memory is initialized to contain values that are easy to spot, a series of 0xAA bytes in this case. With multiple simultaneous connections and proper memory layout control, otherwise sensitive data could possibly be leaked, which can be of use in further exploitation.
To trigger this vulnerabilit,y a call request that specifies a RPC_C_CN_FLAGS_FIRST_FRAG flag without RPC_C_CN_FLAGS_LAST_FRAG can be sent following a correct BIND request for one of the available RPC services.
On macOS, vulnerable code could be reached over network, after authentication, through SMB protocol. However, it can also be triggered through access to local UNIX sockets in /var/rpc/ncalrpc/* via a regular user.
Apple fixed this vulnerability internally and didn’t assign a CVE identifier.
2022-12-06 - Vendor Disclosure
2023-03-27 - Vendor Patch Release
2023-07-13 - Public Release
Discovered by Aleksandar Nikolic of Cisco Talos.