Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
CVE-2023-41992 — Prueba de concepto para CVE-2023-41992, una vulnerabilidad del kernel de macOS, que demuestra técnicas de explotación y proporciona un análisis del parche. | Kitploit
Herramientas/GitHubGitHub/whw0x455/cve-2023-41992
Seguridad iOSForensia de MemoriaAnálisis de VulnerabilidadesExplotaciónExplotación de Binarios
GitHubwhw0x455/cve-2023-41992

CVE-2023-41992

Prueba de concepto para CVE-2023-41992, una vulnerabilidad del kernel de macOS, que demuestra técnicas de explotación y proporciona un análisis del parche.

Ver Repositorio
55125hace 10 mesesRevisado por Kitploit

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

CVE-2023-41992

Esta es una prueba de concepto para CVE-2023-41992. Y antes que nada, esto no tiene nada que ver con jailbreak. ¡Y todavía está en desarrollo.

Gracias a todos los que me han ayudado hasta ahora. Por razones de privacidad, es posible que no los mencione aquí. ¡DM si quieres!

parche

Por lo que sé, el parche está en ipc_right_destroy. Alguien también señaló esto en X (o Twitter).

root@kitploit:~
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));

Evitar ReportCrash o SIGKILL

Usar ipc_right_destroy para obtener una entrada ipc de tipo none dejada en el espacio ipc provocaría una excepción. Consulte [0] y [1] a continuación.

root@kitploit:~
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] no matará la tarea en el sandbox de aplicaciones de terceros. Elegí mach_thread_self() antes porque ese es el único derecho de envío fijo que pude encontrar.

Pero sin evitar ReportCrash o SIGKILL, el bug no será útil en el sandbox de WebContent. Así que profundicé un poco más.

root@kitploit:~
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 en el kernel maneja las excepciones de mach port guard. Para una excepción fatal, primero busca el puerto de excepción. Si el notify de excepción devuelve KERN_SUCCESS, hace un SIGKILL. Parece prometedor, cada tarea que desencadena una excepción fatal de mach port guard será eliminada. Sin embargo...

Mach port guards fatales - siempre entregados sincrónicamente.

Puedo simplemente establecer un puerto de excepción de hilo para el hilo que desencadena el bug, y no procesar la notificación de excepción. El kernel solo esperará una respuesta aquí, sin SIGKILL.

Una referencia a NULL ptr

  1. Crear un puerto receptor y un puerto víctima, insertar algunos derechos, hacer algo de port guard.
  2. Enviar el puerto víctima al puerto receptor en un descriptor de puerto.
  3. Desencadenar el bug en otro hilo con nuestro propio puerto de excepción.
  4. Recibir mensaje en el puerto receptor, pánico del kernel.

Pánico en ipc_right_copyout() con una entrada NULL.

referencia

  • blanket, código copiado para pruebas.
Descargar herramienta