Glibc 2.34 chega con correccións de vulnerabilidade, novas funcións para Linux e moito máis

Recientemente anunciouse o lanzamento da nova versión de Glibc 2.34 que vén despois de seis meses de desenvolvemento e nos que se fixeron varios cambios bastante importantes, entre os que se inclúen as bibliotecas libpthread, libdl, libutil e libanl, así como varias correccións de erros dos cales un deles causou bloqueos.

Para aqueles que non estean familiarizados con Glibc, deberían saber de que se trata unha biblioteca GNU C, normalmente coñecido como glibc é a biblioteca de tempo de execución estándar de GNU C. Nos sistemas onde se usa, esta biblioteca C que ofrece e define chamadas ao sistema e outras funcións básicas, é usado por case todos os programas. 

Principais novidades de Glibc 2.34

Nesta nova versión de Glibc 2.34 que se presenta libpthread, libdl, libutil e libanl integráronse na biblioteca principal, usar a súa funcionalidade en aplicacións xa non require enlazalos coas bandeiras -lpthread, -ldl, -lutil e -lanl.

Ademais, cítase que fixéronse preparativos para integrar libreolv en libc, co que a integración permitirá un proceso de actualización glibc máis suave e simplificará a implementación do tempo de execución e tamén se proporcionaron bibliotecas stub para a compatibilidade con aplicacións construídas con versións anteriores de glibc.

Por parte dos cambios centráronse en Linux Glibc 2.34 destaca o engadiu capacidade para usar o tipo time_t de 64 bits en configuracións que tradicionalmente utilizaba o tipo time_t 32 bits. Esta función só está dispoñible en sistemas con kernel 5.1 e superior.

Outro cambio específico para Linux é o implementación da función execveatQue permite executar un ficheiro executable dende un descriptor de ficheiro aberto. A nova función úsase tamén na implementación da chamada fexecve, que non precisa montar o pseudo-sistema de ficheiros / proc ao inicio.

A función tamén se engadiu close_range () que está dispoñible para as versións de Linux 5.9 e superior e cal pode ser úsase para permitir que un proceso peche unha gama completa de descritores de ficheiros aberto ao mesmo tempo, tamén implementa o parámetro glibc.pthread.stack_cache_size, que pode usarse para axustar o tamaño da caché da pila de pthread.

Por outra banda, engadiu a función _Fork, un substituto para a función garfo que cumpre os requisitos "async-signal-safe", o que significa que se pode chamar de forma segura desde os controladores de sinal. Durante a execución de _Fork, fórmase un ambiente mínimo, o suficiente para chamar a funcións en controladores de sinal como aumentar e executar, sen invocar funcións que poidan cambiar bloqueos ou estado interno.

Para a parte das vulnerabilidades corrixidas en Glibc 2.34, cítanse os seguintes:

CVE-2021-27645: Fallou o proceso nscd (demonio de almacenamento en caché do servidor de nomes) debido a unha dobre chamada á función gratuíta mentres se procesaban solicitudes de grupo de rede especialmente deseñadas.

CVE-2021-33574: acceso a unha área de memoria xa liberada (use-after-free) na función mq_notify cando se usa o tipo de notificación SIGEV_THREAD cun atributo de fío para o que se establece unha máscara de conexión de CPU alternativa. O problema pode causar un fallo, pero non se exclúen outras opcións de ataque.

CVE-2021-35942: O desbordamento do tamaño do parámetro na función wordexp podería bloquear a aplicación.

Dos outros cambios que destacan:

  • Engadiuse a función timespec_getres, definida no borrador da norma ISO C2X e aumentouse a función timespec_getres con capacidades similares á función POSIX clock_getres.
  • No ficheiro gconv-modules, só quedaba un conxunto mínimo de módulos gconv principais e o resto foron movidos a un ficheiro gconv-modules-extra.conf adicional situado no directorio gconv-modules.d.
  • Eliminouse o uso de ligazóns simbólicas para ligar obxectos compartidos instalables á versión Glibc. Estes obxectos agora están instalados tal cal (por exemplo, libc.so.6 agora é un ficheiro en lugar dunha ligazón a libc-2.34.so).
  • En Linux, funcións como shm_open e sem_open agora requiren un sistema de ficheiros para a memoria compartida montada no punto de montaxe / dev / shm.

Finalmente se estás interesado en saber máis sobre el desta nova versión, pode comprobar o detalles na seguinte ligazón.


O contido do artigo adhírese aos nosos principios de ética editorial. Para informar dun erro faga clic en aquí.

Sexa o primeiro en opinar sobre

Deixa o teu comentario

Enderezo de correo electrónico non será publicado. Os campos obrigatorios están marcados con *

*

*

  1. Responsable dos datos: Miguel Ángel Gatón
  2. Finalidade dos datos: controlar SPAM, xestión de comentarios.
  3. Lexitimación: o seu consentimento
  4. Comunicación dos datos: os datos non serán comunicados a terceiros salvo obrigación legal.
  5. Almacenamento de datos: base de datos aloxada por Occentus Networks (UE)
  6. Dereitos: en calquera momento pode limitar, recuperar e eliminar a súa información.