• Venom: el huesped despierta

    From Enric Lleal Serra@2:343/107.1 to All on Fri May 15 07:33:31 2015
    ­Hola All!


    Otro nuevo vector de ataque...

    -------------------------------------------------------------------
    Hispasec - una-al-día 14/05/2015
    Todos los días una noticia de seguridad www.hispasec.com
    Síguenos en Twitter: http://twitter.com/unaaldia
    Noticia en formato HTML: http://unaaldia.hispasec.com/2015/05/venom-el-huesped-despierta.html
    -------------------------------------------------------------------

    VENOM. El huésped despierta
    ---------------------------

    Hoy vamos a hablar sobre Venom, una vulnerabilidad descubierta por
    Jason Geffner de CrowdStrike y que afecta a todos los sistemas de virtualización basados en QEMU, el popular emulador de fuente abierta.

    Lo primero que nos va a llamar la atención es donde se ha encontrado el
    fallo: La emulación del controlador de discos flexibles (si, discos de
    3.5", por ejemplo). Curioso porque resulta ser un componente emulado que
    rara vez se utiliza, salvo en sistemas virtualizados que usen ambientes heredados con cierta edad, aunque no es necesario que dicho dispositivo
    real esté presente para explotar el fallo, es más ni siquiera
    desactivando la emulación de la unidad virtual evitaría la explotación.

    QEMU soporta la emulación de esta unidad basándose en el chipset de
    Intel 82078, documentado en: http://wiki.qemu.org/images/f/f0/29047403.pdf.
    La lectura del documento nos proporcionará dos cosas: cómo funciona internamente el controlador de disco flexible y la justificación más
    exacta de la frase: "La abstracción es ignorancia selectiva".

    Para efectuar las distintas operaciones con la unidad de discos se
    emiten comandos (desde el sistema virtualizado o huésped) del tipo 'FD_CMD_READ' lectura o 'FD_CMD_WRITE' escritura. Los comandos que
    llegan al controlador del cliente son almacenados en un búfer junto con
    la información de sus parámetros. Este búfer del tipo FIFO posee un
    tamaño estático y está definido como miembro de la estructura FDCtrl. En
    dicha estructura los miembros fifo (uint8_t*) y fifo_size (int32_t)
    definen el puntero a memoria donde comienza el búfer y el tamaño
    asignado (512 hasta donde hemos visto).

    Como todo buen array en C que se precie, el mayor problema viene con el
    índice. El cálculo para obtener el acceso al lugar adecuado dentro del
    array puede llegar a complicarse tanto, que la propia lógica que compone
    el índice puede ofuscarse en el código. Y llegar a comprometer, como es
    el caso, la seguridad del proceso si estos valores son controlables
    desde el exterior (entiéndase, a través de valores procedentes del
    exterior del proceso).

    La vulnerabilidad se asienta sobre este hecho en particular. Tenemos
    unos comandos que va a procesar el controlador emulado, unos parámetros asignables desde fuera (cliente) y un búfer de tamaño fijo con un índice
    cuyo valor es "influenciable" con ciertas llamadas.

    El controlador se encarga de limpiar y resetear el búfer cuando los
    comandos son procesados, dejándolo preparado para la siguiente tanda de comandos. Esto se efectúa correctamente salvo cuando se procesan dos
    comandos: "FD_CMD_READ_ID" y "FD_CMD_DRIVE_SPECIFICATION_COMMAND". En
    los casos de estos comandos el búfer no se deja en un estado apropiado,
    lo que permite que las siguientes operaciones de escritura puedan
    escribir fuera de los límites del tamaño asociado al búfer con el
    completo control del atacante sobre lo que se está escribiendo
    (shellcode por supuesto).

    El parche que solventa el problema está publicado en: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=e907746266721f305d67bc0718795fed
    ee2e824c

    Como podemos observar la variable 'pos' usada para almacenar la posición
    del bloque de datos dentro del búfer ha sido cambiada del tipo 'int' al
    tipo 'uint32_t'.

    El tipo 'int' en la especificación del lenguaje C es del tipo "signed" y
    como mínimo de 16 bits para arriba (habitualmente 32 bits), mientras que
    el tipo que le es asignado está definido como entero SIN SIGNO de 32
    bits. De hecho, la operación donde se establece 'pos':

    pos = fdctrl->data_pos;

    Se hace una conversión implícita de uint32_t a int, con la consiguiente malinterpretación: a partir de un fdctrl->data_pos > (UINT_MAX/2) + 1.
    'pos' es negativo siempre que int = uint32_t = 32 bits.

    Además se ha cambiado la forma en la que se usa e interpreta
    'fdctrl->data_pos' como índice.

    - - fdctrl->fifo[fdctrl->data_pos++] = value;
    + pos = fdctrl->data_pos++;
    + pos %= FD_SECTOR_LEN;
    + fdctrl->fifo[pos] = value;

    Ya no se usa directamente el miembro de la estructura para indexar el
    búfer fifo. Ahora vemos como ese valor se pasa a 'pos' (ya correctamente definido como 'uint32_t') y su valor filtrado al módulo de
    FD_SECTOR_LEN, por lo que no podrá ser indexado más allá de 512,
    coincide con el tamaño del búfer.

    Esta vulnerabilidad, con CVE-2015-3456, permitiría "virtualmente" causar
    el acceso al proceso de virtualización en la máquina real, permitiendo
    de manera efectiva un escape desde el sistema huésped al anfitrión.
    Teniendo en cuenta que los sistemas virtualizados corren bajo cuentas
    con privilegios (Administrador, root...), su explotación puede derivar en problemas serios.

    No es la primera vulnerabilidad que permite salir del sistema virtual al anfitrión. Pero, tal y como reseñan en la web dedicada, esta no precisa
    de una configuración especial para que la virtualización sea vulnerable.

    QEMU es usado por varias soluciones de virtualización, el propio QEMU,
    Xen, Citrix, etc. El problema es independiente de la plataforma huésped,
    la vulnerabilidad afectará a Windows, Linux u OSX de igual manera. Ya
    existe parche disponible para solventar el problema. Por cierto, esto
    afecta a infraestructuras en nube, las cuales se caracterizan por el uso extensivo de virtualización y acceso relativamente abierto a sus
    clientes.

    Por otro lado, VENOM sufre de la nueva corriente de presentación estelar
    de vulnerabilidades: Nombre pegadizo que es un acrónimo forzado, icono y
    web propia. Ah!, aquellos archivos de texto con sus asciiarts...

    Opina sobre esta noticia: http://unaaldia.hispasec.com/2015/05/venom-el-huesped-despierta.html#comments

    Más información:

    VENOM
    http://venom.crowdstrike.com/

    VENOM, don't get bitten https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/

    82078 44 PIN
    CHMOS Single-Chip Floppy Disk Controller http://wiki.qemu.org/images/f/f0/29047403.pdf


    David García
    dgarcia@hispasec.com
    Twitter: @dgn1729


    -
    A reveure!!
    Enric
    __________________________________________________________________
    FidoNet: 2:343/107.1 | beholderbbs.org | fidonet.cat | .es | .ws
    InterNet: kishpa(at)kishpa(dot)com | kishpa.com | GPG#0xDCCB8CFC

    ... La amistad es como la mayonesa: cuesta un huevo y hay que tratar de que no se corte
    --- crashmail + golded + binkd
    * Origin: Black flag & crossed bones : Eye Of The Beholder BBS! (2:343/107.1)