Hace pocos dias se dio a conocer la noticia de que fueron encontradas una serie de vulnerabilidades en swhkd (Simple Wayland HotKey Daemon) provocadas por un manejo incorrecto de archivos temporales, opciones de línea de comandos y sockets unix.

El programa está escrito en Rust y maneja teclas de acceso rápido en entornos basados ​​en el protocolo Wayland (un análogo compatible con archivos de configuración del proceso sxhkd utilizado en entornos basados ​​en X11). El paquete incluye un proceso swhks sin privilegios que realiza acciones para las teclas de acceso rápido y un proceso en segundo plano swhkd que se ejecuta como root e interactúa con los dispositivos de entrada en el nivel de la API uinput . Para organizar la interacción entre swhks y swhkd, se utiliza un socket Unix.

Las reglas de Polkit permiten que cualquier usuario local ejecute el proceso /usr/bin/swhkd como root y le pase parámetros arbitrarios.

La integración del paquete RPM presentado para openSUSE Tumbleweed contenía reglas de Polkit inusuales en el archivo de definición que requirió una revisión por parte del equipo de seguridad de SUSE.

Como resultado de la revisión, se identificaron múltiples problemas de seguridad. Los problemas individuales se describen en el siguiente informe detallado.

De las vulnerabilidades que fueron identificadas, se mencionan las siguientes:

CVE-2022-27815

Esta vulnerabilidad permite poder guardar un PID de proceso en un archivo con un nombre predecible y en un directorio que otros usuarios puedan escribir (/tmp/swhkd.pid), con lo cual cualquier usuario puede crear un archivo /tmp/swhkd.pid y poner el pid de un proceso existente en él, lo que hará que sea imposible iniciar swhkd.

En ausencia de protección contra la creación de enlaces simbólicos en /tmp, la vulnerabilidad se puede utilizar para crear o sobrescribir archivos en cualquier directorio del sistema (el PID se escribe en el archivo) o determinar el contenido de cualquier archivo en el sistema (swhkd genera el todo el contenido del archivo PID a stdout). Cabe señalar que en la corrección publicada, el archivo PID no se movió al directorio /run, sino al directorio /etc (/etc/swhkd/runtime/swhkd_{uid}.pid), donde tampoco pertenece.

CVE-2022-27814

Esta vulnerabilidad permite manipular la opción de línea de comando «-c» para especificar un archivo de configuración puede determinar la existencia de cualquier archivo en el sistema.

Como en el caso de la primera vulnerabilidad, solucionar el problema es desconcertante: solucionar el problema se reduce al hecho de que la utilidad externa «cat» (‘Command::new(«/bin/cat»).arg(ruta) es ahora lanzado para leer el archivo de configuración.output()’).

CVE-2022-27819

Este problema también está relacionado con el uso de la opción «-c», que carga y analiza todo el archivo de configuración sin verificar el tamaño y el tipo del archivo.

Por ejemplo, para provocar una denegación de servicio debido al agotamiento de la memoria libre y la creación de E/S parásitas, puede especificar un dispositivo de bloque al inicio («pkexec /usr/bin/swhkd -d -c /dev/sda») o un dispositivo de caracteres que emite un flujo infinito de datos.

El problema se resolvió restableciendo los privilegios antes de abrir el archivo, pero la solución no estaba completa, ya que solo se restablece la ID de usuario (UID), pero la ID de grupo (GID) sigue siendo la misma.

CVE-2022-27818

Esta vulnerabilidad permite poder usar un archivo /tmp/swhkd.sock para crear un socket Unix, que se crea en un directorio público grabable, lo que genera problemas similares a los de la primera vulnerabilidad (cualquier usuario puede crear /tmp/swhkd. sock y generar o interceptar eventos de pulsación de teclas).

CVE-2022-27817

En esta vulnerabilidad, los eventos de entrada se reciben de todos los dispositivos y en todas las sesiones, es decir, un usuario de otra sesión de Wayland o de la consola puede interceptar eventos cuando otros usuarios presionan teclas de acceso rápido.

CVE-2022-27816

El proceso swhks, como swhkd, usa el archivo PID /tmp/swhks.pid en el directorio /tmp de escritura pública. El problema es similar a la primera vulnerabilidad, pero no tan peligroso, ya que swhks se ejecuta bajo un usuario sin privilegios.

Finalmente 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/DClv8bx
via IFTTT

El W3C dio a conocer hace poco mediante una publicación, un borrador de una nueva especificación que estandariza el código de preparación de WebAssembly 2.0 y la API asociada para permitir la creación de aplicaciones de alto rendimiento que son portátiles entre navegadores y plataformas de hardware.

Para quienes desconocen de WebAssembly, deben saber que este proporciona un middleware genérico, de bajo nivel e independiente del navegador, para ejecutar aplicaciones compiladas a partir de varios lenguajes de programación. Gracias al uso de JIT para WebAssembly, puede lograr un nivel de rendimiento cercano al código nativo.

Sobre WebAssembly

WebAssembly se puede utilizar para realizar tareas de alto rendimiento en el navegador, como codificación de video, procesamiento de audio, manipulación de gráficos y 3D, desarrollo de juegos, operaciones criptográficas y cálculos matemáticos, mediante la ejecución de código escrito en lenguajes compilados como C/ C++.

Entre las principales tareas de WebAssembly está la provisión de portabilidad, previsibilidad de comportamiento e identidad de ejecución de código en diferentes plataformas. Recientemente, WebAssembly también se ha promocionado como una plataforma universal para la ejecución segura de código en cualquier infraestructura, sistema operativo y dispositivo, sin limitarse a los navegadores.

Sobre el borrador de WebAssembly 2.0

Por la parte de las modificaciones que se han realizado desde WebAssembly estan las propuestas terminadas para WebAssembly 2.0 se encuentran SIMD de ancho fijo, operaciones de memoria masiva, tipos de referencia, compatibilidad con BigInt de JavaScript para WebAssembly i64, compatibilidad con múltiples valores de retorno e importación/exportación de variables globales mutables.

El W3C ha publicado tres borradores de especificaciones de WebAssembly 2.0:

1. WebAssembly Core: describe una máquina virtual de bajo nivel para ejecutar código intermedio de WebAssembly. Los recursos relacionados con WebAssembly vienen en formato «.wasm», similar a los archivos Java «.class», que contienen datos estáticos y segmentos de código para trabajar con esos datos.
2. Interfaz JavaScript de WebAssembly: proporciona una API para la integración con JavaScript. Le permite obtener valores y pasar parámetros a las funciones de WebAssembly. La ejecución de WebAssembly sigue el modelo de seguridad de JavaScript y toda la interacción con el sistema principal se realiza de manera similar a la ejecución del código JavaScript.
3. WebAssembly Web API: define una API basada en el mecanismo Promise para solicitar y ejecutar recursos «.wasm». El formato de recursos de WebAssembly está optimizado para iniciar la ejecución sin esperar a que el archivo se descargue por completo, lo que mejora la capacidad de respuesta de las aplicaciones web.

Diferencias entre WebAssembly y WebAssembly 2.0

Ademas, cabe resaltar que existen algunos cambios importantes en WebAssembly 2.0 en comparación con la primera versión del estándar:

• Compatibilidad con el tipo de vector v128 y las instrucciones de vector relacionadas que le permiten realizar operaciones en múltiples valores numéricos en paralelo (SIMD, instrucción única, datos múltiples).
• Capacidad para importar y exportar variables globales mutables, lo que permite el enlace global para valores como punteros de pila en C++.
• Nuevas instrucciones para convertir float a int, que en lugar de generar una excepción en el desbordamiento de resultados, devuelve el valor mínimo o máximo posible (requerido para SIMD).
• Instrucciones para expandir el signo de números enteros (aumentar la profundidad de bits de un número manteniendo el signo y el valor).
• Soporte para devolver múltiples valores por bloques y funciones (además de pasar múltiples parámetros a funciones).
• Implementar las funciones de JavaScript BigInt64Array y BigUint64Array para convertir entre el tipo de JavaScript BigInt y la representación WebAssembly de enteros de 64 bits.
• Soporte para tipos de referencia (funcref y externref) y sus instrucciones asociadas (select, ref.null, ref.func y ref.is_null).
• Instrucciones memory.copy, memory.fill, memory.init y data.drop para copiar datos entre regiones de memoria y borrar regiones de memoria.
• Instrucciones para acceso directo y modificación de tablas (table.set, table.get, table.size, table.grow).
• Capacidad para crear, importar y exportar múltiples tablas en un módulo. Funciones para copiar/llenar tablas en modo por lotes (table.copy, table.init y elem.drop).

Finalmente 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/G36e9Di
via IFTTT