image

Virusscanner ClamAV kwetsbaar voor aanval met zip-bom

dinsdag 6 augustus 2019, 13:34 door Redactie, 11 reacties

De populaire gratis opensourcevirusscanner ClamAV is kwetsbaar voor aanvallen met een zogeheten "zip-bom", waardoor een aanvaller servers onbruikbaar kan maken. Een zip-bom is een klein gecomprimeerd archiefbestand dat uitgepakt enorm veel ruimte in beslag neemt.

Onlangs demonstreerde onderzoeker David Fifield een nieuw soort zip-bom waarbij een gecomprimeerd bestand van 42kb uitgepakt 5 gigabyte groot is. Met een bestand van 10MB lukte het Fifield zelf om tot 281TB te komen. Veel virusscanners, waaronder ook ClamAV, scannen automatisch de inhoud van gecomprimeerde bestanden, die hiervoor tijdelijk worden uitgepakt. In het geval van een zip-bom kan dit het systeem ernstig belasten.

"ClamAV wordt vaak gebruikt om automatisch inkomende e-mails op mailservers te scannen. In dit geval kan het een effectieve manier zijn om een server onbruikbaar te maken", zegt onderzoeker Hanno Böck. In het geval van ClamAV zorgt het stoppen van het scanproces er niet voor dat de cpu-pieken in de ClamAV-daemon stoppen en het is niet mogelijk om de daemon netjes uit te schakelen, aldus Böck.

ClamAV heeft inmiddels een update uitgebracht om de kwetsbaarheid te verhelpen. Fifield laat echter weten dat de patch niet volledig is en met een variatie van zijn zip-bom is te omzeilen. Een mogelijke oplossing om denial of service-aanvallen op servers te voorkomen is het niet scannen van archiefbestanden, maar dit heeft weer als nadeel dat gecomprimeerde bestanden niet worden gecontroleerd, merkt Böck op.

Reacties (11)
06-08-2019, 15:23 door Anoniem
Een depth limiet instellen? Dan kan je na x aantal archieven in archieven het archief bestempelen als een zipbom.
06-08-2019, 16:46 door Anoniem
Op welke manier kan een bestandje van 42 kb bij het uitpakken uitkomen op een bestand van 5 GB groot?
Is er geen sprake van een manipulatie aan het bestand zodat de filesystems over hun nek gaan?
06-08-2019, 18:00 door Anoniem
Door Anoniem: Een depth limiet instellen? Dan kan je na x aantal archieven in archieven het archief bestempelen als een zipbom.

Er zijn twee elementen: meer diepte en breedte. Het is niet zo eenvoudig om een combinatie daarvan te herkennen als een ZIP bom.
06-08-2019, 18:32 door Anoniem
Dit is niet nieuw...
Ik weet nog wel uit een grijs verleden dat je dit met een LZH file (LHARC) nog veel beter kon doen dan met ZIP.
Als je een file met tig gigabyte aan nullen comprimeert tot LZH dan blijven er maar een paar bytes over.
(ik denk dat een van de compressiecodes iets doet als "nu volgt er X keer het byte Y")
Altijd leuk om dat soort bestandjes op toegankelijke plekken neer te zetten, liefst met een aantrekkelijke naam, en
dan te zien hoe mensen hun disk ineens vol zien worden.
06-08-2019, 19:43 door Anoniem
Een mogelijke oplossing om denial of service-aanvallen op servers te voorkomen is het niet scannen van archiefbestanden, maar dit heeft weer als nadeel dat gecomprimeerde bestanden niet worden gecontroleerd, merkt Böck op.

No sh*t, Sherlock ;-)
06-08-2019, 20:22 door Anoniem
Door Anoniem: Op welke manier kan een bestandje van 42 kb bij het uitpakken uitkomen op een bestand van 5 GB groot? Is er geen sprake van een manipulatie aan het bestand zodat de filesystems over hun nek gaan?
That's right!
The theoretical maximum compression factor for a raw DEFLATE stream is about 1032 to one,

but by exploiting the ZIP format in unintended ways, ZIP archives with compression ratios of billions to one can be constructed. These "zip bomb"s unzip to extremely large sizes overwhelming the capacity of the computer it is running on.
[bron: https://en.wikipedia.org/wiki/ZIP_(file_format)]
06-08-2019, 20:50 door Anoniem
Door Anoniem: Op welke manier kan een bestandje van 42 kb bij het uitpakken uitkomen op een bestand van 5 GB groot?
Is er geen sprake van een manipulatie aan het bestand zodat de filesystems over hun nek gaan?

Compressie werkt o.a. door identieke blokken maar 1 x op te slaan en de lokaties te weten. Dus als je een 5G bestanden hebt met alleen maar *-jes erin, dan kun je dat comprimeren door te zeggen "5Gx*", en de unzipper dat weer laten omzetten naar het bestand van 5G
06-08-2019, 23:19 door Anoniem
Ik begrijp niet dat er niet gewoon een geheugen limiet gebruikt wordt. Groter dan x, kill. Eind van het probleem.
07-08-2019, 09:26 door Anoniem
In principe zou het wel mogelijk zijn om een "on-the-fly" unzip en scan programma te maken, door bijvoorbeeld de
unpacked data niet naar een file te laten schrijven maar naar een pipe, waar dan aan de andere kant de scanner
de data leest. Je bent dan niet begrensd door diskruimte, maar je kunt evengoed rottigheid uithalen door een idioot
groot bestand gezipt te sturen wat dan heel lang duurt (en heel veel CPU kost) om te scannen.

En uiteraard moet die oplossing ook recursief werken, dwz als de unpacked output weer een zipfile of andere compressed
file is dan gaat die pipe naar een nieuwe instance van dezelfde unpacker ipv direct naar de scanner, zodat er een
ketting ontstaat van unpackers die on-the-fly de data verwerken. En daar moet natuurlijk ook een limiet op zitten om
te voorkomen dat iemand een 100000 levels diep geneste zipfile kan sturen en de hele machine volstoppen met
unpacking processen. (echter zo'n limiet zit er nu ook al op)
07-08-2019, 23:15 door Anoniem
@23:19 door Anoniem

Ja, dat is een manier, maar je wilt niet weten hoeveel groter een normale gecomprimeerd bestand al niet kan worden. Als er iemand een setup van een programma opstuurt, dan is de hoeveel data al snel vele (soms tientallen) malen groter dan de omvang van de bron. Je hebt dus al snel last van false positives.

cpu-tijd meten is ook een optie.

@09:26 door Anoniem

Het is niet nodig om alle data te bewaren. Je kunt sequentieel uitpakken en de output buffer hergebruiken. Het ZIP formaat vermeldt de uitgepakte hoeveel data in meta gegevens. Het probleem is met name dat je tijdens het uitpakken al moet weten wat je aan het doen bent. De meta data hoeft niet overeen te stemmen met de werkelijkheid. Je kunt zelfs de crc32 checksum correct voorspellen en de omvang faken.
08-08-2019, 16:11 door Anoniem
Ik ben eerder geneigd om geen limiet in te voeren, maar te laten kijken naar de compression ratio.
Vanaf een beppaalde ratio wordt het natuurlijk absurd en helemaal niet meer plausibel en dan laten we het gecomprimeerde bestaand gewoonweg niet door.

Tenzij er natuurlijk gebruik wordt gemaakt van de compressietechniek van Jan Sloot. ;-)
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.