Lo que necesita saber sobre la vulnerabilidad del kernel de linux config_keys

El 14 de enero, Perception Point, un equipo de investigación de seguridad, anunció un nuevo problema de seguridad (CVE-2016-0728 para aquellos a quienes les gusta hacer un seguimiento de estas cosas). El error afecta a los núcleos compilados con el interruptor de configuración del núcleo CONFIG_KEYS establecido en "on", y ha estado presente en todos los núcleos de Linux desde la versión 3.8. El exploit permite la escalada de la raíz al volver a poner a cero un número entero de 32 bits. El punto de percepción afirma que "aproximadamente decenas de millones de PC y servidores Linux, y el 66 por ciento de todos los dispositivos Android" están afectados.

Adrian Ludwig de Google, ingeniero principal de seguridad de Android, respondió que el exploit había sido parcheado y lanzado a código abierto a partir del 20 de enero.

Como siempre, todavía hay muchas preguntas. Hablemos de ellos.

Que esta pasando?

Hay un error en el kernel de Linux (versión 3.8 y superior) que permite a un atacante obtener acceso de root. El núcleo debe haber sido construido con el servicio Keyring habilitado, y un ataque debe hacer muchos cálculos matemáticos para que un número cuente lo más alto posible y luego volver a cero. Se necesitan 4.294.967.296 cálculos para volver a cero un número entero de 32 bits (dos a la potencia 32). Esto toma solo 30 minutos más o menos en una nueva CPU Intel i7, pero tomaría mucho más tiempo (como en mucho más tiempo) en una CPU del teléfono.

Una vez que el número va completamente (piense en cómo una máquina de pinball vuelve a cero una vez que su puntaje alcanza 999, 999, 999) y vuelve a cero, el atacante puede obtener acceso al espacio de memoria y ejecutar código como el superusuario.

¿Deberías estar preocupado?

Siempre deberíamos preocuparnos cuando surge una vulnerabilidad de seguridad. Esta vez no es diferente. Pero hay algunas cosas aquí que hacen que muchos cuestionen la cantidad de dispositivos potencialmente afectados.

• La configuración de kernel recomendada para dispositivos Android no tiene activada la variable CONFIG_KEYS, y eso significa que esta vulnerabilidad no tendrá ningún efecto. Las personas que hicieron su teléfono pueden haberlo habilitado, y las cocinas ROM personalizadas también podrían haberlo hecho.
• Todos los teléfonos Nexus no se ven afectados: utilizan la configuración predeterminada del núcleo y el Llavero no está habilitado en el núcleo.
• SELinux niega el vector de ataque, por lo que si su teléfono o tableta ejecuta Android 5.0 o superior, no debería verse afectado.
• La mayoría de los dispositivos que no ejecutan Android 5.0 o superior utilizarán una versión anterior del kernel de Linux y no se verán afectados.

Sí, muchas de las computadoras, teléfonos y tabletas se ven afectados por esta vulnerabilidad. Pero dudamos de los números que Perception Point ha dado.

No podemos auditar los 11, 000 modelos diferentes de Android que existen, pero podemos dirigir a todos con más preguntas a su foro de dispositivos relevante. En pocas palabras, si está ejecutando Lollipop, está a salvo. Si no lo está, mire la pantalla Acerca del dispositivo y verifique la versión de su kernel. Si es anterior a 3.8, estás a salvo.

¿Qué tengo que hacer?

Este es uno de esos problemas de seguridad que puede ser explotado por una aplicación, siempre que su teléfono sea vulnerable como mencionamos anteriormente. Debido a que hay muchos cálculos involucrados, tendrías que tener una mala aplicación ejecutándose en primer plano durante mucho tiempo, por lo que algo como un juego sería una buena aplicación para intentar piratear un exploit.

Para mantenerse seguro, no instale aplicaciones en las que no confía. Siempre.

Si no está seguro de en quién puede confiar, solo asegúrese de no permitir que se instalen aplicaciones de fuentes desconocidas y manténgase en Google Play.

Realmente es tan fácil estar 100 por ciento seguro de este.

¿Qué pasa con las actualizaciones de los exploits?

Ludwig de Google dice que el parche se lanzó el 20 de enero para código abierto y se entregó a todos los socios. Los fabricantes tendrán que incluir este parche para cumplir con el nivel de parche de seguridad del 1 de marzo de 2016 y posterior.