guestfs-security: en línea en la nube

PROGRAMA:

NOMBRE

guestfs-security - seguridad de libguestfs

DESCRIPCIÓN

Esta página de manual analiza las implicaciones de seguridad del uso de libguestfs, particularmente con
invitados no confiables o maliciosos o imágenes de disco.

SEGURIDAD OF MONTAJE SISTEMAS DE ARCHIVOS
Nunca debe montar un sistema de archivos invitado que no sea de confianza directamente en el kernel de su host (p. Ej.
usando loopback o kpartx).

Cuando monta un sistema de archivos, los errores en el sistema de archivos del kernel (VFS) se pueden escalar a
Explotaciones de los atacantes que crean un sistema de archivos malicioso. Estos exploits son muy graves para
dos razones. En primer lugar, hay muchos controladores de sistema de archivos en el kernel, y muchos de
se utilizan con poca frecuencia y no se ha prestado mucha atención al código por parte de los desarrolladores.
El espacio de usuario de Linux ayuda a los piratas potenciales al detectar el tipo de sistema de archivos y
elegir automáticamente el controlador VFS correcto, incluso si ese tipo de sistema de archivos es inesperado.
En segundo lugar, un exploit a nivel de kernel es como un exploit de raíz local (peor en algunos aspectos),
Acceso inmediato y total al sistema hasta el nivel de hardware.

Estos exploits pueden estar presentes en el kernel durante mucho tiempo.
(https://lwn.net/Articles/538898/).

Libguestfs proporciona un enfoque en capas para protegerlo de las vulnerabilidades:

sistema de archivos no confiable
--------------------------------------
kernel del dispositivo
--------------------------------------
proceso qemu ejecutándose como no root
--------------------------------------
sVirt [si usa libvirt + SELinux]
--------------------------------------
kernel de host

Ejecutamos un kernel de Linux dentro de una máquina virtual qemu, generalmente ejecutándose como un usuario no root.
El atacante necesitaría escribir un sistema de archivos que primero explotara el kernel y luego
explotó la virtualización qemu (por ejemplo, un controlador qemu defectuoso) o el libguestfs
protocolo, y finalmente para ser tan serio como el exploit del kernel del host, necesitaría
escalar sus privilegios a root. Además, si usa el back-end libvirt y
SELinux, sVirt se utiliza para limitar el proceso qemu. Esta escalada de varios pasos, realizada
por un dato estático, se cree que es extremadamente difícil de hacer, aunque nunca decimos
'nunca' sobre cuestiones de seguridad.

Las personas que llaman también pueden reducir la superficie de ataque forzando el tipo de sistema de archivos al montar
(use "guestfs_mount_vfs").

GENERAL SEGURIDAD CONSIDERACIONES
Tenga cuidado con los archivos o datos que descargue de un invitado (por "descargar" nos referimos a
no solo el comando "guestfs_download", sino cualquier comando que lea archivos, nombres de archivos,
directorios o cualquier otra cosa de una imagen de disco). Un atacante podría manipular los datos para
engañe a su programa para que haga algo incorrecto. Considere casos como:

· Los datos (archivo, etc.) no están presentes

· Estar presente pero vacío

· Ser mucho más grande de lo normal

· Que contiene datos arbitrarios de 8 bits

· Estar en una codificación de caracteres inesperada

· Que contiene homoglyphs.

PROTOCOLO SEGURIDAD
El protocolo está diseñado para ser seguro, ya que se basa en RFC 4506 (XDR) con un superior definido
tamaño del mensaje. Sin embargo, un programa que usa libguestfs también debe tener cuidado, por ejemplo
puede escribir un programa que descargue un binario de una imagen de disco y lo ejecute localmente,
y ninguna cantidad de seguridad del protocolo le salvará de las consecuencias.

INSPECCIÓN SEGURIDAD
Partes de la API de inspección (consulte "INSPECCIÓN") devuelven cadenas que no son de confianza directamente desde el
guest, y estos podrían contener cualquier dato de 8 bits. Las personas que llaman deben tener cuidado de escapar de estos
antes de imprimirlos en un archivo estructurado (por ejemplo, utilice HTML escaping si crea un
Página web).

La configuración del invitado puede ser alterada de formas inusuales por el administrador de la red virtual.
máquina, y puede que no refleje la realidad (especialmente para los que no son de confianza o son activamente maliciosos
huéspedes). Por ejemplo, analizamos el nombre de host de archivos de configuración como
/ etc / sysconfig / network que encontramos en el invitado, pero el administrador invitado puede
manipular estos archivos para proporcionar el nombre de host incorrecto.

La API de inspección analiza la configuración del invitado mediante dos bibliotecas externas: Augeas (Linux
configuración) y hivex (Registro de Windows). Ambos están diseñados para ser robustos en la cara.
de datos maliciosos, aunque los ataques de denegación de servicio todavía son posibles, por ejemplo, con
archivos de configuración de gran tamaño.

RUNNING SIN CONFIANZA HUÉSPED COMANDOS
Tenga mucho cuidado al ejecutar comandos del invitado. Al ejecutar un comando en el
invitado, le está dando tiempo de CPU a un binario que no controla, bajo el mismo usuario
cuenta como la biblioteca, aunque envuelta en virtualización qemu. Más información y
las alternativas se pueden encontrar en la sección "EJECUTAR COMANDOS".

CVE-2010-3851
https://bugzilla.redhat.com/642934

Este error de seguridad se refiere a la detección automática de formato de disco que qemu hace en el disco.
imágenes.

Una imagen de disco sin procesar son solo los bytes sin procesar, no hay encabezado. Otras imágenes de disco como qcow2
contener un encabezado especial. Qemu se ocupa de esto buscando uno de los encabezados conocidos,
y si no se encuentra ninguno, entonces asumiendo que la imagen del disco debe estar en bruto.

Esto permite que un invitado al que se le haya dado una imagen de disco sin procesar escriba algún otro encabezado. A
siguiente arranque (o cuando libguestfs acceda a la imagen del disco) qemu haría la autodetección
y creo que el formato de la imagen del disco era, digamos, qcow2 basado en el encabezado escrito por el invitado.

Esto en sí mismo no sería un problema, pero qcow2 ofrece muchas características, una de las cuales es
permitir que una imagen de disco se refiera a otra imagen (denominada "disco de respaldo"). Hace esto por
colocando la ruta al disco de respaldo en el encabezado qcow2. Esta ruta no está validada
y podría apuntar a cualquier archivo host (por ejemplo, "/ Etc / passwd"). A continuación, se expone el disco de respaldo
a través de "agujeros" en la imagen del disco qcow2, que por supuesto está completamente bajo control
del atacante.

En libguestfs esto es bastante difícil de explotar excepto en dos circunstancias:

1. Ha habilitado la red o ha abierto el disco en modo de escritura.

2. También está ejecutando un código que no es de confianza del invitado (consulte "EJECUCIÓN DE COMANDOS").

La forma de evitar esto es especificar el formato de disco esperado al agregar discos (el
opción opcional "formato" a "guestfs_add_drive_opts"). Siempre debe hacer esto si el
El disco es de formato sin formato, y también es una buena idea para otros casos. (Consulte también "DISK IMAGE
FORMATOS ").

Para los discos agregados desde libvirt mediante llamadas como "guestfs_add_domain", se obtiene el formato
de libvirt y pasó.

Para las herramientas libguestfs, use el --formato parámetro de línea de comando según corresponda.

CVE-2011-4127
https://bugzilla.redhat.com/752375

Este es un error en el kernel que permitía a los invitados sobrescribir partes de las unidades del host.
a los que normalmente no deberían tener acceso.

Es suficiente actualizar libguestfs a cualquier versión ≥ 1.16 que contenga un cambio que
mitiga el problema.

CVE-2012-2690
https://bugzilla.redhat.com/831117

Las versiones anteriores de virt-edit y el comando "edit" de guestfish crearon un nuevo archivo
que contiene los cambios pero no configuró los permisos, etc. del nuevo archivo para que coincida con el
el viejo. El resultado de esto fue que si editaba un archivo sensible a la seguridad como
/ etc / shadow entonces quedaría legible para todo el mundo después de la edición.

Es suficiente actualizar libguestfs a cualquier versión ≥ 1.16.

CVE-2013-2124
https://bugzilla.redhat.com/968306

Este error de seguridad fue una falla en la inspección donde un huésped que no era de confianza usaba un
archivo creado en el sistema operativo invitado podría causar un doble libre en la biblioteca C (denegación de
Servicio).

Es suficiente actualizar libguestfs a una versión que no sea vulnerable: libguestfs ≥
1.20.8, ≥ 1.22.2 o ≥ 1.23.2.

CVE-2013-4419
https://bugzilla.redhat.com/1016960

Cuando se utiliza el pez invitado(1) --remoto o pez invitado --escucha opciones, guestfish crearía
un enchufe en una ubicación conocida (/tmp/.guestfish-$UID/socket-$PID).

La ubicación debe ser conocida para que ambos extremos se comuniquen. Sin embargo no
Se comprobó que el directorio que lo contiene (/tmp/.guestfish-$UID) es propiedad del
usuario. Por lo tanto, otro usuario podría crear este directorio y potencialmente secuestrar los sockets de propiedad
por el cliente o servidor guestfish de otro usuario.

Es suficiente actualizar libguestfs a una versión que no sea vulnerable: libguestfs ≥
1.20.12, ≥ 1.22.7 o ≥ 1.24.

Negación of Service when inspeccionar disco imágenes con corrupto btrfs volúmenes
Fue posible bloquear libguestfs (y programas que usan libguestfs como biblioteca) por
presentando una imagen de disco que contiene un volumen btrfs corrupto.

Esto fue causado por una desreferencia del puntero NULL que provocó una denegación de servicio, y no es
se cree que puede seguir explotándose.

Consulte la confirmación d70ceb4cbea165c960710576efac5a5716055486 para obtener la solución. Esta corrección está incluida en
ramas estables libguestfs ≥ 1.26.0, ≥ 1.24.6 y ≥ 1.22.8, y también en RHEL ≥ 7.0.
Las versiones anteriores de libguestfs no son vulnerables.

CVE-2014-0191
Libguestfs utilizó anteriormente API libxml2 inseguras para analizar el XML de libvirt. Estas API
predeterminado para permitir que se realicen conexiones de red cuando ciertos documentos XML estaban
presentado. Usando un documento XML con formato incorrecto, también fue posible agotar toda la CPU, la memoria
o descriptores de archivo en la máquina.

Dado que el XML de libvirt proviene de una fuente confiable (el demonio libvirt), no se piensa
que esto podría haber sido explotable.

Esto se corrigió en libguestfs ≥ 1.27.9 y la solución se exportó a versiones estables ≥
1.26.2, ≥ 1.24.9, ≥ 1.22.10 y ≥ 1.20.13.

Neurosis de guerra (intento CVE-2014-6271)
Este error de bash afecta indirectamente a libguestfs. Para más información, ver:
https://www.redhat.com/archives/libguestfs/2014-September/msg00252.html

CVE-2014-8484
CVE-2014-8485
Estos dos errores en binutils afectan al GNU instrumentos de cuerda(1) programa, y ​​por lo tanto el
API "guestfs_strings" y "guestfs_strings_e" en libguestfs. Ejecutando cuerdas en un
archivo no confiable podría causar la ejecución de código arbitrario (limitado a libguestfs
aparato).

En libguestfs ≥ 1.29.5 y ≥ 1.28.3, libguestfs usa las "cadenas" -a opción para evitar BFD
analizando el archivo.

CVE-2015-5745
https://bugzilla.redhat.com/show_bug.cgi?id=1251157

Esta no es una vulnerabilidad en libguestfs, sino porque siempre damos un puerto virtio-serial
a cada huésped (ya que así es como ocurre la comunicación huésped-anfitrión), una escalada del
dispositivo al host qemu proceso es posible. Esto podría afectarle si:

· Su programa libguestfs ejecuta programas que no son de confianza desde el invitado (usando "guestfs_sh"
etc), o

· Se encontró otro exploit en (por ejemplo) el código del sistema de archivos del kernel que permitía
sistema de archivos con formato incorrecto para hacerse cargo del dispositivo.

Si usa sVirt para confinar qemu, eso frustraría algunos ataques.

Permisos of .ssh y .ssh / claves_autorizadas
https://bugzilla.redhat.com/1260778

Las herramientas virt-personalizar(1) virt-sysprep(1) y constructor de virtudes(1) tener un --ssh-inyectar
opción para inyectar una clave SSH en las imágenes de disco de la máquina virtual. Pueden crear una
~ usuario / .ssh directorio y ~ usuario / .ssh / claves_autorizadas archivo en el invitado para hacer esto.

En libguestfs <1.31.5 y libguestfs <1.30.2, el nuevo directorio y archivo obtendría modo
0755 y modo 0644 respectivamente. Sin embargo, estos permisos (especialmente para ~ usuario / .ssh)
son más amplios que los permisos que utiliza OpenSSH. En libguestfs actual, el directorio
y el archivo se crean con el modo 0700 y el modo 0600.

Utilice guestfs-security en línea utilizando los servicios de onworks.net