valentin-metz/writeup_splitAnalisi di una vulnerabilità di heap overflow nel programma split di GNU coreutils. CVE-2024-0684
Una vulnerabilità nel programma "split" di GNU coreutils permette un heap buffer overflow con dati controllati dall'utente.
È stata introdotta nel commit 40bf1591bb4362fa91e501bcec7c2029c5f65a43 il 4 marzo 2023. Una correzione è stata rilasciata con il commit c4c5ed8f4e9cd55a12966d4f520e3a13101637d9 il 17 gennaio 2024.
Versioni interessate: GNU coreutils v9.4; v9.3; v9.2
Prova di concetto:
Il file di esempio split_me in questo repository può essere utilizzato per innescare un crash nelle versioni affette.
split -C 1024 ./split_me
Questo causerà il crash di split con un segmentation fault (SIGABRT).
Ho scoperto questa vulnerabilità mentre cercavo di automatizzare l'estrazione di dati da sistemi air-gapped utilizzando codici QR. I codici QR generati con qrencode hanno una capacità di circa 4000 caratteri, quindi richiedevano un uso intensivo di split. In un caso di test specifico, split è andato in crash con un segmentation fault.
Poiché i GNU coreutils sono open source, possiamo usare il codice sorgente per identificare il bug, invece di dover fare reverse engineering di un binario. Nei progetti open source, si vuole essere il più specifici possibile nel rapporto di bug, idealmente fornendo il commit esatto e la riga che ha introdotto il bug, oltre a una correzione proposta. Ciò permette ai manutentori di verificare rapidamente il rapporto e riduce i tempi di risposta.
Durante la verifica del bug su diversi sistemi, ho notato che il crash si verificava solo su versioni relativamente recenti di split. Se si ha un commit buono e uno cattivo, è possibile eseguire una ricerca binaria sulla cronologia dei commit per trovare il commit che ha effettivamente introdotto il bug.
Git fornisce uno strumento specifico per questo caso d'uso: git bisect. Suggerirà automaticamente i commit da testare e permetterà di segnarli come buoni o cattivi. Alla fine si ottiene il commit che ha introdotto il bug; nel nostro caso:
commit 40bf1591bb4362fa91e501bcec7c2029c5f65a43
Author: Paul Eggert <[email protected]>
Date: Sat Mar 4 11:42:16 2023 -0800
split: prefer signed integers to size_t
This allows for better runtime checking with gcc
-fsanitize=undefined.
* src/split.c: Include idx.h.
(open_pipes_alloc, n_open_pipes, suffix_length)
(set_suffix_length, input_file_size, sufindex, outbase_length)
(outfile_length, addsuf_length, create, cwrite, bytes_split)
(lines_split, line_bytes_split, lines_chunk_split)
(bytes_chunk_extract, ofile_open, lines_rr, main):
Prefer signed integers (typically idx_t) to size_t.
src/split.c | 105 ++++++++++++++++++++++++++++++------------------------------
1 file changed, 52 insertions(+), 53 deletions(-)
Possiamo quindi compilare il programma (idealmente con un address sanitizer), per trovare la riga esatta in cui va in crash. Con solo circa 50 righe da esaminare, diventa facile identificare il bug. Nel nostro caso, il crash è avvenuto in una chiamata memcpy() con indici errati. E in effetti, se controlliamo l'area intorno alla chiamata memcpy(), troviamo un diff che modifica i calcoli degli indici poco prima:
@@ -816,15 +820,10 @@
/* Update hold if needed. */
if ((eoc && split_rest) || (!eoc && n_left))
{
- size_t n_buf = eoc ? split_rest : n_left;
+ idx_t n_buf = eoc ? split_rest : n_left;
if (hold_size - n_hold < n_buf)
- {
- if (hold_size <= SIZE_MAX - bufsize)
- hold_size += bufsize;
- else
- xalloc_die ();
- hold = xrealloc (hold, hold_size);
- }
+ hold = xpalloc (hold, &hold_size, n_buf - (hold_size - n_hold),
+ -1, sizeof *hold);
memcpy (hold + n_hold, sob, n_buf);
n_hold += n_buf;
n_left -= n_buf;
Se annulliamo queste modifiche e ricompiliamo, split elabora tutti i nostri casi di test senza errori.
Non resta che esaminare la logica per verificare il bug e sviluppare una correzione.