lack of security awareness

[jreiser]

I can find no concise documentation relating to the security awareness of this code. Delta .rpms often are part of a supply chain for software that should be resistant to tampering. What threats against integrity of results (or their efficient creation and consumption) have been considered, and what design strategies and implementation techniques have been used to counter, deter, or mitigate such threats?

One recent post on suspected security problem areas within the deltarpm package by Demi Marie Obenour on 2022-03-06:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/42I5IQEHRBLKUIB6KIHTE46RYTUVNPHU/

Specific items for makedeltarpm:

1. Diagnosis of incoming security state: Is each .rpm input file signed and verified? By a trusted key? By the same trusted key for both old and new .rpm? Any answer of "No" should be referred to a security policy subsystem, with command-line options for overriding the default of highest security, which requires an exit status of Failure (and no output file created) from makedeltarpm.
2. Is each input a S_IFREG file with (stat.n_links == 1)? A symlink often enables an easy tampering attack, and a hard link is by definition an alias that can be exploited.
3. Does the code lock each input file against writing for the duration of makedeltarpm?
4. Each datum that is read from an input file and then consumed by any operation except copying, should be considered suspect. In particular, embedded byte counts and the implied or explicit substring of an input file must be checked against the [remaining] byte length in the file. Also, probably any two such substrings must not overlap.
5. The recently-added command-line flag -m to limit memory usage must be a global limit that applies to peak memory usage for the entire duration of makedeltarpm, including all compression and de-compression subsystems. Also, either the same limit, or some other adjustable limit, must enable applydeltarpm to succeed.

[jreiser]

There is a related project https://github.com/rpm-software-management/deltarpm with pull requests (~4 months old) that fix bugs. The changes look OK and should be propagated here.

[mlschroe]

Deltarpm is a transport mechanism for a repository in 'repomd' format. The repository metadata is signed, and the downloader of the deltarpm has to make sure that it matches the sha256 checksum contained in the metadata. So the deltarpm content can be considered safe.

Makedeltarpm is not run on the consumer side at all, it is run at repo creation time and the input are two trusted rpms. So there's no attack surface as well.

There are 3 open pull requests in https://github.com/rpm-software-management/deltarpm and they are open since 23 days.

[DemiMarie]

Deltarpm is a transport mechanism for a repository in 'repomd' format. The repository metadata is signed, and the downloader of the deltarpm has to make sure that it matches the sha256 checksum contained in the metadata. So the deltarpm content can be considered safe.

Neither Fedora nor RHEL signs its repository metadata, so this assertion is false. The TLS to the server is not considered sufficient because anyone who compromised any of the hundreds of publicly-trusted CAs could perform a monster-in-the-middle attack.

[DemiMarie]

I recommend deprecating v1 and v2 deltarpms, and verifying the signature of v3 deltarpms before applying them. v3 deltarpms have their own signature header, and include the lead and signature header in the deltarpm payland, This means that they can be signed and deltarpm can check their signatures.

[mlschroe]

I recommend using a distribution that signs its repository metadata.

[DemiMarie]

I recommend using a distribution that signs its repository metadata.

Those are orthogonal concerns. DNF is expected to be secure even if repository metadata is not signed.