El exploit usa una combinación de tres vulnerabilidades. Cada vulnerabilidad es un error en un componente de iOS que permite al atacante hacer cosas que se supone que no deben ser posibles.
Etapa 1 ( CVE-2016-4657 ) es un error en WebKit , una biblioteca de código utilizada para representar páginas web. El código WebKit se ejecuta en el contexto del navegador web Safari de iOS. Aún no se han publicado detalles, solo la descripción como "un problema de corrupción de memoria se solucionó a través de un mejor manejo de la memoria". Esto podría ser un desbordamiento de búfer , un use-after-free , o algún otro tipo de error similar. La idea general de los errores de corrupción de memoria es que el atacante pasa datos inconsistentes (aquí, algunos contenidos de la página web, como HTML, CSS, JavaScript, etc.) y en lugar de detectar la inconsistencia, el programa se comporta de manera inconsistente y termina por sobrescribir. Algunas de sus propias instrucciones con datos suministrados por el atacante. Esto le permite al atacante ejecutar el código de su elección en Safari.
Etapa 3 ( CVE-2016-4656 ) también es un error de corrupción de memoria sobre el cual no se han publicado detalles, pero esta vez en el kernel. Este error permite que una aplicación iOS corrompa algunas estructuras de datos en el kernel y ejecute código en el kernel o (sospecho que dada la descripción) al menos eleva los privilegios de la aplicación que realiza la llamada para que pueda hacer cosas que las aplicaciones no deben. para hacer, como instalar programas que eviten los permisos normales de iOS y así lo permitan, por ejemplo, instalar spyware que no se mostrará en la lista de aplicaciones instaladas porque se enmascara como parte del sistema operativo básico.
Etapa 2 ( CVE-2016-4655 ) es una habilitador para la etapa 3. Normalmente, no debería importar que el programa sepa cómo el núcleo asigna su memoria. Y si el atacante puede hacer que el kernel ejecute código arbitrario, el juego se pierde. Pero puede suceder (y este es probablemente el caso aquí) que el atacante no tiene mucho espacio para jugar. Por ejemplo, tal vez haya una verificación de tamaño presente pero ligeramente desactivada, por lo que el atacante solo puede sobrescribir algunos bytes después del lugar donde se encuentran los datos inyectados. En tales casos, es posible que el atacante necesite saber exactamente qué colocar en esa ubicación, de lo contrario no podrá causar ningún efecto interesante. Si la ubicación que pueden sobrescribir es un puntero, deben saber qué colocar allí para hacer que el kernel utilice datos válidos pero incorrectos, en lugar de un puntero no válido que podría causar un bloqueo. Por ejemplo, cambie un puntero a una lista de capacidades a la dirección de un lugar en la memoria que se sabe que contiene lo que parece una lista que contiene algunas capacidades clave del sistema. Para eso, saber dónde mapea el núcleo sus datos le permite al atacante calcular el valor del puntero correcto.
Para ser claros, solo estoy dando ejemplos de métodos de ataque plausibles que se ajustan a las descripciones de una línea que se han publicado en este momento.
La mejor manera de tener una idea de cómo funciona esto es escribir algunas hazañas. Obtenga algunas versiones antiguas de software (preferiblemente de código abierto) con vulnerabilidades conocidas explotables , y ve y escribe un exploit. También es posible que desee reproducir algunos CTF .