Desde Linux David Naranjo  

Fueron descubiertas cerca de 25 vulnerabilidades en Zephyr, el sistema RTOS

Zephyr

Investigadores de la empresa NCC Group publicaron hace poco los resultados de las auditorías del proyecto Zephyr, el cual es un sistema operativo en tiempo real (RTOS), destinado a equipar los dispositivos de acuerdo con el concepto de «Internet de las cosas» (IoT). Zephyr se está desarrollando con la participación de Intel.

Zephyr proporciona para todos los procesos un solo espacio de dirección virtual compartido global (SASOS, Sistema operativo de espacio de dirección único). El código específico de la aplicación se combina con un núcleo adaptado para una aplicación específica y forma un archivo ejecutable monolítico para descargar y ejecutar en ciertos equipos.

Todos los recursos del sistema se determinan en la etapa de compilación, lo que reduce el tamaño del código y aumenta la productividad. Solo las características del núcleo que se requieren para ejecutar la aplicación se pueden incluir en la imagen del sistema.

Es de destacar que entre las principales ventajas de Zephyr mencionó el desarrollo con un ojo puesto en la seguridad. Se argumenta que todas las etapas de desarrollo pasan por las etapas obligatorias de confirmar la seguridad del código: pruebas difusas, análisis estático, pruebas de penetración, revisión de código, análisis de implementación de puerta trasera y modelado de amenazas.

Sobre las vulnerabilidades

La auditoría reveló 25 vulnerabilidades en Zephyr y 1 vulnerabilidad en MCUboot. En total, se identificaron 6 vulnerabilidades en la pila de red, 4 en el núcleo, 2 en el shell de comandos, 5 en los controladores de llamadas del sistema, 5 en el subsistema USB y 3 en el mecanismo de actualización del firmware.

A dos problemas se les asignó un nivel crítico de peligro, dos: alto, 9 moderado, 9 – bajo y 4 – a tener en cuenta. Los problemas críticos afectan la pila IPv4 y el analizador MQTT, mientras que los peligrosos incluyen almacenamiento masivo USB y controladores USB DFU.

En el momento de la divulgación de información, las correcciones se prepararon solo para las 15 vulnerabilidades más peligrosas, todavía hay problemas que se han resuelto, lo que lleva a una denegación de servicio o relacionada con fallas en los mecanismos para la protección adicional del núcleo.

Se ha identificado una vulnerabilidad explotada remotamente en la pila IPv4 de la plataforma, lo que conduce a la corrupción de la memoria cuando se procesan paquetes ICMP modificados de cierta manera.

Se encontró otro problema grave en el analizador de protocolo MQTT, que es causado por la falta de verificación adecuada de la longitud de los campos en el encabezado y puede conducir a la ejecución remota de código. Se encuentran problemas de denegación de servicio menos peligrosos en la pila de IPv6 y la implementación del protocolo CoAP.

Otros problemas pueden ser explotados localmente para causar denegación de servicio o ejecución de código a nivel de kernel. La mayoría de estas vulnerabilidades están relacionadas con la falta de comprobaciones adecuadas de los argumentos de las llamadas al sistema, y ​​pueden conducir a la escritura y lectura de áreas arbitrarias de la memoria del núcleo.

Los problemas también cubren el código de procesamiento de llamadas del sistema en sí mismo: acceder a un número de llamada negativo del sistema conduce a un desbordamiento de enteros. El núcleo también identificó problemas en la implementación de la protección ASLR (aleatorización del espacio de direcciones) y el mecanismo para instalar etiquetas canarias en la pila, lo que hace que estos mecanismos sean ineficaces.

Muchos problemas afectan la pila USB y los controladores individuales. Por ejemplo, un problema en el almacenamiento masivo USB le permite causar un desbordamiento del búfer y ejecutar código a nivel del núcleo cuando conecta el dispositivo a un host atacante USB controlado.

La vulnerabilidad en USB DFU, un controlador para descargar nuevo firmware a través de USB, le permite cargar una imagen de firmware modificada en el Flash interno de un microcontrolador sin usar cifrado y omitiendo el modo de arranque seguro con verificación de firma digital de componentes. Además, se estudió el código del cargador de arranque abierto MCUboot , en el que se encontró una vulnerabilidad no peligrosa que podría conducir a un desbordamiento del búfer cuando se usa el Protocolo de administración simple (SMP) a través de UART.

Leave A Comment

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.