Etiqueta: vulnerability

FP Lazy State Restore: nueva vulnerabilidad en los procesadores Intel Core

Intel ha publicado una nueva vulnerabilidad que afecta a sus procesadores la cual aprovecha debilidades en la ejecución especulativa, al igual que Meltdown y Spectre.

Extraída de betanews.com

Era de esperar: una vez que los investigadores han puesto el ojo sobre los microprocesadores, era solo cuestión de tiempo que fueran descubriéndosemás vulnerabilidades y con mayor frecuencia. Desde el descubrimiento de Spectre y Meltdown, hemos asistido a un desfile de fallos de seguridad relacionados con la ejecución especulativaHoy tratamos FP Lazy State Restore.

Aunque no se han dado muchos detalles técnicos de la vulnerabilidad, a la que se ha asignado el identificador CVE-2018-3665, se ha publicado que el error está relacionado con la forma de guardar y restaurar los registros de estado de la unidad de coma flotante (Floating Point Unit, FPU, y de ahí el nombre de la vulnerabilidad: ‘Floating Point Lazy State Restore’).

¿Y por qué el “lazy“? La FPU guarda el estado de las operaciones que está realizando. Cuando se da un cambio de contexto en el procesador, este puede indicar a la FPU que este estado sea guardado automáticamente o de forma “vaga”. En este último caso, el estado no se guarda hasta que el nuevo proceso ejecute una operación de punto flotante que requiera salvar datos en los registros de la unidad. Es decir, en esta modalidad la FPU no realiza salvado ni recuperación de estados a no ser que realmente se necesite, ahorrando varios ciclos de computación.

Al igual que las dos vulnerabilidades antes mencionadas, el error está efectivamente relacionado con la ejecución especulativa, pero en este caso es el software el que puede elegir entre el guardado inmediato o “vago” de contexto, por lo que los fabricantes de sistemas operativos podrán corregir esta vulnerabilidad a través de una actualización de software.

Aunque no existen muchos detalles más allá de estos, parece ser similar a la variante 3A de Spectre (Rogue System Register Read). Este error podría permitir la obtención de información sensible almacenada por distintas aplicaciones, incluyendo claves de cifrado, lo que la convierte en una vulnerabilidad con un fuerte impacto.

Actualmente la vulnerabilidad no afecta a los procesadores AMD, tampoco a las últimas versiones de OpenBSD, DragonflyBSD, Linux con kernel 4.9 o las versiones de Windows más modernas, aunque Microsoft no ha dado muchos detalles al respecto más allá de confirmar un parche en julio.

También se sabe que Intel está trabajando con el equipo de Red Hat para dar solución a este problema con la máxima celeridad.

New ‘Lazy FP State Restore’ Vulnerability Found in All Modern Intel CPUs:

https://thehackernews.com/2018/06/intel-processor-vulnerability.html

 

RedHat. Lazy FPU Save/Restore

Zip Slip, oportuno rebranding de una vieja vulnerabilidad

Se ha detectado la posibilidad de sobreescribir archivos arbitrarios, que suele permitir ejecutar código arbitrario, en múltiples proyectos software de envergadura

Sobreescritura de archivos arbitrarios al descomprimir un archivo conteniendo nombres de archivo que escalan directorios. Eso es todo. Pero ya sabemos que cualquier cosa vende más con un nombre pegadizo y un logo bonito. En este caso, los responsables de localizar esta vieja vulnerabilidad en múltiples proyectos importantes fueron los componentes del equipo de seguridad de Snyk, una empresa dedicada a encontrar y arreglar vulnerabilidades en dependencias software.

Técnicamente, la vulnerabilidad no es ninguna obra maestra, ni siquiera es nueva. Tiene gracia buscar ‘zip directory traversal’ en Google y encontrarse como primer resultado un repositorio de GitHub que permite generar un archivo para explotar esta vulnerabilidad. Actualizado por última vez hace 7 años. Y cuya descripción reza así (traducida del inglés):

La mayoría de los programas comerciales para zip (winzip, etc) impedirán la extracción de archivos zip cuyos archivos internos contengan rutas con caracteres que escalen directorios. Sin embargo, algunas librerías de desarrollo software no incluyen estos mismos mecanismos de protección (ej. Java, PHP, etc).

Volviendo al apartado técnico, la vulnerabilidad es bastante fácil de comprender si analizamos una de las líneas de código vulnerables en Apache Storm:

  • File file = new File(unzipDir, entry.getName());

Esta línea forma parte del código encargado de descomprimir un archivo ZIP.‘file’ será un objeto que representa el archivo interno que está siendo extraído, pero tras la extracción, ‘unzipDir’ el directorio de destino para la extracción, y‘entry.getName()’ devuelve la ruta dentro del ZIP del archivo que está siendo extraído. El constructor de la clase ‘File’ en Java (que es lo que se ejecuta con‘new’ ahí) acepta dos parámetros en una de sus versiones: el primero es una ruta madre, y la segunda una ruta hija. Si leemos la documentación, simplemente dice que une la ruta madre y la ruta hija para crear el archivo, sin hacer referencia a validaciones de seguridad. Por tanto, ¿qué pasa si las rutas son las siguientes?

  • Madre: /tmp/decompressed_file/
  • Hija: ../../etc/passwd

Como recordamos, dos puntos seguidos en una ruta significa que retrocedemos un directorio, con lo que uniendo esas dos rutas terminaríamos extrayendo el archivo en ‘/etc/passwd’… El escenario de explotación más sencillo: un sistema que acepte y procese archivos ZIP, que los descomprima en un directorio temporal. No tiene que ser un único archivo, de hecho es un vector de ataque bastante bueno si no conoces el sistema, ya que puedes especificar múltiples archivos que afecten a distintas configuraciones.

Ahora que conocemos de qué va la cosa, pasamos a ver el por qué se da esto ahora. Tiene una explicación simple: hay múltiples lenguajescomo JavaScriptRuby.NETGo… pero especialmente Java, para los que no existen librerías estándares de manipulación de archivos comprimidos a alto nivel. Esto ocasiona que los interesados en disponer de esta funcionalidad terminen programándola ellos, de forma despreocupada por no ser un trozo de código especialmente divertido, introduciendo esta vulnerabilidad. Normalmente, si eres un programador de algo tan específico como una librería, conoces bastante bien el dominio del problema y contemplas este tipo de errores.

Uno de los imperativos en programación es “escribe tan poco código como puedas”, es decir, intenta tirar lo máximo posible de código existente, librerías, frameworks Básicamente, “quien mucho habla, mucho yerra”, pero en el ámbito de la programación. Y además, si falla siempre puedes echarle la culpa a otro…

Más información:
 
Zip Slip Vulnerability (Arbitrary file write through archive extraction)
https://github.com/snyk/zip-slip-vulnerability