Durante febrero Google informó en uno de sus blogs (https:// googleonlinesecurity.blogspot. cl), de una grave vulnerabilidad en glibc, la implementación de GNU de la librería estándar de C, en palabras simples, es uno de los ladrillos más básicos sobre el cual buena parte de la computación está construida.

Desde servidores de la NASA hasta el teléfono que usamos para jugar Candy Crush, pasando por el notebook donde día a día miles de personas escriben o utilizan para trabajar, todos usan glibc y todos son vulnerables a un ataque que permite que, en ciertas condiciones, un tercero pueda tomar el control de un computador/teléfono/servidor que utilice Linux.

La mayoría de los usuarios no se enteraron de esto y por lo mismo estamos expuestos a que sigan ocurriendo situaciones de ese tipo.

“La seguridad informática es una constante carrera entre los atacantes que encuentran vulnerabilidades y como explotarlas y los proveedores de software que cierran las brechas. Y en esta carrera todo minuto cuenta”, señala Emilio Davis, Gerente de Tecnología de khipu (https://khipu. com/).

Cuando Google hizo el anuncio, no existían versiones invulnerables para instalar en los servidores, por lo tanto era necesario estudiar el potencial ataque para tomar medidas preventivas.

El ataque usaba como base que la función getaddrinfo(), utilizada para obtener datos como la IP de un servidor a partir de su nombre, no manejaba correctamente respuestas maliciosamente largas, permitiendo incluir código a ejecutar en la respuesta.

Por lo tanto, mientras se esperaba una solución de fondo, fue posible esconder todos los servicios que consultan un DNS detrás de un proxy, que limitara el largo de la respuesta de los DNS potencialmente malignos. Y al día siguiente, cuando aparecieron versiones corregidas de glibc, hubo que actualizar todos los servidores.

“Esta forma de enfrentar las fallas de seguridad no es nueva, pero es alarmante ver lo poco que se utiliza. Se reduce a tres pasos. Estar atento a nuevas vulnerabilidades que te pueden afectar (http://cve.mitre.org/ y https://nvd.nist.gov son buenas fuentes), entender las vulnerabilidades que te afecten para diseñar una estrategia de mitigación provisoria y, finalmente, actualizar cuando tu proveedor tenga una respuesta definitiva”, sentencia Davis.