Rilascio della libreria di sistema Glibc 2.32

Dopo sei mesi di sviluppo pubblicato rilascio della libreria di sistema Libreria GNU C (glibc) 2.32, che è pienamente conforme ai requisiti degli standard ISO C11 e POSIX.1-2017. La nuova versione include correzioni di 67 sviluppatori.

Da quelli implementati in Glibc 2.32 miglioramenti puoi notare:

  • Aggiunto il supporto per i processori Synopsys ARC HS (ARCv2 ISA). Il port richiede almeno binutils 2.32, gcc 8.3 e Linux kernel 5.1 per essere eseguito. Sono supportate tre varianti ABI: arc-linux-gnu, arc-linux-gnuhf e arceb-linux-gnu (big-endian);
  • Caricamento dei moduli di audit specificati nelle sezioni DT_AUDIT e
    DT_DEPAUDIT del file eseguibile.

  • Per l'architettura powerpc64le è implementato il supporto per il tipo long double IEEE128, che viene abilitato durante la compilazione con l'opzione “-mabi=ieeelongdouble”.
  • Alcune API sono annotate con l'attributo 'access' di GCC, che consente di generare avvisi migliori quando compilati in GCC 10 per rilevare possibili buffer overflow e altri scenari fuori limite.
  • Per i sistemi Linux, le funzioni pthread_attr_setsigmask_np e
    pthread_attr_getsigmask_np, che dà all'applicazione la possibilità di specificare una maschera di segnale per i thread creati utilizzando pthread_create.

  • I dati di codifica, le informazioni sul tipo di carattere e le tabelle di traslitterazione sono stati aggiornati per supportare la specifica Unicode 13.0.0;
  • Aggiunto nuovo file di intestazione , che definisce la variabile __libc_single_threaded, che può essere utilizzata nelle applicazioni per ottimizzazioni a thread singolo.
  • Aggiunte le funzioni sigabbrev_np e sigdescr_np che restituiscono il nome abbreviato e la descrizione del segnale (ad esempio, “HUP” e “Hangup” per SIGHUP).
  • Aggiunte le funzioni strerrorname_np e strerrordesc_np che restituiscono il nome e la descrizione dell'errore (ad esempio, "EINVAL" e "Argomento non valido" per EINVAL).
  • Per la piattaforma ARM64 è stato aggiunto un flag "--enable-standard-branch-protection" (o -mbranch-protection=standard in GCC), che abilita il meccanismo ARMv8.5-BTI (Branch Target Indicator) per proteggere il esecuzione di set di istruzioni che non devono essere eseguite ramificazioni di transizioni. Il blocco delle transizioni a sezioni arbitrarie di codice è implementato per impedire la creazione di gadget negli exploit che utilizzano tecniche di programmazione orientata al ritorno (ROP - Return-Oriented Programming; l'attaccante non tenta di posizionare il proprio codice in memoria, ma opera su pezzi già esistenti di istruzioni macchina che terminano con un'istruzione di controllo di ritorno, da cui si costruisce una catena di chiamate per ottenere la funzionalità desiderata).
  • È stata effettuata un'importante pulizia delle funzionalità obsolete, inclusa la rimozione delle opzioni “--enable-obsolete-rpc” e “--enable-obsolete-nsl”, file di intestazione . Le funzioni sstk, siginterrupt, sigpause, sighold, sigrelse, sigignore e sigset, gli array sys_siglist, _sys_siglist e sys_sigabbrev, i simboli sys_errlist, _sys_errlist, sys_nerr e _sys_nerr e il modulo NSS hesiod sono stati deprecati.
  • ldconfig è stato spostato per impostazione predefinita per utilizzare il nuovo formato ld.so.cache, che è supportato in glibc da quasi 20 anni.
  • Vulnerabilità risolte:
    • CVE-2016-10228 – Si verifica un loop nell'utilità iconv quando viene eseguita con l'opzione "-c" durante l'elaborazione di dati multibyte errati.
    • CVE-2020-10029 Corruzione dello stack quando si chiamano funzioni trigonometriche con un argomento pseudo-null.
    • CVE-2020-1752 - Un accesso alla memoria use-after-free nella funzione glob quando si espande un riferimento alla directory home (“~user”) nei percorsi.
    • CVE-2020-6096 – Gestione errata sulla piattaforma ARMv7 dei valori dei parametri negativi in ​​memcpy() e memmove(), che determina la dimensione dell'area copiata. permette organizzare l'esecuzione del codice durante l'elaborazione dei dati formattati in un certo modo nelle funzioni memcpy() e memmove(). È significativo che il problema è rimasta non corretto per quasi due mesi da quando le informazioni sono state divulgate pubblicamente e cinque mesi da quando gli sviluppatori di Glibc sono stati informati.

Fonte: opennet.ru

Aggiungi un commento