Test TUF (The Update Framework) criteria against Zypper and document it

[Nurmagoz]

Hi There,

I have searched the opensuse wiki and the forums for TUF but i couldnt find anything about it, can you test it against zypper and share the results? (maybe add it to your test suite as well)

TUF Criteria:

https://theupdateframework.io/docs/security/#attacks-and-weaknesses

ThX!

[jengelh]

• Arbitrary: .rpm files in openSUSE are GPG-signed. rpm checks and warns, zypper checks and rejects/interactively asks what to do.
  Metadata is equally GPG-signed, which zypper checks and rejects/asks what to do.
• Rollback: Triggering rollback needs some user input, i.e. the right command. zypper up is forward-only, zypper dup and zypper install --force is bidirectional.
• FFA: you can instruct zypper to keep downloaded packages, therefore giving yourself the possibility to rollback after a malicious v9999.
• IDF: outside the scope of zypper
• EDA: outside the scope of zypper
• MMA: outside the scope of zypper
• WSI: outside the scope of zypper
• MMPU: same class as IDF
• VKC: I don't recall zypper doing revocation checks. Part of the reason is that GPG public keyservers are rare (unfortunately so). TLS revocation, if any, is likely handled by system libraries and would thus be outside the scope of zypper.

[Nurmagoz]

Thank you for your reply.

It indeed misses a lot of important security methodologies. For example, in Debian, the Valid-Until field [1] [2] was introduced to mitigate replay or freeze attacks by setting an expiration date for metadata.

This study, conducted on the YaST package manager (before Zypper), shows that it suffers from replay/freeze attacks. Unfortunately, zypper didn’t resolve these issues either.

Attacks on Package Managers.pdf

So the question is: Will there be an implementation of TUF and real action taken to address issues "outside the scope of Zypper" or will it simply be ignored and yeah everything just fine?

[cboltz]

For example, in Debian, the Valid-Until field was introduced to mitigate replay or freeze attacks by setting an expiration date for metadata.

AFAIK we also have an expiration date somewhere in our metadata (I'd have to look up the details) - and I'm sure I've seen zypper rejecting outdated repos.

[jengelh]

There can be legitimate reasons to want to install old stuff, e.g. historic research (e.g. figuring out how many decades ago a particular feature was introduced, changed or repealed). So there will always be ways offered to users to render a system insecure, but that does not make the package manager insecure.

[mlandres]

Zypper informs about expired gpg-keys being used to sign the metadata, but we don't reject the repo. If you decide to install or inspect a discontiuned distro, you may do this.

Regarding the expiry of metadata themselves, this is up to the issuer. The (signed) metadata may contain a TTL field. But again zypper reports that the repo metadata may be outdated and suggests to check the mirror, but does not reject repo.

But adding a 'strict expiry checks' config option wouldn't be a big deal. Also reviewing the workflows.

Those workflows are implemented in libzypp, which is the underlying lib zypper, YAST and PK(zypp-backend) use. So basically all three should have similar abilities regarding the reports. And a strict mode option in zypp.conf would affect all three installers.

[bzeller]

Endless data attacks -> We have file sizes in our metadata, zypp will cancel downloads that exceed the expected filesize

[mlandres]

Regarding GPG checks (metadata and packages) we have several options explained in zypp.conf and the zypper man page.

Regarding Endless data attacks, downloads are also canceled if they exceed a timely limit. So you can not delay downloads ad infimum.

[mlandres]

This study, conducted on the YaST package manager (before Zypper), shows that it suffers from replay/freeze attacks. Unfortunately, zypper didn’t resolve these issues either.

Because it's IMO important: There is no before/after here. Regarding package management YAST is a GUI frontend and zypper a CLI towards libzypp. All Package/Repo/Media related actions and workflows are performed by libzypp.

[mlandres]

* EDA,MMA,WSI: outside the scope of zypper

IMO not, but it has a broader scope and zypp is just a piece in it.

We do not refer to files (sub-metadata or package-metadata) which are not secured by a chain of checksums originating at the master index. Whatever else is in the remote tree does not bother zypp.

If the issuer uses strong checksums and signs the master index, this part is mostly secure.

But zypp has no influence in how issuer and clien treat the repos. The client may enforce using only signed repos on his system. He has to explicitly allow repos to provide unsigned packages. But we also allow the client to turn it off.

AFAIK download.opensuse.org still delivers master index and it's signature on it's own and delegates only the remaining files to mirrors. But those are aspects actually out of zypps scope.

Stronger metadata protection on top of zypp (e.g. via blockchains) is possible via plugin. So there is a bunch of things we offer, but nothing we enforce.

VKC may actually be an issue. Especially if client systems are not connected to the internet. There's currently no way (through zypp or repo metadata) to revoke gpg keys. Maybe there are others. Actually something for the product security team.

[mlandres]

It indeed misses a lot of important security methodologies. For example, in Debian, the Valid-Until field [1] [2] was introduced to mitigate replay or freeze attacks by setting an expiration date for metadata.

This study, conducted on the YaST package manager (before Zypper), shows that it suffers from replay/freeze attacks. Unfortunately, zypper didn’t resolve these issues either.

        /**
         * Suggested expiration timestamp.
         *
         * Repositories can define an amount of time
         * they expire, with the generated timestamp as
         * the base point of time.
         *
         * Note that is the responsability of the repository
         * to freshen the generated timestamp to tell the
         * client that the repo is alive and updating the
         * metadata.
         *
         * The timestamp is 0 if the repository does not specify
         * an expiration date.
         *
         */
        Date suggestedExpirationTimestamp() const;

Well, it does not solely depend on zypp. Since 2008 we support an <expire> tag in the repo metadata which indicates how long the generated metadata should be considered to be valid. After that, we issue a warning that the repo appears to be outdated (maybe discontinued or a bad mirror).

The flag is an extension to yum's repodata/repomd.xml and opensuse repos usually ship it in their suseinfo.xml (like https://download.opensuse.org/update/leap/15.6/oss/repodata/). If native rpmmd upstream would support a similar flag, we'd add support for this too.

So replay/freeze depends on whether the metadata issuer supplies the data or not.

[jengelh]

Endless data attacks -> We have file sizes in our metadata, zypp will cancel downloads that exceed the expected filesize

and the metadata is signed, which is already covered by another point. So I interpret EDA as "what if there is signed endless (meta)data", which is a whole other level.

[cboltz]

and the metadata is signed, which is already covered by another point. So I interpret EDA as "what if there is signed endless (meta)data", which is a whole other level.

Playing devil's advocate: There is one file that is not signed: the metadata signature (repomd.xml.asc) ;-) While this is an obvious statement - are there any checks in libzypp that prevents downloading a 10 GB metadata signature? If not, it might be a good idea to add some limits.

[bmwiedemann]

The repomd.xml needs a similar limit, because having the .asc probably does not tell you its size.

[mlandres]

There's a 20MB limit for files without size (repomd.xml,.key,.asc or media.N/media)