A Heap Buffer Overflow issue takes place at from_header() in list.c in the tar application. The issue occurs when attempting to read files with old V7 tar format with an especially crafted checksum. As a result, an invalid memory read that leads to a conditional jump or move operation on uninitialised memory values takes place. Reference: https://savannah.gnu.org/bugs/?62387
Created tar tracking bugs for this issue: Affects: fedora-all [bug 2149724]
I created and submitted a patch to upstream. https://savannah.gnu.org/patch/?10307
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2023:0842 https://access.redhat.com/errata/RHSA-2023:0842
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2023:0959 https://access.redhat.com/errata/RHSA-2023:0959
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2022-48303
Hello Matej, our evaluating lab pointed this CVE out as part of the Vulnerability Assessment report for RHEL 9.0 Common Criteria certification. They note that https://access.redhat.com/security/cve/CVE-2022-48303 and https://savannah.gnu.org/bugs/?62387 seem to be discussing a flaw about a checksum, not mtime which is what https://savannah.gnu.org/patch/?10307 deals with. Could you please confirm that the upstream patch https://savannah.gnu.org/patch/?10307 is indeed a fix for this CVE an that the checksum / mtime difference is just about describing the problem and solution at different level and not talking about completely different things? Thank you, Jan
Hi Jan, Matej actually used the upstream's commit (https://git.savannah.gnu.org/cgit/tar.git/commit/?id=3da78400eafcccb97e2f2fd4b227ea40d794ede8) in our package (https://gitlab.com/redhat/centos-stream/rpms/tar/-/commit/3f1e688b3212d1911e2de8ac97918ab6d432a174). Or are you asking about something else?
My question was: is this patch really fixing the checksum issue that the CVE is about? Or does it fix the mtime issue? Or are those actually the same?
I wasn't working on the patch Matej proposed, so we'll have to wait for his response. However, I just checked the valgrind output of the reproducer and it fixes the buffer overflow issue: ``` ==4496== Memcheck, a memory error detector ==4496== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==4496== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info ==4496== Command: tar -xf vuln.tar -O ==4496== tar: Archive contains ‘\0\f\f\f\f\f\f\f\f\f\f\200’ where numeric time_t value expected tar: Archive value -1 is out of uid_t range 0..4294967295 tar: Archive contains ‘\371\361\361\367\361\377\377\377’ where numeric gid_t value expected tar: Exiting with failure status due to previous errors ==4496== ==4496== HEAP SUMMARY: ==4496== in use at exit: 4,136 bytes in 3 blocks ==4496== total heap usage: 469 allocs, 466 frees, 57,640 bytes allocated ==4496== ==4496== LEAK SUMMARY: ==4496== definitely lost: 0 bytes in 0 blocks ==4496== indirectly lost: 0 bytes in 0 blocks ==4496== possibly lost: 0 bytes in 0 blocks ==4496== still reachable: 4,136 bytes in 3 blocks ==4496== suppressed: 0 bytes in 0 blocks ==4496== Rerun with --leak-check=full to see details of leaked memory ==4496== ==4496== For lists of detected and suppressed errors, rerun with: -s ==4496== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ```
(In reply to Jan Pazdziora from comment #10) > My question was: is this patch really fixing the checksum issue that the CVE > is about? Or does it fix the mtime issue? Or are those actually the same? They are actually the same. Tar header consists of numerous values [1]. Some of those values can be specified in various formats, eg. the mtime can be in base-64 format, base-256, ... In this case the bug was in parsing the base-256 format of date. If the 12 byte long mtime header field was set to a value consisting of 11 whitespaces (or '\0' and 10 whitespaces) followed by 0xff or 0x80 byte, heap buffer overflow occured - one byte from the next field (chksum) was read and a jump depended on it. [1] https://www.gnu.org/software/tar/manual/html_node/Standard.html
Thanks for the explanation.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Extended Update Support Via RHSA-2023:5610 https://access.redhat.com/errata/RHSA-2023:5610