valentin-metz/writeup_splitWriteup zu einer Heap-Overflow-Sicherheitslücke im Programm split der GNU coreutils. CVE-2024-0684
Eine Schwachstelle im Programm split der GNU coreutils ermöglicht einen Heap-Pufferüberlauf mit benutzerkontrollierten Daten.
Eingeführt wurde sie mit 40bf1591bb4362fa91e501bcec7c2029c5f65a43 am 2023-03-04. Ein Fix wurde veröffentlicht mit c4c5ed8f4e9cd55a12966d4f520e3a13101637d9 am 2024-01-17.
Betroffene Versionen: GNU coreutils v9.4; v9.3; v9.2
Proof of Concept:
Die Beispieldatei split_me in diesem Repository kann verwendet werden, um einen Absturz in den betroffenen Versionen auszulösen.
split -C 1024 ./split_me
Dadurch stürzt split mit einer Speicherzugriffsverletzung (SIGABRT) ab.
Ich habe diese Schwachstelle entdeckt, als ich versuchte, die Datenextraktion von Air-Gap-Systemen mithilfe von QR-Codes zu automatisieren.
Mit qrencode erzeugte QR-Codes haben eine Kapazität von ca. 4000 Zeichen, daher war eine intensive Nutzung von split erforderlich.
Bei einem bestimmten Testfall stürzte split mit einer Speicherzugriffsverletzung ab.
Da die GNU coreutils Open Source sind, können wir den Quellcode nutzen, um den Fehler zu identifizieren, anstatt ein Binary per Reverse Engineering analysieren zu müssen. Bei Open-Source-Projekten sollte man im Bug-Report so präzise wie möglich sein, idealerweise mit dem exakten Commit und der Zeile, die den Fehler eingeführt haben, sowie einem vorgeschlagenen Fix. Das ermöglicht es den Maintainern, den Report schnell zu verifizieren, und verkürzt die Reaktionszeit.
Bei der Überprüfung des Fehlers auf verschiedenen Systemen
ist mir aufgefallen, dass der Absturz nur bei relativ aktuellen Versionen von split auftrat.
Wenn man einen guten und einen schlechten Commit hat,
kann man eine binäre Suche in der Commit-Historie durchführen,
um den Commit zu finden, der den Fehler tatsächlich eingeführt hat.
Git bietet ein spezielles Werkzeug für diesen Anwendungsfall: git bisect.
Es schlägt automatisch Commits zum Testen vor und erlaubt es, sie als gut oder schlecht zu markieren.
Am Ende erhält man den Commit, der den Fehler eingeführt hat; in unserem Fall:
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(-)
Anschließend können wir das Programm (idealerweise mit einem Address Sanitizer) kompilieren,
um die genaue Zeile zu finden, an der es abstürzt.
Mit nur ca. 50 zu prüfenden Zeilen
wird es leicht, den Fehler zu identifizieren.
In unserem Fall trat der Absturz in einem memcpy()-Aufruf mit falschen Indizes auf.
Und tatsächlich: Wenn wir den Bereich um den memcpy()-Aufruf prüfen,
finden wir einen Diff, der die Indexberechnungen direkt davor verändert:
@@ -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;
Wenn wir diese Änderungen zurücksetzen und neu kompilieren,
verarbeitet split alle unsere Testfälle ohne Fehler.
Es bleibt nur noch, die Logik durchzugehen, um den Fehler zu verifizieren und einen Fix zu entwickeln.