Lo primero importante es pensar sobre el significado de este agujero de seguridad. Esta es una escalada de privilegios locales : si un atacante puede ejecutar el código de su elección en la máquina, con privilegios "normales", luego ese atacante puede usar este agujero para obtener más privilegios extendidos en esa máquina.
En general, para un sistema de escritorio, cuando los atacantes pueden ejecutar su propio código en su máquina, ya han ganado. En los sistemas de escritorio, sus propias acciones, como "usuario normal", se realizan como proceso en ejecución, desde el punto de vista del kernel, con los privilegios asociados a su cuenta de usuario. Si un atacante logra ejecutar su propio código, lo hará subvirtiendo una de tus aplicaciones o haciendo que, sin saberlo, ejecutes un protector de pantalla aparentemente honesto o algo así. Los privilegios asociados a su cuenta son suficientes para saquear el contenido de todos sus archivos, mostrar anuncios falsos, secuestrar sus conexiones de red y, en general, robar toda su vida. Además, obtener privilegios de root en la máquina no aumenta sustancialmente el alcance del desastre, aunque puede facilitarle la vida al atacante.
Además, como "usuario normal", ya tiene formas de obtener privilegios de root, y los usa de manera regular, por ejemplo, para autorizar una actualización del plugin de Flash. El sistema actualizador le pedirá su contraseña y la usará para solicitar y obtener privilegios de root. Un atacante que puede ejecutar código bajo su nombre solo tiene que imitar una actualización de Flash para mostrar la ventana emergente y obtener los privilegios. En ese sentido, la nueva vulnerabilidad es irrelevante para un sistema de escritorio . En consecuencia, no hay prisa en arreglarlo.
Los agujeros de escalamiento de privilegios tienen mucho más sentido en servidores compartidos , donde varios usuarios que pueden ser hostiles entre sí comparten el mismo hardware, y el sistema operativo debe arbitrar entre los usuarios y protegerlos de cada uno. otro. Los servidores compartidos son un modelo antiguo, cuando hablamos de mainframes . Un profesional de la seguridad de la información que ahora tiene unos cuarenta años debe haber estado expuesto a ese modelo cuando era estudiante, en los años 80 o 90. En ese momento, los estudiantes de computación solían usar terminales en alguna sala de computación compartida y accedían a uno o unos pocos servidores centrales con sistemas operativos similares a Unix. La escalada de privilegios era entonces un grial muy solicitado.
Esto rara vez se aplica hoy en día. En este momento, en 2015, cuando hay hardware compartido, a los usuarios se les otorgan máquinas virtuales, no simplemente cuentas shell. Hay todavía lugares donde los servidores se comparten de la forma anterior, pero son una especie que desaparece. Si sus máquinas OS X son servidores que se utilizan de esa manera, con usuarios en los que no todos pueden confiar (o que no confían entre sí), entonces sí, el agujero de la escalada de privilegios es una gran preocupación. Sin embargo, es probable que este no sea el caso.
Suponiendo que aún quieres arreglar el agujero rápidamente instalando el parche de Esser, tienes dos puntos a considerar:
-
Básicamente, está insertando en su máquina, con "privilegios del kernel", un fragmento de código descargado de Internet. Esto conlleva una gran dosis de confianza. Debe asegurarse de que la persona de Internet que aparece con el nombre de "Stefan Esser" sea lo suficientemente confiable, y que nadie más pueda alterar el parche donde está almacenado o mientras lo descarga.
¿Cómo alguna "garantía" de otra persona de Internet , incluso con un avatar impresionante, creará más confianza?
Sin embargo, podría obtener el código fuente, auditarlo y luego compilarlo usted mismo. Pero si cree que puede hacerlo, entonces no necesita ninguna ayuda de un sitio de StackExchange; ya sabes lo suficiente.
-
El parche cambia el comportamiento de la máquina, conceptualmente para hacerlo "mejor" (o "más seguro"), pero un cambio siempre es un cambio y puede romper las cosas. Es posible que algún desarrollador de aplicaciones, en algún lugar, haya notado que algunas variables de entorno DYLD_ * sobrevivan a través de la ejecución de SUID, y en realidad lo haya usado para alguna funcionalidad (sin notar necesariamente que esto tiene implicaciones de seguridad). Si bien el parche parece ser lo suficientemente inofensivo (al menos por lo que veo en el código fuente, pero ¿puede confiar en me ?), No puedo excluir la posibilidad de que afecte el comportamiento de algunas partes de el sistema operativo o las aplicaciones.