GHSA-j72g-pr5x-vf6p: 
Python vulnerability analysis and mitigation

Summary

A damaged zip attachment inside a mail file stops the whole run

Details

Details

MailVigil reads the attachments of a mail file in memory and gives them to the same reader as a loose file. That reader turns every failure of the standard library on a damaged archive into a typed refusal (not_an_archive), so a corrupt file costs one line in the list of skipped files and the run goes on. The list of errors it catches (_ARCHIVE_ERRORS in src/mailvigil/reports/reader.py) did not include the ValueError that zipfile raises when a zip read from memory is damaged near its start. A loose .zip file with the same damage raises BadZipFile instead, which was caught, so only the mail path was affected. The exception then crosses ingest, summary and verdict and ends the run with exit code 70 (internal error), with no report and no summary of the other files. With mailvigil fetch, the message stays in the folder, so every later run stops the same way until it is removed. This is the same promise that the XML limits of 1.1.2 protect: one bad file or attachment must never cost the run (spec 002, RF-09). The bug was found by property-based tests (Hypothesis) that damage valid archives and messages, a new kind of test added in the same release as the fix.

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: take a version <= 1.3.0, build a valid report zip, change or remove a few bytes at its start, attach it to a mail message saved as .eml (or put the message in an .mbox) and run mailvigil summary or mailvigil verdict on it. The run ends with exit code 70 and a message about an internal error. The same damage in a loose .zip file is reported as one skipped file. On 1.3.1 the attachment is refused as not_an_archive, listed in the skipped files, and the other reports are read as usual. The regression tests that ship with the fix (tests/test_properties.py and tests/test_reports_reader.py) hold the exact shapes and fail on the previous code.

Impact

A person who can get a crafted message into the mail the user feeds to MailVigil (an address that receives reports is public by design) can stop the tool from reading that folder: the person who runs it gets no summary and no verdict until the message is removed. It affects availability of the tool only. Nothing is disclosed, nothing is written and no code is executed. It needs the user to run MailVigil on a mail file or on a folder fetched from the mailbox. Workaround before the fix: move the offending message out of the folder (the error does not name it, so remove messages until the run succeeds), or read only loose .xml, .gz and .zip files.