GHSA-w7fh-vvfp-fggg: 
Python vulnerability analysis and mitigation

Summary

pyHanko 0.38.0, the latest release, loops forever in pyhanko/pdf_utils/xref.py (parse_xref_table) on a 56-byte PDF whose xref table ends early. An application that opens an untrusted PDF with PdfFileReader, for example to validate its signature, can be made to spin a CPU core until it is killed. Both strict=True and strict=False hang.

Details

The table declares two entries but holds one. Cause: the loop that skips a CR or LF at the start of an entry,

    while line[0] in b"\x0d\x0a":
        stream.seek(-20 + 1, os.SEEK_CUR)
        line = stream.read(20)

assumes each read returns 20 bytes. When fewer than 20 bytes are left, read(20) stops at the end of the file and the seek lands 19 bytes before the end every time. If that byte is a CR or LF, the same short line is read forever. pypdf had the same loop (both inherited it from PyPDF2) and fixed it in 6.20.0 after I reported it as py-pdf/pypdf#4169. The same check fixes pyHanko: with it, the file above raises PdfReadError in both modes, and our tests with genuinely signed files still pass. Found it by fuzzing (atheris).

Proof of concept

Reproducer (Python 3.13):

    import io
    from pyhanko.pdf_utils.reader import PdfFileReader
    data = (
        b"%PDF-1.7\n"
        b"xref\n0 2\n0000000000 65535 f \n"
        b"\nstartxref\n9\n%%EOF"
    )
    PdfFileReader(io.BytesIO(data), strict=False)  # never returns

Impact

An application that opens an untrusted PDF with PdfFileReader, for example to validate its signature, can be made to spin a CPU core until it is killed.