oletools - python tools to analyze MS OLE2 files (Structured Storage, Compound File Binary Format) and MS Office documents, for malware analysis, forensics and debugging.
Describe the bug
Packaging a flat zipbomb inside an OOXML file will impact the iter_xml function used by oleid, oleobj and msodde slowing down the parsing almost to an halt (although turning your laptop into a cozy heating system). May not be so much zipbomb related as much as just "feeding a huge file into the xml parser" related.
unzip an OOXML (e.g. agenttesla.xlsx) into unzipped_oxml (agenttesla_xlsx/)
rezip it while adding the bomb using python3 zip-bomb.py -d agenttesla_xlsx/ flat 4096 agenttesla_flat_zipbomb.xlsx
How To Reproduce the bug
Run either oleid, oleobj, msodde on the sample and wait. Then keep waiting.
Expected behavior
Tool is running rather than stuck.
Console output / Screenshots
When doing a keyboard interruption, the stacktrace will always point out towards the iter_xml function (with different stacktrace start depending on the tool used).
^CTraceback (most recent call last):
File "/usr/local/bin/oleid", line 8, in <module>
sys.exit(main())
File "/usr/local/lib/python3.8/site-packages/oletools/oleid.py", line 540, in main
indicators = oleid.check()
File "/usr/local/lib/python3.8/site-packages/oletools/oleid.py", line 300, in check
self.check_external_relationships()
File "/usr/local/lib/python3.8/site-packages/oletools/oleid.py", line 380, in check_external_relationships
for rel_type, target in oleobj.find_external_relationships(xmlparser):
File "/usr/local/lib/python3.8/site-packages/oletools/oleobj.py", line 809, in find_external_relationships
for _, elem, _ in xml_parser.iter_xml(None, False, OOXML_RELATIONSHIP_TAG):
File "/usr/local/lib/python3.8/site-packages/oletools/ooxml.py", line 556, in iter_xml
for event, elem in ET.iterparse(handle, events):
File "/usr/local/lib/python3.8/xml/etree/ElementTree.py", line 1232, in iterator
pullparser.feed(data)
File "/usr/local/lib/python3.8/xml/etree/ElementTree.py", line 1274, in feed
self._parser.feed(data)
KeyboardInterrupt
Version information:
OS: Linux
Python version: 3
oletools version: latest
Additional context
The issue is not raised by the nested approach to zipbomb, at least the one in use in https://github.com/damianrusinek/zip-bomb/ , probably due to the issue being around feeding a huge file into the XML parser (so actually, you may not even require a zipbomb technically, just a huge file ?).
Affected tool: oleid, oleobj, msodde
Describe the bug Packaging a flat zipbomb inside an OOXML file will impact the
iter_xmlfunction used byoleid,oleobjandmsoddeslowing down the parsing almost to an halt (although turning your laptop into a cozy heating system). May not be so much zipbomb related as much as just "feeding a huge file into the xml parser" related.File/Malware sample to reproduce the bug Used https://github.com/damianrusinek/zip-bomb/ to produce a quick PoC following this logic:
agenttesla.xlsx) into unzipped_oxml (agenttesla_xlsx/)python3 zip-bomb.py -d agenttesla_xlsx/ flat 4096 agenttesla_flat_zipbomb.xlsxHow To Reproduce the bug Run either oleid, oleobj, msodde on the sample and wait. Then keep waiting.
Expected behavior Tool is running rather than stuck.
Console output / Screenshots When doing a keyboard interruption, the stacktrace will always point out towards the
iter_xmlfunction (with different stacktrace start depending on the tool used).Version information:
Additional context The issue is not raised by the nested approach to zipbomb, at least the one in use in https://github.com/damianrusinek/zip-bomb/ , probably due to the issue being around feeding a huge file into the XML parser (so actually, you may not even require a zipbomb technically, just a huge file ?).