Glibc 2.34 chega com correções de vulnerabilidades, novas funções para Linux e muito mais

Faz pouco o lançamento da nova versão do Glibc 2.34 foi anunciado que vem após seis meses de desenvolvimento e no qual várias mudanças bastante importantes foram feitas, entre as quais a inclusão das bibliotecas libpthread, libdl, libutil e libanl, bem como várias correções de bugs, uma das quais causou bloqueios.

Para aqueles que não estão familiarizados com o Glibc, eles devem saber o que é uma biblioteca GNU C, comumente conhecido como glibc é a biblioteca GNU C em tempo de execução padrão. Em sistemas onde é usado, esta biblioteca C que fornece e define chamadas de sistema e outras funções básicas, é usado por quase todos os programas. 

Principais novos recursos do Glibc 2.34

Nesta nova versão do Glibc 2.34 que é apresentada libpthread, libdl, libutil e libanl foram integrados à biblioteca principal, o uso de sua funcionalidade em aplicativos não requer mais a ligação deles com os sinalizadores -lpthread, -ldl, -lutil e -lanl.

Além disso, é mencionado que preparações foram feitas para integrar libreolv em libc, com o qual a integração irá permitir um processo de atualização glibc mais suave e simplificará a implementação em tempo de execução e as bibliotecas stub também foram fornecidas para compatibilidade com aplicativos construídos com versões anteriores do glibc.

Da parte das mudanças focadas no Linux Glibc 2.34 destaca o capacidade adicional de usar o tipo time_t de 64 bits nas configurações que tradicionalmente usava o tipo time_t 32 bits. Este recurso está disponível apenas em sistemas com kernel 5.1 e superior.

Outra mudança específica para Linux é o implementação da função execveato que permite a execução de um arquivo executável a partir de um descritor de arquivo aberto. A nova função também é usada na implementação da chamada fexecve, que não requer que o pseudo-sistema de arquivos / proc seja montado na inicialização.

A função também foi adicionada close_range () que está disponível para Linux versões 5.9 e superior e que pode ser usado para permitir que um processo feche uma gama completa de descritores de arquivo aberto ao mesmo tempo, além do parâmetro glibc.pthread.stack_cache_size é implementado, que pode ser usado para ajustar o tamanho do cache de pilha pthread.

Além disso, adicionada função _Fork, uma substituição para função garfo que atende aos requisitos de "async-signal-safe", ou seja, pode ser chamado com segurança a partir de manipuladores de sinal. Durante a execução de _Fork, um ambiente mínimo é formado, o suficiente para chamar funções em manipuladores de sinal como raise e execve, sem invocar recursos que podem alterar os bloqueios ou o estado interno.

Para a parte das vulnerabilidades corrigidas no Glibc 2.34, o seguinte é mencionado:

CVE-2021-27645: O processo nscd (daemon de cache do servidor de nomes) falhou devido a uma chamada dupla para a função livre durante o processamento de solicitações de grupo de rede especialmente criadas.

CVE-2021-33574: acesso a uma área de memória já liberada (use-after-free) na função mq_notify ao usar o tipo de notificação SIGEV_THREAD com um atributo de encadeamento para o qual uma máscara de ligação de CPU alternativa é definida. O problema pode causar um travamento, mas outras opções de ataque não são excluídas.

CVE-2021-35942: O estouro do tamanho do parâmetro na função wordexp pode travar o aplicativo.

Das outras mudanças que se destacam:

  • A função timespec_getres, definida no rascunho do padrão ISO C2X, foi adicionada e a função timespec_get foi aumentada com recursos semelhantes à função POSIX clock_getres.
  • No arquivo gconv-modules, apenas um conjunto mínimo de módulos principais gconv permaneceu, e o resto foi movido para um arquivo gconv-modules-extra.conf adicional localizado no diretório gconv-modules.d.
  • O uso de links simbólicos para vincular objetos compartilhados instaláveis ​​à versão Glibc foi removido. Esses objetos agora são instalados como estão (por exemplo, libc.so.6 agora é um arquivo em vez de um link para libc-2.34.so).
  • No Linux, funções como shm_open e sem_open agora requerem um sistema de arquivos para a memória compartilhada montada no ponto de montagem / dev / shm.

Finalmente se você estiver interessado em saber mais sobre isso desta nova versão, você pode verificar o detalhes no link a seguir.


O conteúdo do artigo segue nossos princípios de Ética editorial. Para relatar um erro, clique Clique aqui.

Seja o primeiro a comentar

Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.