On Tuesday, February 9, 2021 7:41 PM, Jake Shipton listmail@crazylinuxnerd.net wrote:

On Wed, 2021-02-10 at 06:48 +1000, Chris Drake wrote:

...

Your Wkii page here: https://wiki.centos.org/FAQ/CentOSStream#Where_is_the_source_code.3F After discussion in which it was confirmed that TLS could be implemented "but traditionally we have not done so", was just updated by Manuel Wolfshant with the following lie:- Note: downloads are hosted on a mirror network, where we cannot mandate that every mirror node runs SSL/TLS, hence using regular http and not enforcing httpsFalse statements are disgusting to begin with, but ones that attempt to excuse the lazy decision to put all CentOS customers at risk are totally unacceptable.  LE is free and easy to use and setup - it's a no- brainer to fix this problem, assuming someone isn't getting a kickback from some 3-letter-agency to leave this exploitable security hole open ?

CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

Well..

Technically CentOS users are not customers - at all in fact - unless they also happen to also own a paid RHEL subscription.

Now onto the issue at hand. While the info should be accurate, I don't think it's a big deal.

TLS is certainly preferable for the mirror network, it isn't entirely required from a security point of view.

Realistically TLS shines most when you're transporting customer (user data) or are dealing with some kind of sensitive information, trying to stop prying eyes etc.

From a mirror perspective it's not overly important because the only protection TLS can add in this case is to prevent RPM tampering. But even if someone intercepted your connection and successfully switched the RPM while it was downloading the risk is minimal.

This is because your local machine has the GPG key identity required for the packages. All CentOS (and most RPM distros) sign their packages with a GPG key, which package managers then use to verify the RPM has not been tampered with.

That's why if you want to install a non-GPG signed package from a repo you need to specifically tell yum/dnf to ignore GPG signing.

So, TLS or not, if your package has been swapped with a fake, your package manager should notice this and refuse to install that package.

The biggest problem from a security point of view would probably be a rogue mirror that serves up modified packages.. a rogue mirror could also carry TLS.

That's why you sign the RPM for security.

If you're worried that someone sees the package your about to install, just remember two things:

1. Mirrors are public, everyone can easily know what packages and their versions exist.

2. If there's an exploitable package just waiting to be installed for an easy exploit.. whoever has that exploit will probably be randomly probing systems for it - they won't need to monitor a mirrors downloads..

   This of course is all my quick and short personal opinion, I don't work for Red Net. I reserve the right to be dead wrong.

   Just my 3c.

I agree that TLS is being oversold as being a security benefit in this situation.

As long as we are being pedantic about repository security, my person observation is the best point of attack is the repo XML files. These are not signed. If a rogue mirror or a man in the middle attack did take place, this seems like the best target. From what I can tell, DNF (and libxml2) typically are parsing these files while running as root. A zero-day against libxml2 would be gold.

I would not go as far as to indicate this proves anyone has been lazy. Red Hat has been responsive to patching libxml2 as soon as they become aware of problems. But it would be nice if this was handled better.

What excites me about Stream is the potential to push security enhancements forward sooner than just contributing into Fedora does. We may be able to backport important changes into Stream that the RHEL team may not have taken the time to in the past.

Maybe someday we will see a pull request to createrepo to support adding a signature element towards the top of the XML file. And then another pull request for dnf to perform signature checking before xml parsing, preferably running in an unpriviledged/sandboxed way when possible.

Normally even after the pull requests have proven themselves in Fedora for a while we would have to wait for the next RHEL cycle to see the changes in RHEL itself. But I think Stream may give hope of getting something like "gpgcheckxml" for dnf into a Technology Preview for Stream/RHEL 8.

Right now it is still unclear to what degree we will just be mere consumers of Stream or how much we will be drivers of the roadmap. It seems like in the short term we might have to purpose a dnf-NG SIG group instead of being able to contribute back directly. But even that would be an improvement over how things worked in the past.

On Tuesday, February 9, 2021 8:58 PM, John R. Dennison jrd@gerdesas.com wrote:

On Wed, Feb 10, 2021 at 02:42:35AM +0000, redbaronbrowser via CentOS-devel wrote:

...

As long as we are being pedantic about repository security, my person observation is the best point of attack is the repo XML files. These are not signed. If a rogue mirror or a man in the middle attack did take place, this seems like the best target. From what I can tell, DNF (and libxml2) typically are parsing these files while running as root. A zero-day against libxml2 would be gold.

Repo metadata is signed.

From what I can tell, the repo metadata is hashed by sha256 but that is not the same a cryptographically signed.

What are you finding is performing a verification of the repomd.xml against the CentOS public key before parsing it with libxml2?

On Wed, Feb 10, 2021 at 10:20:19AM +0100, Peter Meier wrote:

Now if we look at what Fedora does (e.g. for EPEL):

curl -s "https://mirrors.fedoraproject.org/metalink?repo=epel-source-8&arch=x86_6..." | grep protocol= | sed 's/.*protocol="(.*)" type=.*/\1/' | sort | uniq -c 64 http 36 https 50 rsync

If you add '&protocol=https' you will only get https mirrors from that Fedora link.

Adrian

On Wednesday, February 10, 2021 7:32 AM, Leon Fauster via CentOS-devel centos-devel@centos.org wrote:

Am 10.02.21 um 10:20 schrieb Peter Meier:

...

However, I guess since things are intervened with Fedora and Fedora also has:

1. repo_gpgcheck not enabled by default :(

I had asked this before. JFYI:

https://bugzilla.redhat.com/show_bug.cgi?id=1851242

...

2. a mixed list of http, https and rsync mirrors
3. no way on dnf (afaik) to prefer https

it's probably a good starting point over there.

That bugzilla thread has an interesting point, EPEL is using a metalink delivered over https to provide the size and hashsums of the repomd.xml.

CentOS differs from EPEL in the following ways:

1. CentOS delivers mirrorlist instead of metalink

2. CentOS delivers mirrorlist over http by default instead of https

While EPEL mirroring has some of the same challages as CentOS, they seem to have handled it in a cleaner way.

It is true that not all mirrors are TLS enabled.

But "mirrorlist.centos.org" is under CentOS direct control. Also, the centos-linux-repos is authored by CentOS.

It should be possible for CentOS to respond to this request by updating the centos-linux-repos to use https for the mirrorlist and enable repo_gpgcheck by default.

It would also be nice if migration to using metalink instead of mirrorlist was a goal of the CentOS infrastructure team.

On Wednesday, February 10, 2021 9:51 AM, Leon Fauster via CentOS-devel centos-devel@centos.org wrote:

Am 10.02.21 um 16:36 schrieb redbaronbrowser:

...

But "mirrorlist.centos.org" is under CentOS direct control. Also, the centos-linux-repos is authored by CentOS.

I am not part of the CentOS team therefore "non-authoritative answer".

I was also subject to this assumption, but if I have understood it correctly "mirrorlist.centos.org" is glued together with sponsored/community donated machines. So, not in the realm of CentOS.

Just do:

$ dig +short -t A mirrorlist.centos.org

Maybe it is time to establish a metalink.centos.org that is behind a CDN such as cloudflare.

Migrating to repo_gpgcheck for the centos-linux-repos package would be nice to.

Am 10.02.21 um 02:41 schrieb Jake Shipton:

On Wed, 2021-02-10 at 06:48 +1000, Chris Drake wrote:

...

Your Wkii page here:

https://wiki.centos.org/FAQ/CentOSStream#Where_is_the_source_code.3F

After discussion in which it was confirmed that TLS *could* be implemented "but traditionally we have not done so", was just updated by Manuel Wolfshant with the following lie:-

*Note: downloads are hosted on a mirror network, where we cannot mandate that every mirror node runs SSL/TLS, hence using regular http and not enforcing https*

False statements are disgusting to begin with, but ones that attempt to excuse the lazy decision to put all CentOS customers at risk are totally unacceptable.  LE is free and easy to use and setup - it's a no- brainer to fix this problem, assuming someone isn't getting a kickback from some 3-letter-agency to leave this exploitable security hole open ? _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

Well..

*Technically* CentOS users are not customers - at all in fact - unless they also happen to also own a paid RHEL subscription.

Now onto the issue at hand. While the info should be accurate, I don't think it's a big deal.

TLS is certainly preferable for the mirror network, it isn't entirely required from a security point of view.

Realistically TLS shines most when you're transporting customer (user data) or are dealing with some kind of sensitive information, trying to stop prying eyes etc.

From a mirror perspective it's not overly important because the only protection TLS can add in this case is to prevent RPM tampering. But even if someone intercepted your connection and successfully switched the RPM while it was downloading the risk is minimal.

This is because your local machine has the GPG key identity required for the packages. All CentOS (and most RPM distros) sign their packages with a GPG key, which package managers then use to verify the RPM has not been tampered with.

That's why if you want to install a non-GPG signed package from a repo you need to specifically tell yum/dnf to ignore GPG signing.

So, TLS or not, if your package has been swapped with a fake, your package manager should notice this and refuse to install that package.

The biggest problem from a security point of view would probably be a rogue mirror that serves up modified packages.. a rogue mirror could also carry TLS.

That's why you sign the RPM for security.

dnf not checking gpg signature sounds scary:

https://github.com/ansible/ansible/blob/v2.9.13/changelogs/CHANGELOG-v2.9.rs...

-- Leon