martes, 5 de diciembre de 2017

Cuando tu parche de software no soluciona una vulnerabilidad


A finales del mes de noviembre, un desarrollador de software turco llamado Lemi Orhan Ergin twitteó que había una falla de seguridad crítica en la última versión del sistema operativo MAC (llamado High Sierra o versión 10.13). 

La criticidad era bastante alta pues permitía a un usuario ganar acceso con derechos de administrador en un computador MAC sin entrar ninguna clave. En el sistema operativo MacOS, como en todos los sistemas basados en Unix, el usuario “root” tiene alto acceso al sistema y por supuesto la situación es considerada gravísima. Quien use esta cuenta puede crear nuevos usuarios, habilitar acceso remoto y evitar la necesidad de acceso físico en un futuro.

Una vez hecho público, otros investigadores confirmaron esta vulnerabilidad y agregaron que era posible explotarla de manera remota. Este hecho convierte esta vulnerabilidad en una de las más serias y de alto impacto de los últimos años y por esta razón Apple liberó muy rápidamente un parche que arreglaba el problema. O eso pensamos todos.

Desafortunadamente, el parche reintroducía la vulnerabilidad descubierta por el desarrollador turco. Y esta es una situación que vale la pena analizar.

Cuando el producto de software que una compañía provee presenta vulnerabilidades de alto impacto, los desarrolladores dedican personal y tiempo valioso en solucionarlas.

Usualmente arreglar una vulnerabilidad puede tomar varias semanas, o incluso meses. El equipo de trabajo debe verificar que el nuevo código arregla la vulnerabilidad, que no introduce nuevas vulnerabilidades y que la funcionalidad no cambia. Esto se logra con el llamado “regression testing”, que no es otra cosa que hacer pruebas al software y su funcionalidad. También debe probarse la seguridad del sistema con los llamados “penetration testing”. Solo después de pasar estos requerimientos, el código que soluciona un problema debe liberarse.

Sin embargo, cuando el problema es en un sistema operativo que es usado por millones quienes toman decisiones se enfrentan a un serio dilema. El equipo debe actuar lo más rápido posible y tener el código listo con el menor número de errores. Quienes desarrollan software saben que este es un delicado balance. En el caso de Apple, es claro que no hubo ciertas verificaciones y que se liberó el parche con la intención de solucionar un problema serio en el menor tiempo posible sin las verificaciones necesarias.

Para mala fortuna de Apple, no se logró el objetivo y la compañía es hoy blanco de burlas y críticas por su falta de cuidado. Los responsables de liberar el código deben estar trabajando afanosamente contra el reloj y bajo la presión de los ejecutivos y el público en general.

Esta es una lección importante de aprender. En ocasiones las presiones financieras o de tiempo obligan a saltarse buenas prácticas que existen precisamente para evitar la ocurrencia de estos problemas. Apple tiene ingentes recursos financieros y este será un traspié más en la larga historia de errores de software que poco daño causará en el mediano o largo plazo.

Sin embargo, la historia puede ser muy diferente para compañías de software con recursos limitados. Para una pequeña empresa las consecuencias no se limitan a costos financieros o la pérdida de un contrato vital, sino que pueden desestabilizar o amenazar la existencia de la empresa misma.