The vulnerabilityįor signed packages, the TOC hash needs to be used for two different checks: For example, appending more data to a xar file will always keep the TOC hash and signature valid. Interestingly, this design does mean that data on the heap that is not included in any of the ranges can be modified without invalidating the signature. This signature therefore ensures the authenticity of all files in the archive.
The data used for generating the signature is the TOC hash. The signature itself is also stored on the heap (for the same cyclic dependency reason). 20 256 MIIFdjCCBF6gAwIBAgIQMJvx21UGMjp4U MIIEbDCCA1SgAwIBAgIQWqJHoRaQ3Cgu/ MIIEuzCCA6OgAwIBAgIBAjANBgkqhkiG9 To verify the integrity of the entire archive, the TOC also lists the location on the heap where a value known as the “TOC hash” is stored. 430 2533 654 c5c07ac6917dbbbacf1044700559dfff3c96ac26 bda75d4a4f97c71985cdb5d3350fea8a62bbad0e 0 T00:00:00 wheel 0 r16777241 33 file PackageInfo Įven xar files that are not signed have these hashes and so the integrity can be verified when extracting a file. Each file in the archive can be compressed independently by specifying an encoding, so when creating an archive file it is possible to choose the optimal way of storing each file.įor all files, a hash is included in the TOC of both the uncompressed and compressed data, using the hashing algorithm specified in the header. This document lists for each file included in the archive the start address and length where the contents can be found on the heap, starting with 0 for the first byte directly after the TOC. The TOC is a zlib-compressed XML document. The header contains a number of fields, including the hashing algorithm that is used throughout the file (typically still SHA1) and the size of the TOC.
The method for signing installer packages is the same as generating signed xar files, so to start we’ll explain how that file format works.Ī xar file consists of 3 parts: a fixed length header, a table of contents (TOC) and what is called the “heap”. Installer packages are based on xar files with a number of predefined file names. This vulnerability could be abused to bypass Gatekeeper, SIP and under certain conditions elevate privileges to root. During a short review of the xar source code, we found a vulnerability (CVE-2022-42841) that could be used to modify a signed installer package without invalidating its signature.
Besides signing applications, it is also possible to sign installer packages (.pkg files). Code signing of applications is an essential element of macOS security.
0 kommentar(er)
