whw0x455/cve-2023-41992Proof-of-Concept für CVE-2023-41992, eine macOS-Kernel-Schwachstelle, die Exploitation-Techniken demonstriert und eine Patch-Analyse bereitstellt.
Dies ist ein Proof-of-Concept für CVE-2023-41992. Und zuallererst hat dies nichts mit Jailbreak zu tun! Es befindet sich noch in der Entwicklung.
Vielen Dank an alle, die mir bisher geholfen haben. Aus Datenschutzgründen werde ich Sie hier möglicherweise nicht auflisten. Schreiben Sie mir eine DM, wenn Sie möchten!
Soweit ich weiß, befindet sich der Patch in ipc_right_destroy. Jemand hat auch darauf auf X (oder Twitter) hingewiesen.
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));
Die Verwendung von ipc_right_destroy, um einen IPC-Eintrag ohne Typ im IPC-Space zu erhalten, würde eine Exception auslösen. Siehe [0] und [1] unten.
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] wird die Aufgabe im Drittanbieter-App-Sandbox nicht töten. Ich habe zuvor mach_thread_self() gewählt, weil das das einzige gepinnte Sende-Recht war, das ich finden konnte.
Aber ohne ReportCrash oder SIGKILL zu vermeiden, wird der Fehler im WebContent-Sandbox nicht hilfreich sein. Also habe ich etwas tiefer gegraben.
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);
}
...
Fatal Mach port guards - always delivered synchronously.
Ich kann einfach einen Thread-Exception-Port für den Thread setzen, der den Fehler auslöst, und die Exception-Benachrichtigung nicht verarbeiten. Der Kernel wartet hier nur auf eine Antwort, kein SIGKILL.
Panic in ipc_right_copyout() mit einem NULL-Eintrag.