
En el blog de Reverse Engineering Mac OS X han publicado un artículo en el que se lleva a cabo la ingeniería inversa de la vulnerabilidad. La excusa para llevar a cabo la prueba de concepto es que Apple no informa mucho de sus actualizaciones de seguridad, no dicen si es explotable en instalaciones OS X por defecto o requiere condiciones particulares. Tras la lectura del artículo se puede ver como el error no es explotable en instalaciones OS X por defecto. La herramienta Diaphora creada por Joxean Koret permite obtener las diferencias entre un binario vulnerable y la actualización. El binaio de syslogd se encuentra en /usr/sbin/syslogd. En la imagen se puede ver como difiere en poco código.
![]() |
Figura 1: Diferencias en los binarios syslogd vulnerable y actualizado |
El código fuente de syslogd para OS X El Capitan 10.11.2 puede descargarse desde el dominio opensource.apple.com. El parche se encuentra realizado en el tamaño de asignación de reallocf(). El detalle del proceso de ingeniería inversa puede ser observado en el artículo, el cual recomendamos la lectura con una taza de café.
El lenguaje C es poderoso, pero pequeños errores pueden suponer la ejecución de código arbitrario, e incluso la escalada de privilegio. El programador de la pieza de código cometió un pequeño error, y su arreglo puede ser tan simple como el añadir un conjunto de parentésis. La función vulnerable se encuentra en add_lockdown_session(), y para llegar a ella se puede visualizar este árbol de funciones.
Cómo se puede visualizar el proceso de ingeniería inversa puede ser una tarea altamente compleja. La vulnerabilidad en syslogd se encontraba en una función, la cual con la configuración por defecto de OS X no es vulnerable, pero que dicha vulnerabilidad estaba ahí. Como se menciona anteriormente se recomienda la lectura de todo el proceso de reversing llevado a cabo y estar atentos al mínimo detalle.
![]() |
Figura 2: Árbol de llamadas en syslogd |
Cómo se puede visualizar el proceso de ingeniería inversa puede ser una tarea altamente compleja. La vulnerabilidad en syslogd se encontraba en una función, la cual con la configuración por defecto de OS X no es vulnerable, pero que dicha vulnerabilidad estaba ahí. Como se menciona anteriormente se recomienda la lectura de todo el proceso de reversing llevado a cabo y estar atentos al mínimo detalle.
No hay comentarios:
Publicar un comentario