tarfile: unbounded memory use on large pax and GNU extensions

[woodruffw]

Bug report

Bug description:

This is somewhat similar to #151497, and fits under the larger umbrella of #141713.

Summary

Both the pax and GNU tar families support extensions, via different mechanisms. These extensions have pre-declared lengths, and a tar parser must read a payload of length bytes to consume them.

Prior to #151497 this was done in a single read(n) call, resulting in a single large up-front allocation. That was changed to _safe_read with #151498, which bounds each read call to 1MB.

This prevents unbounded memory consumption at the read site, but not in aggregate. For example, an attacker can still contrive a pax-style tar archive with an extremely large individual pax record, and tarfile will buffer that pax record (in 1MB increments) into memory. The same is true for GNU extensions.

Solution

I think the solution is to put a reasonable caps on the sizes of extensions.

This could be done at a few different layers (e.g. restricting individual pax record sizes versus the entire pax extension size), but I think doing it at the extension size layer is probably simplest and most consistent.

My proposal would be:

1. No pax or GNU extension should ever exceed 1 MB in raw size (i.e., the size reported by its tar frame). This is extremely conservative, i.e. should be well above what any real-world tar would need to put in its extensions.
2. For pax in particular, the global pax extension state should never exceed some reasonable multiplier of the extension cap. For example, someone shouldn't be able to induce higher memory usage by chaining g -> g -> g -> ... -> file.txt, where each g member has 1MB of pax extension state.

For prior art, we perform this kind of bounding in tar-codec, e.g. here:

https://github.com/astral-sh/tar-codec/blob/dbd4b5efeb6edb732c993d107a7cfdc83f8d29a8/crates/tar-framing/src/stream.rs#L1099-L1154

and we impose a default cap of 256KB for pax extensions, 1MB for all active global pax extensions, and 128KB for GNU extensions:

https://github.com/astral-sh/tar-codec/blob/dbd4b5efeb6edb732c993d107a7cfdc83f8d29a8/crates/tar-framing/src/lib.rs#L124-L137

(These numbers are not particularly scientific; we picked them because we think even 256KB is very conservative i.e. high for pax, and 128KB for GNU is well beyond what any normal OS will accept as a pathname length limit.)

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

[woodruffw]

CC @zanieb

[woodruffw]

(NB: I mentioned _proc_pax and _proc_gnulong above, but I think _proc_sparse and other sparse file processing has a similar class of unbounded consumption behaviors.)