Virusscanner ClamAV kwetsbaar voor aanval met zip-bom
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.
Is er geen sprake van een manipulatie aan het bestand zodat de filesystems over hun nek gaan?
Er zijn twee elementen: meer diepte en breedte. Het is niet zo eenvoudig om een combinatie daarvan te herkennen als een ZIP bom.
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.
No sh*t, Sherlock ;-)
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.
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
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)
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.
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. ;-)
Deze posting is gelocked. Reageren is niet meer mogelijk.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
