
CVE-2023-41992 के लिए प्रूफ-ऑफ-कॉन्सेप्ट, एक macOS कर्नेल भेद्यता, जो शोषण तकनीकों का प्रदर्शन करती है और पैच विश्लेषण प्रदान करती है।
यह CVE-2023-41992 के लिए एक proof-of-concept है। और सबसे पहले, इसका jailbreak से कोई लेना-देना नहीं है ! और यह अभी भी विकासाधीन है।
अब तक मेरी मदद करने वाले सभी का धन्यवाद। गोपनीयता कारणों से, हो सकता है मैं आपको यहाँ सूचीबद्ध न करूँ। अगर आप चाहें तो मुझे DM करें !
जहाँ तक मुझे पता है, पैच ipc_right_destroy में है। किसी ने यह बात X (या Twitter) पर भी बताई थी।
diff --git a/osfmk/ipc/ipc_right.c b/osfmk/ipc/ipc_right.c
index a81ac21..32a9a3e 100644
--- a/osfmk/ipc/ipc_right.c
+++ b/osfmk/ipc/ipc_right.c
@@ -912,7 +912,6 @@ ipc_right_destroy(
mach_port_type_t type;
bits = entry->ie_bits;
- entry->ie_bits &= ~IE_BITS_TYPE_MASK;
type = IE_BITS_TYPE(bits);
assert(is_active(space));
ipc_right_destroy का उपयोग करके ipc space में छोड़े गए एक none प्रकार के ipc entry को प्राप्त करने से एक exception उत्पन्न होगा। नीचे [0] और [1] देखें।
kern_return_t
ipc_right_destroy(
ipc_space_t space,
mach_port_name_t name,
ipc_entry_t entry,
boolean_t check_guard,
uint64_t guard)
{
...
if (type == MACH_PORT_TYPE_SEND) {
if (ip_is_pinned(port)) {
assert(ip_active(port));
is_write_unlock(space);
mach_port_guard_exception_pinned(space, // <---- [0]
name, port, MPG_FLAGS_MOD_REFS_PINNED_DESTROY);
return KERN_INVALID_CAPABILITY;
}
ipc_hash_delete(space, ip_to_object(port), name, entry);
}
...
if ((type & MACH_PORT_TYPE_RECEIVE) &&
(check_guard) && (port->ip_guarded) &&
(guard != port->ip_context)) {
/* Guard Violation */
uint64_t portguard = port->ip_context;
ip_mq_unlock(port);
is_write_unlock(space);
/* Raise mach port guard exception */
mach_port_guard_exception(name, // <---- [1]
0, portguard, kGUARD_EXC_DESTROY);
return KERN_INVALID_RIGHT;
}
[0] थर्ड-पार्टी ऐप सैंडबॉक्स में task को kill नहीं करेगा। मैंने पहले mach_thread_self() चुना क्योंकि वह एकमात्र pinned send right था जो मुझे मिल सका।
लेकिन ReportCrash या SIGKILL से बचे बिना, यह bug WebContent सैंडबॉक्स में उपयोगी नहीं होगा। इसलिए मैंने थोड़ी और गहराई से जाँच की।
void
mach_port_guard_ast(thread_t t,
mach_exception_data_type_t code, mach_exception_data_type_t subcode)
{
...
if (reason <= MAX_FATAL_kGUARD_EXC_CODE) {
/*
* Fatal Mach port guards - always delivered synchronously.
* Check if anyone has registered for Synchronous EXC_GUARD, if yes then,
* deliver it synchronously and then kill the process, else kill the process
* and deliver the exception via EXC_CORPSE_NOTIFY.
*/
if (task_exception_notify(EXC_GUARD, code, subcode) == KERN_SUCCESS) {
task_bsdtask_kill(task);
} else {
exit_with_guard_exception(get_bsdtask_info(task), code, subcode);
}
...
कर्नेल में mach_port_guard_ast mach port guard exceptions को संभालता है। एक घातक exception के लिए, यह पहले exception port की तलाश करता है। यदि exception notify KERN_SUCCESS लौटाता है, तो SIGKILL करता है। यह आशाजनक लगता है, हर वह task जिसने घातक mach port guard exception ट्रिगर किया है, kill कर दिया जाएगा। हालाँकि...
घातक Mach port guards - हमेशा synchronously डिलीवर किए जाते हैं।
मैं बस उस thread के लिए एक thread exception port सेट कर सकता हूँ जो bug ट्रिगर करता है, और exception notification को process नहीं करता। Kernel यहाँ सिर्फ reply का इंतज़ार करेगा, कोई SIGKILL नहीं।
NULL entry के साथ ipc_right_copyout() में panic।