Hace poco se dio a conocer información de la vulnerabilidad (CVE-2022-29582) en la implementación de la interfaz de E/S asíncrona io_uring, incluida en el kernel de Linux desde la versión 5.1, que permite que un usuario sin privilegios se convierta en root en el sistema, incluso cuando ejecuta un exploit de un contenedor.

Cabe mencionar que dicha vulnerabilidad se informó hace poco más de 3 meses (aproximadamente a principios de mayo de este año), pero la información completa y divulgación se dio a conocer recientemente.

Sobre la vulnerabilidad se menciona que esta se produce al acceder a un bloque de memoria ya liberado, se manifiesta en los kernels de Linux a partir de la rama 5.10.

Sobre la vulnerabilidad CVE-2022-29582

Esta vulnerabilidad permite poder accede a la memoria liberada como resultado de una condición de carrera cuando se manejan tiempos de espera en la función io_flush_timeouts(), que elimina la entrada de tiempo de espera de la lista y la cancela, sin verificar la creación y eliminación del tiempo de espera en ese punto.

Una descripción general y actualizada de io_uring ya ha sido proporcionada por otros. Lo explican mil veces mejor que nosotros, por lo que solo cubriremos el subsistema de manera más amplia (consulte este artículo de Grapl Security y este artículo de Flatt Security para obtener una excelente introducción).

Lo que es más importante, el campo opcode determina qué tipo de operación realizar. Para que cada que»opcode» lo requiera, el campo fd especifica el descriptor de archivo en el que realizar la E/S solicitada. Casi todas las llamadas al sistema de E/S normales ( read, sendto, etc.) tienen un código de operación asíncrono equivalente. Cada campo puede asumir diferentes roles dependiendo de la operación.

Una vez recuperado del SQ, un SQE se convierte en una representación interna descrita por struct io_kiocb( kernel input/output call back). Estos objetos se conocen comúnmente como solicitudes.

struct io_kiocb utiliza como un equivalente a «ready-for-launch» del SQE en el que se basa, con lo que cualquier descriptor de archivo se resuelve en struct file*s, se adjuntan las credenciales del usuario, se adjunta la personalidad (en qué núcleos se ejecutará), etc.

Una vez finalizada la operación solicitada, se escribe en la cola de finalización (CQ) una entrada que corresponde al SQE. Dicha entrada se denomina entrada de cola de finalización (CQE) y contiene campos como un código de error y un valor de resultado. La aplicación del espacio de usuario puede sondear el CQ en busca de nuevas entradas para determinar si los SQE enviados han terminado de procesarse y cuál fue su resultado.

Se mencionan que existen algunos escenarios sobre los cuales es fácil reemplazar un objeto sobre la marcha. Pero existen dos limitantes :

• LT’ tiene que ser asignado e inicializado en una ventana de carrera. Es decir, después de que el LT se libera pero antes de llegar a un punto en el LT que ya no se accede.
• LT’ sólo puede ser otro objeto objeto struct io_kiocb. Debido al aislamiento del montón, donde los objetos del montón se separan según su tipo, es demasiado difícil reasignarlos como un tipo diferente de objeto dentro de la ventana de carrera.

Los investigadores han preparado un exploit funcional que no requiere la inclusión de espacios de nombres de identificadores de usuario (espacios de nombres de usuario) para su funcionamiento y puede proporcionar acceso de raíz al sistema principal cuando un usuario sin privilegios inicia el exploit en un contenedor aislado.

Nuestro exploit apunta a la versión del kernel 5.10.90, la versión que Google estaba ejecutando de forma remota en ese momento. Tuvimos que ajustar nuestro exploit a las especificaciones particulares del servidor (4 núcleos Skylake Xeon @ 2.80Ghz, 16GiB RAM), pero con algunos ajustes, cualquier máquina que ejecute un kernel vulnerable debería ser explotable

El exploit también funciona en el entorno nsjail aislado en la distribución Google COS (Container Optimized OS) basada en Chromium OS y utilizada en Google Cloud Platform en máquinas virtuales Compute Engine. El exploit está diseñado para funcionar con ramas del kernel de 5.10 a 5.12. Por ultimo vale mencionar que el problema solucionó en abril en las actualizaciones 5.10.111, 5.15.34 y 5.17.3.

Finalmente si estás interesado en poder conocer más al respecto sobre la vulnerabilidad, puedes consultar la publicación realizada en el siguiente enlace.

from Linux Adictos https://ift.tt/Ji69sRY
via IFTTT

Se dio a conocer el lanzamiento de la nueva versión de la distribucion para el respaldo, recuperación del sistema después de fallas y diagnóstico de varios problemas de hardware«Rescuezilla 2.4».

Rescuezilla está diseñada a partir de la base del paquete de Ubuntu y continúa el desarrollo del proyecto «Redo Backup & Rescue», cuyo desarrollo se interrumpió en 2012.

Rescuezilla admite la copia de seguridad y la recuperación de archivos eliminados accidentalmente en particiones de Linux, macOS y Windows. Busca y monta automáticamente particiones de red que se pueden usar para alojar copias de seguridad. La GUI se basa en el shell LXDE.

De las características que se destacan, podremos encontrar:

• Entorno gráfico simple que cualquiera puede usar
• Crea imágenes de respaldo que son totalmente interoperables con el estándar de la industria Clonezilla
• Admite imágenes creadas por todas las interfaces de imágenes de código abierto conocidas, incluido Clonezilla (consulte la sección «compatibilidad» de la página de descarga)
• También admite imágenes de máquinas virtuales: VirtualBox (VDI), VMWare (VMDK), Hyper-V (VHDx), Qemu (QCOW2), raw (.dd, .img) y muchas más
• Acceda a archivos desde imágenes (incluidas imágenes de máquinas virtuales) utilizando ‘Image Explorer (beta)’
• Totalmente compatible con entornos avanzados como Linux md RAID, LVM y sin tabla de particiones (sistema de archivos directamente en el disco)
• Admite la clonación (para el modo directo de «dispositivo a dispositivo» sin necesidad de una tercera unidad para almacenamiento temporal)
• Arranca desde una memoria USB Live en cualquier PC o Mac
• Copia de seguridad completa del sistema, recuperación completa, edición de particiones, protección de datos, navegación web y más
• Herramientas adicionales para la partición del disco duro, restablecimiento de fábrica, recuperación de archivos
• Navegador web para descargar controladores, leer documentación

Principales novedades de Rescuezilla 2.4

En esta nueva versión que se presenta de Rescuezilla 2.4 se destaca que se ha realizado un cambió a la base, pues anteriormente se estaba usando Ubuntu 21.10, pero por temas de compatibilidad se decidió regresar a Ubuntu 22.04.

Otro de los cambios que se destaca de esta nueva versión es que la utilidad partclone se ha actualizado a la versión 0.3.20, esto corrige el error de «característica no admitida» para los usuarios de sistemas de archivos BTRFS comprimidos (como Fedora Workstation 33 y posteriores). Se eliminó el antiguo partclone 0.2.43 utilizado para maximizar la compatibilidad heredada de Redo Backup (el partclone moderno aún brinda una buena compatibilidad con versiones anteriores)

Ademas de ello, tambien se destacan las mejoras de soporte para particiones Btrfs con compresión habilitada, asi como tambien que se ha proporcionado la capacidad de comprimir imágenes utilizando la utilidad bzip2 y que se agregó la capacidad de configurar un puerto de red diferente para SSH.

Por otra parte, se destaca que se corrigió la ejecución del script Clonezilla EFI NVRAM para manejar mejor el reinicio en los sistemas EFI.

Se cambió Firefox para usar el repositorio PPA del equipo de Mozilla, porque el nuevo paquete «snap» es incompatible con los scripts de compilación de Rescuezilla

Se movió la acción posterior a la finalización a la página en progreso y se actualizaron muchas traducciones existentes, pero también se agregaron: Árabe, Catalán, Checo, Húngaro y Eslovaco.

En cuanto a los errores conocidos en esta nueva versión:

• Al hacer una copia de seguridad de una unidad de Windows, algunos usuarios informan el error «Windows está en hibernación, se negó a montar» o «Error: sistema de archivos de solo lectura» y una copia de seguridad fallida. Esto generalmente se debe a la función de hibernación de Windows, con una solución ampliamente utilizada para seleccionar ‘Reiniciar’ (no apagar) desde el menú de inicio de Windows antes de iniciar la memoria USB de Rescuezilla. Pero algunos usuarios informan que incluso después de hacer un reinicio completo, el problema ahora persiste, con la única solución para que estos usuarios deshabiliten la hibernación por completo (lo que definitivamente no es una buena solución).

Finalmente si estás interesado en poder conocer más al respecto sobre esta nueva versión, puedes consultar los detalles en el siguiente enlace.

Descargar y obtener Rescuezilla 2.4

Para quienes estén interesados en poder obtener esta nueva versión, deben saber que se ofrecen para descargar compilaciones en vivo para sistemas x86 de 64 bits (1 GB) y un paquete deb para la instalación en Ubuntu.

La imagen ISO la pueden obtener desde el siguiente enlace.

from Linux Adictos https://ift.tt/z1yCqip
via IFTTT

Cuando he tenido que usar Chrome en Windows o macOS, ver el contenido en su modo oscuro no me ha resultado ningún problema. Sin embargo, en Linux sí. A mí, que me gustan poco los temas claros, siempre me ha resultado extraño, por ejemplo, abrir las herramientas del desarrollador y ver una parte oscura y otra, la del código, en blanco. Es algo que no me ha pasado en Windows, y hay una manera de conseguirlo en Linux.

Esto funciona para navegadores basados en Chromium que no ofrezcan una opción por sí mismos, como Brave. El navegador «valiente» lo cambia todo a oscuro si elegimos su tema oscuro, pero no es así en Chrome ni en Vivaldi. Si se puede conseguir de la misma manera en ambos casos, donde hacerlo está a un minuto de distancia. Y el modo oscuro que conseguiremos no será nada forzado, por lo que merece la pena.

Modo oscuro en Chrome/Chromium y derivados

Si tu distribución y tu navegador no te permite ver las páginas como en la imagen de cabecera, sólo tienes que abrir un terminal y escribir:

sudo gedit /usr/share/applications/google-chrome.desktop

Dentro, buscamos google-chrome-stable y cambiamos las líneas que tienen Exec=/usr/bin/google-chrome-stable %U y Exec=/usr/bin/google-chrome-stable añadiéndoles --enable-features=WebUIDarkMode --force-dark-mode al final. En el caso de Vivaldi, el archivo a modificar es vivaldi-stable.desktop y la línea a la que se le añaden las opciones es Exec=/usr/bin/vivaldi-stable %U. Deberían quedar como Exec=/usr/bin/google-chrome %U --enable-features=WebUIDarkMode --force-dark-mode, cambiando el ejecutable dependiendo del navegador que estemos usando. Y para que quede todo consistente, luego hay que instalar y activar un tema oscuro como este.

Lo malo de este método, que nos permite ver las páginas oscuras como debería ser sin forzar nada, es que deja de funcionar cada vez que se actualiza el navegador y vuelve a crear un nuevo archivo .desktop. Esto de que no cambie el tema con el del sistema operativo es un bug conocido, pero no lo han solucionado en años. Mientras tanto, podemos verlo todo con este pequeño truco.

from Linux Adictos https://ift.tt/gT3Nq0I
via IFTTT