Malformed unused device fields are accepted

[zaniebot]

Summary

TarReader accepts malformed devmajor and devminor fields even on an
ordinary regular member. The reproduction archive is rejected by
CPython tarfile and Go archive/tar; the other maintained peers accept it.

Tested at 1ac1199559a1b96f0f953ac99520ccc296503808.

Observed behavior

The two device fields contain XXXXXXXX and YYYYYYYY. Tar-codec treats them
as opaque and returns the regular member.

Expected behavior

Consider validating populated device fields consistently, or document that
unused device fields are deliberately ignored for non-device members.

Impact

This is an interoperability and validation-policy difference, not an extraction
vulnerability by itself.

[woodruffw]

Hmm, I think this is actually a Python bug: it looks like Python's tarfile is trying to parse devmajor and devminor as base-256 (which is wrong for pax to begin with, but that's another step), which then fails on those values. However, pax says:

Represent character special files and block special files respectively. In this case the devmajor and devminor fields shall contain information defining the device, the format of which is unspecified by this volume of POSIX.1-2024. Implementations may map the device specifications to their own local specification or may ignore the entry.

(That's when the member is actually a device.)

So TL;DR:

• If the member is a device, POSIX pax says that the format of devmajor and devminor is not specified. So Python should not attempt to parse these as numeric.
• If the member is not a device (which is the normal case), POSIX doesn't define their format at all (even negatively). So parsing as numeric is also incorrect in this case.

(I suspect the confusion with these fields is that GNU refers to them as "device numbers," but even so their format is not actually specified to be octal or base-256.)

(Go appears to reject for a similar reason.)