Versión de la biblioteca del sistema Glibc 2.32

Después de seis meses de desarrollo publicado lanzamiento de la biblioteca del sistema Biblioteca GNU C (glibc) 2.32, que cumple plenamente con los requisitos de las normas ISO C11 y POSIX.1-2017. La nueva versión incluye correcciones de 67 desarrolladores.

De los implementados en Glibc 2.32 mejoras puedes notar:

  • Se agregó soporte para procesadores Synopsys ARC HS (ARCv2 ISA). El puerto requiere al menos binutils 2.32, gcc 8.3 y kernel de Linux 5.1 para ejecutarse. Se admiten tres variantes de ABI: arc-linux-gnu, arc-linux-gnuhf y arceb-linux-gnu (big-endian);
  • Carga de módulos de auditoría especificados en las secciones DT_AUDIT y
    DT_DEPAUDIT del archivo ejecutable.

  • Para la arquitectura powerpc64le, se implementa soporte para el tipo doble largo IEEE128, que se habilita al construir con la opción “-mabi=ieeelongdouble”.
  • Algunas API están anotadas con el atributo 'acceso' de GCC, que permite generar mejores advertencias cuando se compilan en GCC 10 para detectar posibles desbordamientos del búfer y otros escenarios fuera de límites.
  • Para sistemas Linux, las funciones pthread_attr_setsigmask_np y
    pthread_attr_getsigmask_np, que le dan a la aplicación la capacidad de especificar una máscara de señal para los subprocesos creados con pthread_create.

  • Los datos de codificación, la información del tipo de caracteres y las tablas de transliteración se actualizaron para admitir la especificación Unicode 13.0.0;
  • Se agregó un nuevo archivo de encabezado , que define la variable __libc_single_threaded, que se puede utilizar en aplicaciones para optimizaciones de un solo subproceso.
  • Se agregaron funciones sigabbrev_np y sigdescr_np que devuelven el nombre abreviado y la descripción de la señal (por ejemplo, “HUP” y “Hangup” para SIGHUP).
  • Se agregaron funciones strerrorname_np y strerrordesc_np que devuelven el nombre y la descripción del error (por ejemplo, "EINVAL" y "Argumento no válido" para EINVAL).
  • Para la plataforma ARM64, se ha agregado un indicador "--enable-standard-branch-protection" (o -mbranch-protection=standard en GCC), que permite que el mecanismo ARMv8.5-BTI (Branch Target Indicator) proteja la ejecución de conjuntos de instrucciones que no deben ejecutarse transiciones de bifurcación. El bloqueo de transiciones a secciones arbitrarias de código se implementa para evitar la creación de gadgets en exploits que utilizan técnicas de programación orientada al retorno (ROP - Programación orientada al retorno, el atacante no intenta colocar su código en la memoria, sino que opera en piezas ya existentes de instrucciones de máquina que finalizan con una instrucción de control de retorno, a partir de la cual se construye una cadena de llamadas para obtener la funcionalidad deseada).
  • Se ha llevado a cabo una limpieza importante de funciones obsoletas, incluida la eliminación de las opciones “--enable-obsolete-rpc” y “--enable-obsolete-nsl”, archivo de encabezado . Las funciones sstk, siginterrupt, sigpause, sighold, sigrelse, sigignore y sigset, las matrices sys_siglist, _sys_siglist y sys_sigabbrev, los símbolos sys_errlist, _sys_errlist, sys_nerr y _sys_nerr, y el módulo NSS hesiod han quedado obsoletos.
  • ldconfig se ha movido de forma predeterminada para utilizar el nuevo formato ld.so.cache, que ha sido compatible con glibc durante casi 20 años.
  • Vulnerabilidades solucionadas:
    • CVE-2016-10228: se produce un bucle en la utilidad iconv cuando se ejecuta con la opción "-c" al procesar datos multibyte incorrectos.
    • CVE-2020-10029 Corrupción de pila al llamar a funciones trigonométricas con un argumento pseudonulo.
    • CVE-2020-1752: acceso a memoria de uso posterior a liberación en la función global al expandir una referencia al directorio de inicio (“~usuario”) en las rutas.
    • CVE-2020-6096: manejo incorrecto en la plataforma ARMv7 de valores de parámetros negativos en memcpy() y memmove(), que determina el tamaño del área copiada. Permite organizar la ejecución del código al procesar datos formateados de cierta manera en las funciones memcpy() y memmove(). Es significativo que el problema se mantuvo sin corregir durante casi dos meses desde que la información se reveló públicamente y cinco meses desde que se notificó a los desarrolladores de Glibc.

Fuente: opennet.ru

Añadir un comentario