GHSA-wrrw-x2x3-vvp7: 
Python Analyse et atténuation de la vulnérabilité

Summary

Some report files that MailVigil cannot read end the whole summary or verdict run with an internal error instead of being listed as skipped, one of them makes the rest of an .mbox unread, and nothing limits the memory a run of many small compressed reports takes. Anyone who can send mail to the domain's DMARC report address can deliver such a file. Nothing is disclosed and nothing is executed.

Details

This is the same kind of problem as GHSA-j72g-pr5x-vf6p, in parts that fix did not reach.

1. Compressed zip members (reports/reader.py, _ARCHIVE_ERRORS). A zip member compressed with a method other than stored or deflate raises errors of its decompressor that are not in the list, and the LZMA decoder reserves the memory its header asks for before the 5 MiB cap (MAX_BYTES) counts a single byte.
2. The XML declaration (reports/xmlsafe.py). An encoding the XML parser cannot use raises an error that is not an ExpatError, so the refusal path is skipped.
3. Mail headers (reports/mail.py, _MESSAGE_ERRORS). The size of one header is not limited, and the cost of the standard library's header parser grows faster than the header; a deeply nested header also raises RecursionError, which is not in the list.
4. Mailboxes (reports/ingest.py). An error raised while reading one attachment of an .mbox message was taken as the whole mailbox being unreadable, so every later message was not read, with one skipped line as the only sign.
5. The whole run. The caps (MAX_BYTES, MAX_ELEMENTS) are per document; nothing bounds a run. Each compressed report expands to up to 5 MiB of XML whose records stay in memory, so many small mails add up to gigabytes. The observable effect of items 1 to 3 is internal error with exit code 70, no summary or verdict, and no file named, so the folder cannot be read until the file is found by hand. Item 4 leaves reports out of the summary and the verdict. Item 5 exhausts memory. Not affected: nothing from the machine is disclosed, nothing from a report is executed, no file is written, mailvigil fetch itself is not affected, and none of these errors makes verdict answer "ready".

Proof of concept

No exploit input is published with this advisory, on purpose: the affected code is public, and the fix is the reference. How to verify without an exploit: read a folder that holds, next to valid reports, a zip report whose member uses LZMA or bzip2 compression, an XML report whose declaration names an encoding the parser does not support, or a mail whose Content-Type header is unusually long; and an .mbox where a message with such an attachment comes before valid reports. On 1.7.0 the run ends with an internal error, or the reports after that message are missing. On the patched version each file is listed as skipped with its reason (not_an_archive, malformed_xml, message_too_complex), the mailbox is read to its end, and a run past 1,000,000 records stops with a message and exit code 1 instead of growing without limit. The regression tests that ship with the fix (in tests/test_reports_reader.py, tests/test_reports_xmlsafe.py, tests/test_reports_mail.py, tests/test_reports_ingest.py, tests/test_reports_ingest_many.py and tests/test_cli_exit_codes.py) fail on the previous code and pass on the fixed one.

Impact

Anyone who runs mailvigil summary or verdict over reports that arrive by mail, which is the normal use: the report address is public in DNS, so anyone can send to it. The run loses availability (no answer, or memory exhaustion), and in the mailbox case the answer is computed on fewer reports than were received. Nothing is disclosed and nothing is executed. Patches: fixed in 1.7.1. Workaround before the fix: when a run ends with an internal error, split the folder to find and remove the file, and run MailVigil under a memory limit when the report address receives mail from unknown senders.