apt/apt-pkg/contrib, branch 2.1.18

CVE-2020-27350: tarfile: integer overflow: Limit tar items to 128 GiB

2020-12-09T16:30:43Z

The integer overflow was detected by DonKult who added a check like this: (std::numeric_limits::max() - (2 * sizeof(Block))) Which deals with the code as is, but also still is a fairly big limit, and could become fragile if we change the code. Let's limit our file sizes to 128 GiB, which should be sufficient for everyone. Original comment by DonKult: The code assumes that it can add sizeof(Block)-1 to the size of the item later on, but if we are close to a 64bit overflow this is not possible. Fixing this seems too complex compared to just ensuring there is enough room left given that we will have a lot more problems the moment we will be acting on files that large as if the item is that large, the (valid) tar including it probably doesn't fit in 64bit either.

tarfile: OOM hardening: Limit size of long names/links to 1 MiB

2020-12-09T16:30:43Z

Tarballs have long names and long link targets structured by a special tar header with a GNU extension followed by the actual content (padded to 512 bytes). Essentially, think of a name as a special kind of file. The limit of a file size in a header is 12 bytes, aka 10**12 or 1 TB. While this works OK-ish for file content that we stream to extractors, we need to copy file names into memory, and this opens us up to an OOM DoS attack. Limit the file name size to 1 MiB, as libarchive does, to make things safer.

CVE-2020-27350: arfile: Integer overflow in parsing

2020-12-09T16:30:43Z

GHSL-2020-169: This first hunk adds a check that we have more files left to read in the file than the size of the member, ensuring that (a) the number is not negative, which caused the crash here and (b) ensures that we similarly avoid other issues with trying to read too much data. GHSL-2020-168: Long file names are encoded by a special marker in the filename and then the real filename is part of what is normally the data. We did not check that the length of the file name is within the length of the member, which means that we got a overflow later when subtracting the length from the member size to get the remaining member size. The file createdeb-lp1899193.cc was provided by GitHub Security Lab and reformatted using apt coding style for inclusion in the test case, both of these issues have an automated test case in test/integration/test-ubuntu-bug-1899193-security-issues. LP: #1899193

HexDigest: Silence -Wstringop-overflow

2020-12-04T22:16:04Z

The compiler does not know that the size is small and thinks we might be doing a stack buffer overflow of the vla: Add APT_ASSUME macro and silence -Wstringop-overflow in HexDigest() The compiler does not know that the size of a hash is at most 512 bit, so tell it that it is. ../apt-pkg/contrib/hashes.cc: In function ‘std::string HexDigest(gcry_md_hd_t, int)’: ../apt-pkg/contrib/hashes.cc:415:21: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 415 | Result[(Size)*2] = 0; | ~~~~~~~~~~~~~~~~~^~~ ../apt-pkg/contrib/hashes.cc:414:9: note: at offset [-9223372036854775808, 9223372036854775807] to an object with size at most 4294967295 declared here 414 | char Result[((Size)*2) + 1]; | ^~~~~~ Fix this by adding a simple assertion. This generates an extra two instructions in the normal code path, so it's not exactly super costly.

Merge branch 'pu/less-slaves' into 'master'

2020-08-04T10:12:30Z

Remove master/slave terminology See merge request apt-team/apt!124

Replace whitelist/blacklist with allowlist/denylist

2020-08-04T10:12:11Z

Merge branch 'pu/apt-key-deprecated' into 'master'

2020-08-04T10:07:10Z

Fully deprecate apt-key, schedule removal for Q2/2022 See merge request apt-team/apt!119

Reorder config check before result looping for SRV parsing debug

2020-07-02T16:57:11Z

It isn't needed to iterate over all results if we will be doing nothing anyhow as it isn't that common to have that debug option enabled.

Skip reading data from tar members if nobody will look at it

2020-05-18T13:55:36Z

The variable this is read to is named Junk and that it is for usecases like apt-ftparchive which just looks at the items metadata, so instead of performing this hunked read for data nobody will process we just tell our FileFd to skip ahead (Internally it might still loop over the data depending on which compressor is involved).

Properly handle interrupted write() call in ExtractTar

2020-05-18T13:55:36Z

With FileFd::Write we already have a helper for this situation we can just make use of here instead of hoping for the best or rolling our own solution here.