Google Native Client: Detalles de la implementación

Google se ha embarcado en un proyecto que permita ejecutar código nativo en un navegador web de manera segura. Esta idea no es nueva, Microsoft fue una de las primeras compañías que intentaron este camino a través de la tecnologia ActiveX. Sin embargo el mecanismo de seguridad basado en firmas y zonas de ejecución, no ha sido suficiente para evitar que haya sido uno de los vectores de ataques más usados contra sistemas que ejecutan Windows.

Los objetivos de Google es permitir un entorno de ejecución de módulos binarios x86 - aunque podrían portarlo a otras arquitecturas de microprocesador - que permitan aprovechar la potencia disponible en los microprocesadores actuales, que sea portable entre diferentes sistemas operativos y que sea seguro. Para poder interactuar con el resto del navegador existe un puente que comunica javascript con los módulos binarios.

Google crea un entorno aislado ("sandbox") donde se va a ejecutar los diferentes módulos, cada uno de los cuales está en un espacio de direcciones separados y que se comunican entre ellos a través de un mecanismo de procedimientos de llamada remoto (RPC). Se aísla el código que se ejecuta en el sandbox del sistema operativo, ofreciendo sólo una serie de servicios autorizados a llamar desde los ejecutables generados.

De la documentación que llevo leída, en especial de Native Client: A Sandbox for Portable, Untrusted x86 Native Code, la idea que me hago de la arquitectura que quiere implementar Google es la siguiente:

Arquitectura

Destacar en este caso el mecanismo de comunicación, denominado IMC e implementado en éste módulo de intercomunicación.

Para tener un entorno seguro se realiza un análisis estático del código que se ha generado: se busca detectar aquellas instrucciones peligrosas para el sistema y se fuerza a que el módulo ejecutable tenga una determinada estructura para evitar código automodificable e instrucciones superpuestas. Además utiliza los mecanismos de segmentación presente en la arquitectura x86 para evitar referencias a memoria fuera de los límites del proceso, y aislar el módulo binario de las librerias que el propio sistema mapea en memoria. La implementación de estos mecanismos de protección es lo que Google llama inner sandbox.

Native Client impone las siguientes restricciones a un módulo binario para que pueda ejecutarse en el entorno:

1. El módulo binario una vez cargado en memoria es sólo de lectura.
2. El módulo binario se linka empezando en la dirección de memoria cero y a partir de los 64kbytes empieza el código máquina generado por las herramientas.
3. Las llamadas de control indirectas utilizan una secuencia especial de instrucciones.
4. El binario ocupa páginas de memoria completa, rellenándose hasta el límite de las páginas, apareciendo al menos una instrucciones hlt.
5. No puede contener instrucciones que sobrepasen 32 bytes de memoria.
6. Todas las direcciones de las instrucciones válidas son alcanzables a través de un desemsablado que empieza en la dirección de carga.
7. Todas los saltos directos tienen como destino instrucciones válidas e identificadas durante el análisis estático de código.

El análisis estático del código generado se implementa en la libreria native client verifier (ncv). Es el encargado de asegurarse que no existen instrucciones de carga o escritura de datos fuera de la memoria asignada, que el binario puede desemsablarse de manera exacta, no debe de existir direcciones inseguras y debe de existir integridad en el flujo del binario. La seguridad de esta parte del código es crítica, (y algún bug han descubierto ya)

El módulo tiene una particular disposición en memoria que permite atrapar aquellas referencias a punteros nulos (protege la primera página de la memoria asignada contra lectura y escritura). Los siguientes 60 Kb se utilizan para el código de los servicios de ejecución y el resto del espacio de direcciones se dedica al módulo.Todos los módulos binarios tienen como base la dirección cero y el código comienza a insertarse a partir de los 64 kbytes:

Mapa de memoria

Es interesante ver en acción uno de los mecanismos que tienen los procesadores x86 desde que existe el modo protegido: El uso de la segmentación para limitar el rango de memoria que puede accederse.Acostumbrados a modelos de memoria planos y de 4 GB, Google implementa con ayuda de la segmentación el modelo de memoria (ver nacl_ldt.c para el caso de Linux). Este mecanismo, no se puede usar en procesadores ejecutando código de 64 bits. La estructura que tendría una vez cargado el módulo en memoria sería la siguiente:

Las llamadas al sistema que se realizan desde el módulo binario se compara contra una lista blanca de llamadas permitidas. Esta validación formaría otra capa de protección que Google llam outer sandbox, donde se implementaría los servicios de ejecución. Están en service runtime.

Aparte el entorno de ejecución define un API que da acceso a los servicios que puede necesitar el módulo binario: gestión de memoria, gestión de hilos o primitivas de sincronización.

Referencias

1. Google Native Client: Aplicaciones x86 en el navegador
2. Native Client
3. Native Client: A Sandbox for Portable, Untrusted x86 Native Code
4. Safer than ActiveX: a look at Google's Native Client plugin
5. Native Client:README
6. Native Client: A Technology for Running Native Code on the Web

Technorati Tags: google,native cliente,sandbox