La capacidad de poder ofrecer compilaciones reproducibles en Linux es una marca de transparencia y seguridad en la que actualmente diversas distribuciones se encuentran trabajando y que otras ya ofrecen.

La importancia de ello radica en que esto permite tanto a desarrolladores, investigadores como a usuarios verificar que el binario distribuido se ha creado correctamente a partir del código fuente proporcionado y no ha sido alterado.

Consultado un poco la documentación de Linux, podemos entender que:

Generalmente es deseable que la construcción del mismo código fuente con el mismo conjunto de herramientas sea reproducible, es decir, que el resultado sea siempre exactamente el mismo. Esto hace posible verificar que la infraestructura de construcción para una distribución binaria o un sistema integrado no haya sido subvertida. Esto también puede facilitar la verificación de que un cambio de fuente o herramienta no supone ninguna diferencia en los archivos binarios resultantes

Y en el caso Linux y de manera general en todo el software de código abierto, las compilaciones reproducibles son esenciales para garantizar que la comunidad pueda verificar y auditar el software de manera, además de que esto permite poder detectar cambios mal intencionados.

openSUSE Factory ya ofrece compilaciones reproducibles «bit a bit»

La razón de mencionar esto, es que el proyecto openSUSE ha introducido el soporte para compilaciones reproducibles «bit a bit» en su repositorio openSUSE Factory, que es la base para la distribución openSUSE Tumbleweed.

Esta actualización permite garantizar que los archivos binarios distribuidos en los paquetes sean generados de manera consistente a partir del código fuente proporcionado, sin incluir cambios ocultos y como mencionamos, el beneficio de realizar esto, es que cualquier usuario puede verificar por sí mismo que las compilaciones propuestas coinciden exactamente con las compilaciones generadas desde los códigos fuente.

Un ejemplo reciente es que las compilaciones reproducibles permiten la creación de pruebas, simplemente reconstruyendo y comparando el resultado, de que una compilación de GCC cuya fuente se extrajo con un xz comprometido no estaba comprometida; Este proceso se logró sin necesidad de realizar ingeniería inversa sobre cómo se produjo el compromiso. De manera similar, se informó que las compilaciones reproducibles eran útiles durante las investigaciones del compromiso xz

Las compilaciones reproducibles se logran teniendo en cuenta detalles como la exactitud en las dependencias, el uso de las mismas versiones y configuraciones de las herramientas de compilación, un conjunto idéntico de opciones y configuraciones predeterminadas, la preservación del orden de los archivos en la compilación (mediante métodos de clasificación consistentes), y la desactivación de la adición de información no permanente por parte del compilador, como valores aleatorios, referencias de rutas de archivos, y detalles de fecha y hora de la compilación

La capacidad de verificar un binario ofrece una capa adicional de seguridad al no depender únicamente de la confianza en la infraestructura del compilador. Esto es crucial porque comprometer el compilador o las herramientas de compilación podría conducir a la inserción de elementos maliciosos o cambios ocultos en los binarios resultantes.

Por ejemplo, los desarrolladores de openSUSE utilizaron compilaciones repetibles para garantizar la integridad de los binarios después del famoso incidente del backdoor detectado en el paquete xz. En este caso, la biblioteca liblzma comprometida, utilizada para descomprimir archivos con código GCC, podría haber introducido cambios maliciosos en el código GCC, lo que a su vez podría afectar a las aplicaciones ensambladas.

Es importante tener en cuenta que el repositorio Factory no está destinado a usuarios finales, sino principalmente a desarrolladores de distribuciones. Esto se debe a que su estabilidad no está garantizada en todo momento.

Los paquetes agregados a Factory pasan por pruebas automatizadas utilizando openQA. Una vez que estas pruebas se completan y se verifica la consistencia del estado de dependencia, el contenido del repositorio se sincroniza con los espejos varias veces por semana. El resultado final de este proceso se publica como openSUSE Tumbleweed, que es la distribución estable y confiable que los usuarios finales pueden utilizar con confianza.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

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

Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace ya varios días se dio a conocer la noticia de que fue detectada una vulnerabilidad en Flatpak (el sistema para construir, distribuir y ejecutar entornos aislados de aplicaciones de escritorio en Linux). Catalogada bajo CVE-2024-32462, junto con la clasificación CWE-88, la vulnerabilidad descubierta permitía escapar del sandbox a través de RequestBackground.

Esta vulnerabilidad afecta a ciertas versiones específicas de Flatpak, y su impacto puede ser grave, ya que una aplicacion especialmente diseñada podría ejecutar código arbitrario fuera del sandbox, comprometiendo la información del usuario.

Sobre la vulnerabilidad CVE-2024-32462

Se menciona que la vulnerabilidad permite que una aplicación maliciosa o comprometida distribuida mediante un formato de paquete flatpak eluda el modo de aislamiento de la zona de pruebas y acceda a los archivos del sistema principal. Este problema se manifiesta solo en paquetes que utilizan los portales de Freedesktop (xdg-desktop-portal), empleados para facilitar el acceso a recursos en el entorno del usuario desde aplicaciones aisladas.

Es posible pasar una interfaz arbitraria commandlinea la interfaz del portal org.freedesktop.portal.Background.RequestBackgrounddesde una aplicación Flatpak. Normalmente esto es seguro, porque sólo puede especificar un comando que existe dentro del entorno sandbox; pero cuando un objeto elaborado commandlinese convierte en –commandargumentos and, la aplicación podría lograr el mismo efecto de pasar argumentos directamente a bwrapy, por lo tanto, lograr un escape de zona protegida.

La solución es que Flatpak use el –argumento to bwrap, lo que hace que detenga las opciones de procesamiento, antes de agregar el comando especificado por el atacante. El –argumento ha sido respaldado desde bubblewrap 0.3.0, y todas las versiones compatibles de Flatpak ya requieren al menos esa versión de bubblewrap.

La explotación de esta vulnerabilidad permite a una aplicación en un entorno aislado utilizar la interfaz xdg-desktop-portal para crear un archivo «.desktop» con un comando que inicia la aplicación desde flatpak, permitiendo así el acceso a los archivos en el sistema principal.

La esencia de la vulnerabilidad que permite evadir el entorno aislado reside el argumento –command de flatpak run, el cual esperaba recibir un comando para ejecutar en la aplicación Flatpak especificada, junto con algunos argumentos opcionales. Al manipular el parámetro «–command«, que se emplea para pasar el nombre del programa, era posible pasar un nombre de opción, como por ejemplo –bind, y esto era interpretado erróneamente como una opción de bwrap para ejecutar el programa especificado dentro del paquete, en un entorno aislado.

Un ejemplo práctico de ello que se menciona, es para ejecutar la utilidad ls en un entorno de paquetes aislado, se utiliza algo similar a esto:

"flatpak run --command=ls org.gnome.gedit"

La cual ejecutará:

"bwrap ...lots of stuff... --bind / /host ls -l /host".

En este caso, el nombre «–bind» no se considerará como el nombre de la aplicación a ejecutar, sino como una opción de bwrap.

Como tal, la vulnerabilidad radica en el hecho de que si el nombre del programa comienza con los caracteres «–«, la utilidad bwrap lo interpretará como su propia opción. Originalmente, enviar comandos de esta manera no se consideraba peligroso, ya que se ejecutarían en un entorno aislado del paquete. Sin embargo, no se tuvo en cuenta que los comandos que comienzan con «–» serán interpretados como opciones por la utilidad bwrap. Como resultado, la interfaz xdg-desktop-portal se puede aprovechar para crear un archivo «.desktop» con un comando que explote esta vulnerabilidad.

El argumento —  ha sido compatible desde bubblewrap 0.3.0, y todas las versiones compatibles de Flatpak ya requieren al menos esa versión de bubblewrap. Se menciona que una de las soluciones es que la versión 1.18.4 de xdg-desktop-portal ya no permita que las aplicaciones Flatpak creen nuevos archivos .desktop para los comandos que se inician con -.

Finalmente cabe mencionar que la vulnerabilidad ha sido corregida en las versiones parcheadas de Flatpak 1.15.8, 1.14.6, 1.12.9 y 1.10.9. Asimismo, se ha propuesto una solución de seguridad en las versiones 1.16.1 y 1.18.4 de xdg-desktop-portal.

Puedes consultar la versión de Flatpak que tienes ejecutando el siguiente comando:

flatpak --version

En dado caso de estar sobre una versión vulnerable o si quieres actualizar tu versión de Flatpak, basta con ejecutar alguno de los siguientes comando:

Ubuntu/Debian y derivados:

sudo apt upgrade flatpak

RHEL/Fedora  y derivados:

sudo dnf upgrade flatpak

Arch Linux y derivados:

sudo pacman -Syu flatpak

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

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

Después de un período de prueba de 6 meses, al 1 de abril de 2024, los desarrolladores del entorno de escritorio XFCE dieron conocer, mediante una publicación de blog, la decisión de trasladar los canales oficiales de comunicación del proyecto XFCE de IRC a Matrix.

Los desarrolladores mencionan que la principal razón detrás de esta migración es principalmente a la finalización del soporte para la integración de canales IRC en Matrix en la red IRC Libera.Chat, ya que muchos desarrolladores usaban Matrix para acceder a los canales de IRC a través de estos.

El cierre se debe a la decisión de tomar acción respecto al puente de Element Matrix Services (EMS) surgió por diversas preocupaciones de estabilidad, seguridad y privacidad, lo que culminó en la solicitud de desactivar la función de portal de EMS.

Otro de los factores que llevo a Libera.Chat a tomar la decisión fue debido a la carga de abusos, incluyendo oleadas de bots, filtraciones de privacidad y vulnerabilidades de seguridad, generó una tensión significativa en los recursos de Libera y la dificultad para abordar estos problemas con EMS.

Los desarrolladores de XFCE mencionaron que al perder el soporte, se fragmentó la comunicación entre usuarios que permanecieron en IRC y aquellos que se mudaron a canales Matrix independientes y con la finalidad de mantener una plataforma de comunicación unificada, se optó por transferir oficialmente los canales a la plataforma Matrix.

Además, la disminución de la popularidad de IRC se debe a varios factores, como la falta de familiaridad para los nuevos usuarios y la obsolescencia del protocolo en comparación con las necesidades modernas de comunicación.

Y es que Matrix ofrece una gran cantidad de ventajas al ser una plataforma abierta y descentralizada, lo cual es un ganar-ganar tanto para el proyecto como para la comunidad. Entre las ventajas de Matrix sobre IRC que contribuyeron a esta elección, se destacan las siguientes:

• Facilidad de uso: Matrix proporciona una experiencia de uso más amigable en comparación con IRC, lo que puede reducir la barrera de entrada para nuevos usuarios.
• Cifrado de extremo a extremo: Matrix ofrece cifrado de extremo a extremo de forma predeterminada, lo que garantiza la privacidad y seguridad de las conversaciones.
• Sincronización de mensajes: Los canales de Matrix retienen los mensajes que llegan mientras un usuario está desconectado, evitando la pérdida de información y fomentando una comunicación más fluida.
• Plataforma abierta y descentralizada: Matrix es una plataforma abierta y no depende de servidores centralizados, lo que la hace más resistente a fallos y censura.
• Multi-dispositivo: El historial de chat se sincroniza en múltiples dispositivos de forma predeterminada en Matrix, eliminando la necesidad de configuraciones complejas.
• Al acceder a canales IRC a través del puente Matrix, no es necesario administrar un Bouncer IRC . Los canales Bridged Matrix retienen los mensajes que llegan mientras usted no está conectado.

Se menciona que aunque los canales IRC anteriores siguen disponibles, ahora el principal punto de atención es la promoción de los canales basados en Matrix como el método oficial de comunicación interactiva en la documentación y el sitio web del proyecto.

Por ejemplo, para soporte técnico y discusiones generales, se alienta a usar #xfce:matrix.org en lugar del antiguo canal IRC #xfce en la red libera.chat. De manera similar, para debates relacionados con el desarrollo, se sugiere utilizar #xfce-dev:matrix.org en lugar de #xfce-dev en IRC, y para rastrear la actividad en GitLab, se recomienda #xfce-commits:matrix.org en lugar de #xfce-commits en IRC

Finalmente, cabe mencionar que Matrix no es el único canal de comunicación que tiene el proyecto XFCE, ya que también se ofrece a los usuarios la posibilidad de contribuir, participar o enviar sus dudas en el foro de Xfce o en la lista de correo xfce. De igual forma, si tienes dudas sobre como informarte en el proceso de desarrollo del entorno, puedes consultar su wiki en el siguiente enlace.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en él, siguiente enlace.

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