pjlantz/optee-qemuEntorno con kernel vulnerable para la explotación del controlador TEE (CVE-2021-44733)
Recientemente se descubrió una vulnerabilidad de use-after-free en el subsistema TEE del kernel de Linux, hasta la versión 5.15.11 inclusive, y se le asignó CVE-2021-44733 [1].
A primera vista no parecía explotable por varias razones; sin embargo, tras un análisis más profundo de la ruta de código vulnerable y mediante la implementación de un exploit de prueba de concepto rudimentario, fue posible sobrescribir un puntero a función en el kernel. En esta publicación no se presenta una carga útil de escalada de privilegios, pero todo el entorno para ejecutar OP-TEE y el exploit está disponible para realizar más pruebas; consulte 'Configuración del entorno'.
Un TEE (Entorno de Ejecución Confiable) es un sistema operativo confiable que se ejecuta en algún entorno seguro, por ejemplo, TrustZone en CPUs ARM. Un controlador TEE maneja los detalles necesarios para comunicarse con el TEE. Algunas de las funciones más importantes del controlador son proporcionar una API genérica hacia el TEE basada en la especificación GlobalPlatform TEE Client API [3], y también gestionar la memoria compartida entre Linux y el TEE. Este subsistema se puede habilitar configurando CONFIG_OPTEE en las configuraciones del kernel para arquitecturas ARM.
El mundo seguro contiene el sistema operativo confiable denominado OP-TEE OS [4]. Sobre este sistema operativo es posible ejecutar las llamadas Aplicaciones Confiables (TAs, por sus siglas en inglés) que pueden realizar algunas operaciones en el entorno aislado; consulte la Figura 1.
Figura 1: Descripción general de TEE - de la presentación de Linaro [5]
El mundo normal (espacio de usuario/kernel de Linux) puede interactuar con estas aplicaciones usando aplicaciones cliente (CAs, por sus siglas en inglés) y la API expuesta por el subsistema TEE. Una CA puede abrir una sesión hacia una TA específica e invocar las funciones que la TA implementa. El paso de argumentos entre la TA y la CA se realiza mediante memoria compartida. A continuación se describe la interacción entre una CA y una TA usando todas las syscalls relevantes.
Una CA abre /dev/tee[0-9] para comunicarse con el controlador. Tenga en cuenta que, en la forma convencional de usar estas APIs, esto se hace implícitamente mediante libteec.
La CA puede registrar la memoria compartida usando el IOCTL TEE_IOC_SHM_ALLOC. Esto asigna memoria compartida y devuelve un descriptor de archivo que el espacio de usuario puede usar como parte de mmap.
El siguiente paso es establecer una sesión usando el IOCTL TEE_IOC_OPEN_SESSION y especificando el uuid de una TA específica. Este uuid está codificado de forma fija durante la compilación de la TA.
Para invocar cualquier función específica en la TA, la CA la invoca especificando el identificador de una función junto con los argumentos de entrada; esto se hace mediante TEE_IOC_INVOKE.
Cuando la CA termina con todas las solicitudes, la sesión se puede cerrar usando TEE_IOC_CLOSE_SESSION.
Figura 2: Sesión entre CA y TA - de la presentación de Linaro [5]
Gran parte de la comunicación entre los clientes y el TEE es opaca para el controlador. La tarea principal del controlador es gestionar el contexto, recibir las solicitudes de los clientes, reenviarlas al TEE y enviar de vuelta los resultados [2].
