-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
over five years ago vulnerabilities in Fedora's (and others) package managers [1] have been presented at USENIX.
And even though yum supports repo_gpgcheck since 2008 [2] Fedora still does not make use of it to protect the repo metadata.
Are there specific reasons why Fedora still does not sign its repo metadata to prevent metadata manipulation attacks (i.e. "hiding" updates)? The LWN article from 2009 somehow hinted that it was about to be enabled in Fedora 11? [1]
I filed a bug against fedora-release (covering the missing repo_gpgcheck in fedora.repo) [3]. Which component would I file the missing repomd.xml.asc (on fedora's repositories) against?
thanks, Joonas
[1] https://lwn.net/Articles/327847/ [2] http://lists.baseurl.org/pipermail/yum-devel/2008-August/005350.html [3] https://bugzilla.redhat.com/show_bug.cgi?id=1130491
On Sat, 16 Aug 2014 22:20:26 +0000 Joonas Lehtonen joonas.lehtonen@bitmessage.ch wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
over five years ago vulnerabilities in Fedora's (and others) package managers [1] have been presented at USENIX.
And even though yum supports repo_gpgcheck since 2008 [2] Fedora still does not make use of it to protect the repo metadata.
Are there specific reasons why Fedora still does not sign its repo metadata to prevent metadata manipulation attacks (i.e. "hiding" updates)? The LWN article from 2009 somehow hinted that it was about to be enabled in Fedora 11? [1]
It's logistically difficult to sign the repodata... but of course it could be done.
Many, if not all of the things they mention (I can't seem to find a link to the orig USENIX pdf thats still valid to be sure) were fixed by us moving to using metalinks by default.
The metalink is fetched over https and the ssl certs are checked. The metalink has checksums of the current and previous repodata only. If the mirror doesn't have either of those, it's skipped.
At least I can't off hand think that any of the items they mention not being taken care of by metalinks, but perhaps I missed something. ;)
I filed a bug against fedora-release (covering the missing repo_gpgcheck in fedora.repo) [3]. Which component would I file the missing repomd.xml.asc (on fedora's repositories) against?
Release engineering trac instance I suppose... https://fedorahosted.org/rel-eng/
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
It's logistically difficult to sign the repodata... but of course it could be done.
Many, if not all of the things they mention (I can't seem to find a link to the orig USENIX pdf thats still valid to be sure) were fixed by us moving to using metalinks by default.
The metalink is fetched over https and the ssl certs are checked. The metalink has checksums of the current and previous repodata only.
While transport layer security is certainly weaker than gpg signatures (depending on where you store your private keys) it is certainly addresses the easiest MITM attacks.
Is there any kind of certificate pinning in place when verifying the certificate of https://mirrors.fedoraproject.org or can the certificate be from any trusted CA?
Thanks for your explanation!
Joonas Lehtonen wrote:
Is there any kind of certificate pinning in place when verifying the certificate of https://mirrors.fedoraproject.org or can the certificate be from any trusted CA?
I strongly suspect the answer is "any trusted CA"
-- rex
On Sat, 16 Aug 2014 23:55:55 +0000 Joonas Lehtonen joonas.lehtonen@bitmessage.ch wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
It's logistically difficult to sign the repodata... but of course it could be done.
Many, if not all of the things they mention (I can't seem to find a link to the orig USENIX pdf thats still valid to be sure) were fixed by us moving to using metalinks by default.
The metalink is fetched over https and the ssl certs are checked. The metalink has checksums of the current and previous repodata only.
While transport layer security is certainly weaker than gpg signatures (depending on where you store your private keys) it is certainly addresses the easiest MITM attacks.
Yeah.
Is there any kind of certificate pinning in place when verifying the certificate of https://mirrors.fedoraproject.org or can the certificate be from any trusted CA?
I'm not sure. Yum (and dnf) uses python-urlgrabber, which uses urlgrabber, which uses curl. So, it would depend on the default curl config.
Thanks for your explanation!
No problem.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
It's logistically difficult to sign the repodata... but of course it could be done.
Has someone tried to get this done/accepted before?
Is there any kind of certificate pinning in place when verifying the certificate of https://mirrors.fedoraproject.org or can the certificate be from any trusted CA?
I'm not sure. Yum (and dnf) uses python-urlgrabber, which uses urlgrabber, which uses curl. So, it would depend on the default curl config.
So we could take advantage of the environment variable named 'CURL_CA_BUNDLE' to feed it with the issuing CA of https://mirrors.fedoraproject.org 's certificate.
Has fedora a policy where it gets its certificates from? Is it always DigiCert?
Until curl gets DANE support we could use 'CURL_CA_BUNDLE' as a poor men's CA pinning?
http://curl.haxx.se/docs/todo.html#Support_DANE
On Tue, 19 Aug 2014 16:05:12 +0000 Joonas Lehtonen joonas.lehtonen@bitmessage.ch wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
It's logistically difficult to sign the repodata... but of course it could be done.
Has someone tried to get this done/accepted before?
Not sure what you mean fully by that, but it's been talked about before. If you're really interested in it propose it to release engineering and offer to work on needed code/etc.
The big downside is that it means the updates compose would stop at the very end and need to have the repodata signed before it could be pushed out, so it means someone would have to not only sign packages before a updates push, but come back many hours later and sign the repodata too. I'm sure it would need bodhi changes, possibly mash changes, possibly changes to the signing tools.
Is there any kind of certificate pinning in place when verifying the certificate of https://mirrors.fedoraproject.org or can the certificate be from any trusted CA?
I'm not sure. Yum (and dnf) uses python-urlgrabber, which uses urlgrabber, which uses curl. So, it would depend on the default curl config.
So we could take advantage of the environment variable named 'CURL_CA_BUNDLE' to feed it with the issuing CA of https://mirrors.fedoraproject.org 's certificate.
I suppose, sure. Or it might be a slightly different env for urlgrabber... not sure.
Has fedora a policy where it gets its certificates from? Is it always DigiCert?
No, it was another registrar until last year. It hasn't changed often though.
Until curl gets DANE support we could use 'CURL_CA_BUNDLE' as a poor men's CA pinning?
Sure.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Kevin Fenzi:
So we could take advantage of the environment variable named
'CURL_CA_BUNDLE' to feed it with the issuing CA of https://mirrors.fedoraproject.org 's certificate.
I suppose, sure. Or it might be a slightly different env for urlgrabber... not sure.
It is actually even easier:
sslcacert=/path/to/pem
works fine here.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
"repo files: certificate pinning for mirrors.fedoraproject.org via sslcacert yum option"
https://bugzilla.redhat.com/show_bug.cgi?id=1131673
-
Joonas Lehtonen -
Kevin Fenzi -
Rex Dieter