Hackers kunnen door kwetsbaarheid in Rust-library's op afstand code uitvoeren

Beveiligingsbedrijf Edera heeft een ernstige kwetsbaarheid ontdekt in de populaire Rust-library async-tar en de forks daarvan. De kwetsbaarheid, die de naam TARmageddon heeft gekregen, kan ervoor zorgen dat hackers op afstand code kunnen uitvoeren.

Edera ontdekte de kwetsbaarheid in augustus, schrijft het bedrijf in een blogbericht. Het lek met CVE-nummer CVE-2025-62518 heeft een CVSS-score van 8,1. TARmageddon raakt meerdere veelgebruikte programma's, waaronder de populaire Python-packagemanager uv en de softwarebibliotheek testcontainers.

Het gaat om een boundary-parsing bug die gebruikmaakt van een fout in het uitlezen van pax- en ustar-headers. De pax-header geeft de correcte bestandsgrootte op, maar de ustar-header geeft ten onrechte een bestandsgrootte van 0 bytes. De kwetsbare parser bepaalt vervolgens de positie van de volgende header aan de hand van de grootte die is opgegeven in de ustar-header.

Daardoor leest de parser verborgen tar-archieven alsof zij onderdeel zijn van het hoofdarchief. Hierdoor kan een hacker onder meer supplychainaanvallen uitvoeren door kwaadaardige tar-packages te uploaden naar de openbare Python-repository PyPI. Die verborgen archieven bevatten een configuratiebestand, dat het systeem de opdracht geeft om kwaadaardige scripts uit te voeren.

Volgens Edera is het ook problematisch dat de populairste fork van async-tar, tokio-tar, niet meer actief wordt geüpdatet. Tokio-tar heeft meer dan vijf miljoen downloads op crates.io en werd voor het laatst bijgewerkt in juli 2023. Het lek is in deze library nog altijd niet gepatcht. Gebruikers wordt daarom aangeraden om over te stappen op astral-tokio-tar.

Reacties (32)

[thePiett]

Ja maar, Rust is toch veilig?

[berchtold]

memory-safe. niet domme developer safe

[Memori]

Ik weet niet of het domme developers zijn. Het lijkt mij misschien wel een bewuste keuze zijn geweest om de parser te laten doen wat het doet. De consequenties waren bij voorhand wellicht niet overwogen.

[Oudecomputer]

Je ontwikkelt een veilige taal en het meest basic bug exploit wordt niet afgetimmerd. Wat te doen met incorrecte data. Hacking 101. Ergens incorrecte data in voeren, om een programma te laten doen wat jij wilt..

Dit is gewoon zeer slecht en een gigantische zwakte van een programmeertaal rust wat zich juist profileert als veilig.

In veel oude programmeertalen zoals Pascal/Delfi wat bijna net zo oud is als C. Is dit gewoon dicht getimmerd door verplicht te definieer van je variabelen! Hier door worden verkeerde niet logische waardes niet geaccepteerd.

Dus misschien is het niet dom maar gewoon lui programmeren. Het is duidelijk gewoon een zwakte van rust dat niet stimuleerd goed/ netjes te programmeren en gewoon de zelfde zwakte heeft als C. Luie programmeurs hun ding laten doen ipv ze verplichten te checken of de data wel voldoet aan de verwachtingen ipv gewoon ontvangen en dom uitvoeren.

Stap 1 is definiëren van variabelen maar dan ben je er niet dan is er nog stap 2 . Dit soort lui programmeren is de oorzaak geweest van het neerstorten van de Boeing 737 max blind vertrouwen op data die binnen komt niet checken of het logisch is en direct uitvoeren. Slim geprogrammeerde software kijkt ook of de data ook logisch is, in lijn met verwachting voor het code uitvoert. Ik werk in de industrie en heb al zo veel gevolgen gezien van slechte code die blind uitvoert zonder controle of terug koppeling.

[Argantonis]

Hoezo is het een zwakte van de programmeertaal als dit een library is?

[pixeled]

Weet niet waarom je gemint wordt, want je hebt gewoon gelijk: Rust is memory safe. Voor de rest kun je er prima hele onveilige dingen mee bouwen.

"Rust is toch safe?" is hetzelfde als zeggen "Bakstenen zijn heel hard dus daar kun je toch altijd veilig een huis mee bouwen dat niet instort?" Nou, dat hangt er nogal vanaf hoe je de bakstenen op elkaar metselt

[Daoka]

Ergens is het zeker logisch dat Rust problemen kan hebben. Maar ik zeg eerlijk het was ook wel mijn eerste gedachten. Want meestal als je iets over Rust zie is er wel iemand die zegt dat Rust zo veilig is, dat het zo een goede taal is, ect. Maar ik heb nooit gelezen dat Rust onveilig kan zijn (nu ben ik ook geen programmeur en lees ik ook weinig over rust). Ik dus snap de reactie van "Ja maar, Rust is toch veilig?" zeker wel. Het is gewoon de "reputatie" die het gekregen heeft (in mijn hoofd ieder geval) doordat het is veilig steeds maar herhaalt wordt.

[Argantonis]

Het minnen gaat om de andere zin. Mensen domme developers noemen omdat ze menselijke fouten maken.

[JPtjeeNL]

Beetje alsof je bij een ongeluk met een moderne auto zegt ‘maar auto’s zijn toch veilig?’. Ik denk dat niemand heeft gezegd dat Rust geen kwetsbaarheden zal hebben.

[Stetsed]

Ja rust is veilig***

Rust is memory safe, dit betekent dat er geen vulnerabilities mogelijk moeten zijn(Kan well gebeuren door een bug in de compiler zoals we zagen in cve.rs) die voorkomen door memory misbruik. Dit zijn vulnerabilities zoals Use-After-Free, buffer overflows etc.

Dit betekent echter niet dat er geen foute in de logica van het programma kan zitten. Het kan nog zeker gebeuren dat ik niet check of een token valide is en dan data doorgeef, dit is memory safe maar is natuurlijk niet voor de applicatie veilig. Je praat hier dan dus ook over logic bugs. En ja die kan rust nog zeker hebben.

Maar dan moet je de vraag stellen welke bugs komen vaak voor, en volgens microsoft en google waren een substantieel hoeveelheid bugs memory gebaseerd. Nou betekent dit niet dat rust dan 100% veilig is, maar het betekent dus well dat het in bepaalde categorieren deze kan verminderen. Het is een riem, ja het maakt auto rijden niet compleet veilig, maar het helpt zeker well.

[84hannes]

Het is een riem, ja het maakt auto rijden niet compleet veilig, maar het helpt zeker well.

offtopic:
Ik dacht dat je ging zeggen dat een riem nooit volledig kan voorkomen dat je broek afzakt 😝. Ik noem dat ding een (veiligheids)gordel, vandaar de verwarring

Microsoft claimt dat 70% van de CVE's een memory-management probleem is.

[GertMenkel]

Los van het feit dat unsafe{} natuurlijk bestaat, is dit geen remote code execution in Rust zelf.

Het is een differentiatieaanval zoals die ook al gebruikt is tegen andere archiefcode en HTTP-proxies. Je voert dezelfde invoer aan twee programma's; eentje interpreteert het op een manier, de ander op een compleet andere manier. Als je eerste manier de securityscanner is van PyPi en de ander de Python-setup-tool, dan heb je dus een probleem.

In dit geval bestaat het risico dat je code die normaal in een "configuratie"-bestand terechtkomt, in een codebestand terechtkomt. Als je dat codebestand zonder het eerst te lezen uitvoert, kun je een virus oplopen.

Voor zover het de ononderhouden Rust-library betreft, is dit een bug die ervoor zorgt dat een bestand verkeerd wordt uitgepakt. Wat je verder met dat bestand doet, is wat het daadwerkelijke risico toevoegt. Alleen de .tar uitpakken gaat je computer nog niet hacken gelukkig!

[Pep7777]

Haha had ik het vandaag nog over... teveel mensen staren zich blind op de programmeertaal als het om veiligheid gaat. Dat moet al veel eerder beginnen met het design van je systeem, technologie (programmeer taal) alleen is nooit genoeg.

[84hannes]

alleen is nooit genoeg.

Klopt, je moet tegen meerdere verschillende aanvallen beschermen en daar zul je meerdere verschillende methodologien voor moeten gebruiken. Dat neemt niet weg dat memory-managementfouten een groot deel van het aantal CVE's is en je daarvan een groot deel kunt voorkomen door geen taal te gebruiken waarin dat handmatig werk is (c, in mindere mate c++).

[whale]

unsafe {

heel veilig idd :)

}

[Reactie gewijzigd door whale op 22 oktober 2025 16:44]

[jpsch]

Je moet het wel combineren met AI.

[undefined418]

Waarom `uv` als `pip` ingebouwd met Python komt? Dat is vragen om problemen.

[stuiterveer]

Pip is een afzonderlijk pakket en geen ingebouwd onderdeel van python. Kan zijn dat <insert linux-disto> het wel automatisch mee installeert, maar de aanwezigheid van python betekent niet per definitie de aanwezigheid van pip.

Los daarvan heb je vergelijkbare risico's bij het gebruik van pip: als een probleem zit in een veelgebruikte library krijg je ook daar het probleem. Dat is "gewoon" een algemeen probleem van hoe dergelijke package managers opereren.

[Reactie gewijzigd door stuiterveer op 22 oktober 2025 16:55]

[undefined418]

Usually, pip is automatically installed if you are:

• working in a virtual environment
• using Python downloaded from python.org
• using Python that has not been modified by a redistributor to remove ensurepip

Source https://pip.pypa.io/en/stable/installation/

Ongeacht of het een afzonderlijk pakket is, het komt dus altijd met Python.

[stuiterveer]

Je tekst begint al met "Usually", en toch interpreteer je dat zelf als "altijd". Nog altijd dus m'n punt: kan zijn dat <insert linux-disto> het wel automatisch mee installeert, maar de aanwezigheid van python betekent niet per definitie de aanwezigheid van pip.

Ik heb in de afgelopen jaren elke keer eerst expliciet pip moeten installeren binnen m'n distro voordat ik het kon gebruiken. Dan hebben we het over meerdere Debian versies en Ubuntu versies. Maar hey, laten we de proef op de som nemen.

Ik heb zojuist de laatste Debian iso (13.1 netinstall) gedownload, en heb een nieuwe installatie binnen een VM gedaan. Geen desktopomgeving geïnstalleerd, maar wel de optie "standard system utilities" geselecteerd gelaten tijdens installatie. Python3 was op die manier al voorgeïnstalleerd, maar zodra ik pip of pip3 probeer uit te voeren krijg ik mooi de melding "command not found" (screenshot als bewijs, maar voel je vrij om dezelfde stappen zelf uit te voeren).

Voldoende bewijs dus dat python installeren niet hetzelfde is als pip installeren.

[Reactie gewijzigd door stuiterveer op 22 oktober 2025 17:16]

[undefined418]

Als je Python installeert zonder pip op een unix omgeving (dus niet via Python.org), dan gebruik je dus `ensurepip`.

```
python -m ensurepip
```

Maar in jou geval omdat je debian 13 pakt kan je net zo goed het volgende doen
```
sudo apt install python3-pip -y
```

Verder hoef ik mezelf niet te bewijzen en ga ik verder tot de orde van de dag.

[Goderic]

Zo kan ik het ook:

```

python -m ensurepip

pip install uv
```

uv is 10-100 keer sneller dan pip, wat het verschil is tussen minuten wachten op een CI check enkel voor de setup en enkele seconden.

De Astral tools zijn echt fantastisch voor de Python wereld. ruff, uv en nu ook ty.

[cricque]

Maakt dit echt uit op moderne systemen ? Sorry maar gebruik al jaren pip het is toch niet dat je uren moet wachten. Ik herinner me nog in java in de jaren 90 als je ging compilen dan duurde dat lang en dan was er IBM die een andere tool had en seconden. Gingen we van minuten naar seconden. Maar ik heb nog nooit 5 minuten moeten wachten op pip. Enja time is money, ik heb mijn eigen bedrijf ... maar hoe dikwijls moet je nu alle libs installeren waar je gebruik van maakt. Die andere tools ken ik niet en nog nooit gebruikt, ik zie het nut er niet van in. Dat het sneller kan is leuk, maar eral live winst ... minimaal lijkt me. Het enige waar ik het nut voor zie is bij containers en als je telkens alles opnieuw wilt laten builden. Daar kan je wat winst mee maken, maar 30 seconden max ?

[stuiterveer]

Ik weet dat pip geïnstalleerd kan worden, dat was het hele punt niet. Het hele punt was of pip standaard in python gebouwd zit, en dat is niet het geval. Het is een afzonderlijk iets.

[jorikc]

omdat uv veel meer kan dan alleen pip en als je het alleen zou gebruiken als pip-vervanger, is ie alsnog veel sneller. Volgens Real Python kan JupyterLab bijvoorbeeld 10x zo snel geïnstalleerd worden: https://realpython.com/uv-vs-pip/

[undefined418]

Ik kan me heel goed voorstellen dat snelheid de overweging kan bieden om een andere package manager te gebruiken. Maar heel eerlijk, hoe vaak installeer je je environment (opnieuw)? Ik vaak maar 1 keer per project (mits alles goed gaat en blijft gaan). Dan loop ik wel een keertje naar het koffie automaat bij initialisatie van het project.

De nadruk ligt hem denk ik voornamelijk met wat voor projecten je bezig bent. Zo zie ik in mijn omgeving dat mensen die Data science doen ook vaak Conda gebruiken (waar ik ook de kriebels van krijg).

Quoting "The Zen of Python; There should be one-- and preferably only one --obvious way to do it. (Although that way may not be obvious at first unless you're Dutch)"

[Zarhrezz]

Ik zou het omdraaien; als je niet heel goed weet wat je doet en welke andere tools je daarbij nodig hebt, is pip gebruiken vragen om problemen.

Wat je voor een project wil, is "resolved and pinned" dependencies. Dat biedt pip niet. PEP 751 zal dit wellicht deels gaan bieden (i.e. pip install gebaseerd op een lockfile, zodat je zekerheid hebt dat wat je installeert precies is wat de bedoeling is) maar dat zal dan eerst door tools als uv en poetry ondersteund moeten gaan worden (wat ik wel verwacht, maar dat zal even tijd kosten).

Daarnaast forceert pip geen virtual environments; alles gaat default naar de global Python install. Convenient, maar verder een vrij slecht idee. Tools als uv en poetry dwingen de isolatie af, alleen door bewuste acties kun je installs naar de global interpreter doen.

Als iemand een requirements.txt heeft gegenereerd met (resolved) hashes (dus geen standaard pip freeze) en er een venv geactiveerd is, dan volstaat pip. Anders niet.

[enzozus]

Twee libraries die het niet eens kunnen worden over hoe ze een bewust misvormd bestand moeten interpreteren is echt super veel voorkomend.

De auteurs hebben op zich een redelijk verhaal verzonnen over hoe dit misbruikt kan worden maar het gezwaai met "remote code execution" vind ik toch een beetje absurd, het gaat om het potentieel bypassen van controles en malware scans.

Maar het komt allemaal uiteindelijk neer op "als je een malafide tarball met code van iemand die je niet vertrouwt gebruikt, kan je gehackt worden". Ach jee.

[kuurtjes]

Het is niet echt "remote" meer dan hé.

[telenut]

Het is me wel niet heel duidelijk hoe een aanvaller dit dan juist kan misbruiken.. Je moet al bijna in een systeem raken om het te kunnen misbruiken toch?

[kimborntobewild]

Wat is nu in zijn algemeenheid de meest basale oorzaak van dit en soortgelijke security blunders?

[aaronedam]

As of this commit, async-tar 0.5.1 should be safe.