Mozilla, Fastly, Intel y Red Hat se han unido para desarrollar tecnologías que hacen de WebAssembly una plataforma universal para ejecutar código de forma segura en cualquier infraestructura, sistema operativo y dispositivo. Para el desarrollo conjunto del runtime y compiladores, que permite utilizar WebAssembly no solo en navegadores web, se ha formado la comunidad Bytecode Alliance.

Para crear programas portables entregados en formato WebAssembly que puedan ejecutarse fuera del navegador, se propone utilizar la API WASI (Interfaz del sistema WebAssembly), que proporciona interfaces de programas para la interacción directa con el sistema operativo (API POSIX para trabajar con archivos, sockets, etc.).

Una característica distintiva del modelo de ejecución de aplicaciones que utilizan WASI es el lanzamiento en un entorno de espacio aislado para aislar del sistema principal y el uso de un mecanismo de seguridad basado en la gestión de capacidades, para acciones con cada uno de los recursos (archivos, directorios, sockets, llamadas al sistema, etc.) la aplicación debe tener la autorización correspondiente (solo se proporciona acceso a la funcionalidad declarada).

Uno de los objetivos de la alianza creada es resolver el problema de la difusión de las aplicaciones modulares modernas con una gran cantidad de dependencias. En tales aplicaciones, cada dependencia puede ser una fuente potencial de vulnerabilidades o ataques. Obtener el control de dependencia le permite obtener el control sobre todas las aplicaciones asociadas con él.

Los miembros de Bytecode Alliance tienen la intención de preparar una solución completa para la ejecución segura de aplicaciones WebAssembly que inicialmente no son confiables.

Para la protección, se propone utilizar el concepto de nanoprocesos, en el que cada módulo de dependencia se separa en un módulo WebAssembly aislado por separado, cuya autoridad está configurada para vincularse solo a este módulo (por ejemplo, una biblioteca para procesar cadenas no puede abrir un socket o archivo de red).

A diferencia de la separación de procesos, los manejadores de WebAssembly son livianos y casi no requieren recursos adicionales ademas de que la interacción entre los manejadores no es mucho más lenta que llamar a funciones ordinarias.

Para el desarrollo conjunto, varios proyectos relacionados con WebAssembly, previamente desarrollados por separado por las compañías fundadoras de la alianza, se transfirieron bajo el ala de Bytecode Alliance:

• Wasmtime: un runtime para ejecutar aplicaciones WebAssembly con extensiones WASI como aplicaciones independientes regulares. Admite el lanzamiento del código de bytes de WebAssembly utilizando una utilidad especial de línea de comandos y el diseño de archivos ejecutables listos para usar (wasmtime está integrado en la aplicación como una biblioteca).
• Lucet: es un compilador y un runtime para ejecutar programas en formato WebAssembly. Una característica distintiva de Lucet es el uso de una compilación preventiva completa (AOT, por adelantado) en el código de máquina adecuado para la ejecución directa en lugar de JIT. El proyecto fue desarrollado por Fastly y optimizado para consumir recursos mínimos y lanzar rápidamente nuevas instancia.Como parte de un proyecto conjunto, se planea cambiar el compilador Lucet para usar Wasmtime como base.
• WAMR (WebAssembly Micro Runtime): es otro runtime para ejecutar WebAssembly, desarrollado originalmente por Intel para su uso en dispositivos IoT. WAMR está optimizado para un consumo mínimo de recursos y se puede usar en dispositivos con una pequeña cantidad de RAM. El proyecto incluye un intérprete y una máquina virtual para ejecutar el código de bytes de WebAssembly, una API (un subconjunto de Libc) y herramientas para administrar aplicaciones dinámicamente.
• Cranelift: es un generador de código que traduce una representación intermedia independiente del hardware en código máquina ejecutable optimizado para plataformas de hardware específicas. Cranelift admite la paralelización de la compilación de funciones para una generación muy rápida de resultados, lo que le permite usarlo para crear compiladores JIT (JIT basado en Cranelift se usa en la máquina virtual Wasmtime).
• WASI: una implementación independiente de la API WASI (Interfaz de sistema de ensamblaje web) para organizar la interacción con el sistema operativo.
• cargo-wasi: un módulo para el administrador de paquetes cargo que implementa un comando para compilar código Rust en el código de bytes de WebAssembly utilizando la interfaz WASI para usar WebAssembly fuera del navegador.
• wat y wasmparser: son analizadores para analizar texto (WAT, WAST) y representaciones binarias del código de bytes de WebAssembly.

from Linux Adictos https://ift.tt/2O9ve6P
via IFTTT

Investigadores de la Universidad Tecnológica de Graz (Austria) han revelado información sobre un nuevo método de ataque a través de ZombieLoad 2.0 (CVE-2019-11135), que permite extraer información confidencial de otros procesos, el sistema operativo, máquinas virtuales y enclaves seguros (TEE, Trusted Execution Environment). El problema solo afecta a los procesadores Intel. Los componentes para bloquear el problema fueron propuestos en la actualización de microcódigo de ayer.

El problema pertenece a la clase de MDS (Microarchitectural Data Sampling) y es una versión modernizada del ataque ZombieLoad, lanzado en mayo. ZombieLoad 2.0, así como otros ataques de la clase MDS, se basan en la aplicación de métodos de análisis de terceros a datos en estructuras microarquitectónicas (por ejemplo, en los buffers Line Fill Buffer y Store, en los que los datos utilizados en el proceso se almacenan temporalmente realizar operaciones de carga y almacenamiento).

Esta nueva variante de Zombieload se basa en una fuga que ocurre cuando se implementa el mecanismo TSA Asynchronous Abort (TSA) en la extensión TSX (Transactional Synchronization Extensions), que proporciona medios para trabajar con la memoria transaccional, lo que permite aumentar el rendimiento de las aplicaciones multiproceso debido a la exclusión dinámica operaciones de sincronización innecesarias (se admiten transacciones atómicas, que pueden aceptarse o interrumpirse).

En caso de interrupción, las operaciones realizadas con la región transaccional de la memoria se revierten. La cancelación de una transacción se realiza de forma asíncrona, momento en el que otros subprocesos pueden acceder a la memoria caché, que también se usa en la región de memoria de transacción descartada.

Desde el principio hasta la finalización real de una interrupción de transacción asíncrona, es posible que ocurran situaciones en las que el procesador, durante la ejecución especulativa de una operación, puede leer datos de buffers microarquitectónicos internos y transferirlos a una operación ejecutada especulativamente.

Luego se detectará el conflicto y se descartará la operación especulativa, pero los datos permanecerán en la memoria caché y se pueden extraer utilizando los métodos de restauración de la memoria caché a través de canales de terceros.

El ataque se reduce a abrir transacciones TSX y crear condiciones para su interrupción asincrónica, durante las cuales surgen condiciones de fuga del contenido de los buffers internos especulativamente llenos de datos de las operaciones de lectura de memoria realizadas en el mismo núcleo de la CPU.

La fuga se limita al núcleo físico actual de la CPU (en el que se ejecuta el código del atacante), pero dado que diferentes subprocesos comparten las memorias intermedias de microarquitectura en el modo Hyper-Threading, puede producirse una pérdida de operaciones de memoria realizadas en otros subprocesos de la CPU.

Se han dado a conocer algunos modelos de Intel que en el que ha probado el ataque de ellos se encuentran de la octava, novena y décima generación de procesadores Intel Core y Pentium, Intel Celeron 5000, Intel Xeon E, Intel Xeon W y la segunda generación de procesadores Intel Xeon escalable.

Incluyendo los nuevos procesadores Intel también se basan en la microarquitectura Cascade Lake presentada en abril, que inicialmente no era susceptible a los ataques RIDL y Fallout.

Además de Zombieload 2.0, los investigadores también descubrieron que era posible eludir los métodos de protección previamente propuestos contra los ataques MDS basados ​​en el uso de la instrucción VERW para borrar el contenido de las memorias intermedias de microarquitectura cuando regresan del núcleo al espacio del usuario o cuando transfieren el control al sistema invitado.

Las soluciones para bloquear la vulnerabilidad se incluyen en la base del código del kernel de Linux y se incluyen en las versiones 5.3.11, 4.19.84, 4.14.154, 4.9.201 y 4.4.201. También se han lanzado actualizaciones con kernel y microcódigo para las principales distribuciones (Debian, SUSE/openSUSE, Ubuntu, RHEL, Fedora, FreeBSD). El problema se identificó en abril y la solución fue coordinada por Intel con los desarrolladores de los sistemas operativos.

El método más simple para bloquear Zombieload 2.0 es deshabilitar el soporte de TSX en la CPU. La solución para el kernel de Linux incluye varias opciones de seguridad.

from Linux Adictos https://ift.tt/373rHje
via IFTTT