El día de ayer publicamos aquí en el blog la noticia sobre Aya, una biblioteca para crear controladores eBPF en Rust y es que la finalidad de esta es el crear controladores más seguros o del proyecto Prossimo para asegurar la memoria del kernel de Linux con Rust (dos grandes proyecto que darán mucho de que hablar en los siguientes meses).

Y es que en cuestión de poco tiempo se ha reportado diversas vulnerabilidades en las cuales se aprovechan de los fallos en eBPF y que es un tema en el cual los desarrolladores del Kernel no han dejado de trabajar y tal vez Rust sea la solución.

La razón de tocar este tema, es que hace poco se dio conocer la noticia de que han identificado «otra» vulnerabilidad en el kernel de Linux (CVE-2021-33624) para eludir la protección contra vulnerabilidades de clase Spectre, ya que esta permite utilizar el subsistema eBPF para poder determinar el contenido de la memoria como resultado de la creación de condiciones para especulaciones de ejecución de determinadas operaciones.

Se menciona que la vulnerabilidad es causada por fallas en el verificador, que se utiliza para detectar errores y actividad no válida en los programas BPF. El verificador enumera las posibles rutas de ejecución del código, pero omite las opciones de ramificación que no son válidas desde el punto de vista de la semántica de la arquitectura del conjunto de instrucciones.

Al ejecutar un programa BPF, las opciones de ramificación que no fueron tomadas en cuenta por el verificador pueden ser predichas incorrectamente por el procesador y ejecutadas en un modo especulativo.

En los sistemas afectados, un programa BPF sin privilegios puede aprovechar esta vulnerabilidad para filtrar el contenido de la memoria del kernel arbitraria (y por lo tanto, de toda la memoria física) a través de un canal lateral.

Por ejemplo, al analizar la operación de «carga», el verificador asume que la instrucción usa un registro con una dirección cuyo valor está siempre dentro de los límites especificados, pero un atacante puede crear condiciones bajo las cuales el procesador intentará realizar especulativamente una operación con una dirección que no cumpla con las condiciones de verificación.

El ataque Spectre requiere la presencia de una secuencia específica de comandos en el código privilegiado, lo que lleva a la ejecución especulativa de instrucciones. Al manipular los programas BPF que se pasan para su ejecución, es posible generar tales instrucciones en eBPF y filtrar el contenido de la memoria del núcleo y áreas arbitrarias de la memoria física a través de canales laterales.

Además, se puede marcar una nota sobre el impacto en el rendimiento de los activos para proteger contra la clase de vulnerabilidades Spectre.

Esta nota resume los resultados de optimización del depurador rr (Record and Replay), una vez creado por Mozilla para depurar errores difíciles de repetir en Firefox. El almacenamiento en caché de las llamadas del sistema utilizadas para verificar la existencia de directorios redujo la operación de «fuentes rr» para el proyecto de prueba de 3 minutos 19 segundos a 36 segundos.

El autor de la optimización decidió comprobar cuánto cambiará el rendimiento después de desactivar la protección de Spectre. Después de arrancar el sistema con el parámetro «mitigations=off», el tiempo de ejecución de «rr sources» sin optimización fue de 2 minutos 5 segundos (1.6 veces más rápido) y con optimización 33 segundos (9% más rápido).

Curiosamente, deshabilitar la protección de Spectre no solo redujo el tiempo de ejecución del código a nivel del kernel en 1.4 veces (de 2 min 9s a 1 min 32s), sino que también redujo a la mitad el tiempo de ejecución en el espacio de usuario (de 1 min 9s a 33s), presumiblemente debido a una disminución en La caché de CPU de eficiencia y el TLB se restablecen cuando la protección Spectre está habilitada.

El problema ha aparecido desde el lanzamiento del kernel 4.15 y se ha solucionado en forma de parches, los cuales en estos momentos todavía no llegan a todas las distribuciones, por lo que se recomienda a los usuarios que en estos dias estén realizando las actualizaciones pertinentes en cuanto reciban las notificaciones.

Si quieres conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/35T5LYK
via IFTTT

Josh Aas, director ejecutivo de la Internet Security Research Group (ISRG, organización matriz del proyecto Let’s Encrypt) dio a conocer la semana pasada mediante una publicación sus intenciones de apoyar a Miguel Ojeda (ingeniero en software y desarrollador del kernel de Linux), con el objetivo coordinar los esfuerzos para trasladar la infraestructura de software crítico a un código seguro para la memoria.

Y es que la ISRG ha proporcionado al destacado desarrollador Miguel Ojeda un contrato de un año para trabajar en Rust en Linux y otros esfuerzos de seguridad en tiempo completo.

Según Miguel Ojeda, los beneficios de introducir el lenguaje Rust en el kernel de Linux superan los costos. Para el desarrollador, al usar Rust en el kernel de Linux, el nuevo código escrito en Rust tiene un riesgo reducido de errores de seguridad de la memoria, gracias a las propiedades del lenguaje Rust. El lenguaje Rust sería popular por su seguridad.

Los esfuerzos para hacer de Rust un lenguaje viable para el desarrollo del kernel de Linux comenzaron en la conferencia Linux Plumbers 2020, con la idea del propio Linus Torvalds.

Torvalds solicitó específicamente la disponibilidad del compilador de Rust en el entorno de compilación del kernel predeterminado para respaldar dichos esfuerzos, no para reemplazar todo el código fuente del kernel de Linux con equivalentes desarrollados por Rust, sino para permitir que el nuevo desarrollo funcione correctamente.

Usar Rust para nuevo código en el kernel puede significar nuevos controladores de hardware o incluso reemplazar GNU Coreutils, reduce potencialmente la cantidad de errores ocultos en el kernel. Rust simplemente no permitirá que un desarrollador pierda memoria o cree la posibilidad de desbordamientos de búfer, las principales fuentes de rendimiento y problemas de seguridad en el código complejo de lenguaje C.

El nuevo contrato de Internet Security Research Group le otorga a Ojeda un salario de tiempo completo para continuar con el trabajo de seguridad de la memoria que ya estaba haciendo a tiempo parcial. El director ejecutivo de ISRG, Josh Aas, señala que el grupo ha trabajado en estrecha colaboración con el ingeniero de Google, Dan Lorenc, y que el apoyo financiero de Google es esencial para patrocinar el trabajo continuo de Ojeda.

«Los grandes esfuerzos para eliminar clases enteras de problemas de seguridad son las mejores inversiones a gran escala», dijo Lorenc, y agregó que Google está «encantado de ayudar a ISRG a respaldar el trabajo de Miguel Ojeda para mejorar la seguridad de la memoria del kernel para todos».

“El proyecto de seguridad de memoria Prossimo de ISRG tiene como objetivo coordinar los esfuerzos para mover la infraestructura de software crítico de Internet para proteger el código en la memoria. Cuando pensamos en el código más crítico para Internet hoy en día, el kernel de Linux encabeza la lista. Llevar la seguridad de la memoria al kernel de Linux es un gran trabajo, pero el proyecto Rust para Linux está dando grandes pasos. Nos complace anunciar que comenzamos a respaldar oficialmente este trabajo en abril de 2021 al proporcionar a Miguel Ojeda un contrato para trabajar en Rust para Linux y otros esfuerzos de seguridad a tiempo completo durante un año. Esto fue posible gracias al apoyo financiero de Google. Antes de trabajar con ISRG, Miguel estaba realizando este trabajo como un proyecto paralelo. Estamos felices de hacer nuestra parte para respaldar la infraestructura digital permitiéndole trabajar allí a tiempo completo.

“Trabajamos en estrecha colaboración con Dan Lorenc, ingeniero de software de Google para hacer posible esta colaboración.

El trabajo de Ojeda es el primer proyecto patrocinado bajo la bandera Prossimo del ISRG, pero no es el primer paso que la organización ha dado hacia una mayor seguridad de la memoria. Las iniciativas anteriores incluyen un módulo TLS seguro en memoria para el servidor web Apache, una versión segura en memoria de la utilidad de transferencia de datos curl and rustls, una alternativa segura en memoria a la omnipresente biblioteca de cifrado de red OpenSSL.

Como explica Josh Aas,

“Aunque este es el primer esfuerzo de seguridad de la memoria que anunciamos bajo nuestro nuevo nombre de proyecto Prossimo, nuestro trabajo de seguridad de la memoria comenzó en 2020.y el servidor HTTP Apache , y para agregar mejoras a la biblioteca TLS de Rustls ”.

Fuente: https://www.memorysafety.org

from Linux Adictos https://ift.tt/3wZro5F
via IFTTT