[opensuse-security] Unknown package signing key in OpenSUSE repo
Hi! Today packages signed with key ID b3fd7e48 have appeared in openSUSE repo-update. I get warnings that this is an unknown key. Can somebody advice how to verify that it is a legitimate key? More details at https://forums.opensuse.org/showthread.php/496213-zypper-up-found-no-key-but... Regards, Uwe -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Fri, Mar 14, 2014 at 02:00:34AM +0200, Uwe Geuder wrote:
Hi!
Today packages signed with key ID b3fd7e48 have appeared in openSUSE repo-update. I get warnings that this is an unknown key. Can somebody advice how to verify that it is a legitimate key?
More details at https://forums.opensuse.org/showthread.php/496213-zypper-up-found-no-key-but...
Thanks for the report... This key is the build key for the openSUSE:Maintenance staging area. It should not have been used for the released update itself (the RPMs are resigned before release). Ciao, Marcus -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Friday, March 14, 2014 07:19:09 Marcus Meissner wrote:
On Fri, Mar 14, 2014 at 02:00:34AM +0200, Uwe Geuder wrote:
Hi!
Today packages signed with key ID b3fd7e48 have appeared in openSUSE repo-update. I get warnings that this is an unknown key. Can somebody advice how to verify that it is a legitimate key?
More details at https://forums.opensuse.org/showthread.php/496213-zypper-up-found-no-key-b ut-still-installed-packages Thanks for the report...
This key is the build key for the openSUSE:Maintenance staging area.
It should not have been used for the released update itself (the RPMs are resigned before release).
Ciao, Marcus
Good, I thought I was going crazy over here:) But, this raises another point: How is it possible for apper to install packages without key/wrong key? The packages are served over plain http, above shouldn't be acceptable? Or am I misunderstanding something here, I'd appreciate clarification if possible. Kind regards, Jason -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Fri, Mar 14, 2014 at 02:35:40PM -0400, Jason wrote:
On Friday, March 14, 2014 07:19:09 Marcus Meissner wrote:
On Fri, Mar 14, 2014 at 02:00:34AM +0200, Uwe Geuder wrote:
Hi!
Today packages signed with key ID b3fd7e48 have appeared in openSUSE repo-update. I get warnings that this is an unknown key. Can somebody advice how to verify that it is a legitimate key?
More details at https://forums.opensuse.org/showthread.php/496213-zypper-up-found-no-key-b ut-still-installed-packages Thanks for the report...
This key is the build key for the openSUSE:Maintenance staging area.
It should not have been used for the released update itself (the RPMs are resigned before release).
Ciao, Marcus
Good, I thought I was going crazy over here:)
But, this raises another point:
How is it possible for apper to install packages without key/wrong key? The packages are served over plain http, above shouldn't be acceptable?
Or am I misunderstanding something here, I'd appreciate clarification if possible.
The verification of repositories is done via the YUM metadata. It chains like this: repodata/repomd.xml (signature in repomd.xml.asc) this contains sha256 signatures of the XML files in repodata/: repodata/*.xml these contain sha256 signatures of all RPMs and other files. The RPM signature is usually not involved in this framework. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
Hi Marcus, On Friday, March 14, 2014 08:02:35 Marcus Meissner wrote:
On Fri, Mar 14, 2014 at 02:35:40PM -0400, Jason wrote:
On Friday, March 14, 2014 07:19:09 Marcus Meissner wrote:
On Fri, Mar 14, 2014 at 02:00:34AM +0200, Uwe Geuder wrote: <snip>
Good, I thought I was going crazy over here:)
But, this raises another point:
How is it possible for apper to install packages without key/wrong key? The packages are served over plain http, above shouldn't be acceptable?
Or am I misunderstanding something here, I'd appreciate clarification if possible.
The verification of repositories is done via the YUM metadata.
It chains like this:
repodata/repomd.xml (signature in repomd.xml.asc) this contains sha256 signatures of the XML files in repodata/: repodata/*.xml
these contain sha256 signatures of all RPMs and other files.
The RPM signature is usually not involved in this framework.
Thank you for clarifying. Hope you don't mind me pestering a bit more:) How easy is it the hypothetical mitm in this case? I imagine if the package is different it would fail at digest check anyway so this key issue wouldn't crop up but nevertheless, is it sensible to add the key 'trip point'? Also, since it is served over http, repodata.xml could be injected so digest would pass but not fail at package key check? Sorry if I'm overbearing, but I'd like to understand why is it acceptable for zypper to process the offending package.
Ciao, Marcus
Kind regards, Jason -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Fri, Mar 14, 2014 at 03:10:27PM -0400, Jason wrote:
Hi Marcus,
On Friday, March 14, 2014 08:02:35 Marcus Meissner wrote:
On Fri, Mar 14, 2014 at 02:35:40PM -0400, Jason wrote:
On Friday, March 14, 2014 07:19:09 Marcus Meissner wrote:
On Fri, Mar 14, 2014 at 02:00:34AM +0200, Uwe Geuder wrote: <snip>
Good, I thought I was going crazy over here:)
But, this raises another point:
How is it possible for apper to install packages without key/wrong key? The packages are served over plain http, above shouldn't be acceptable?
Or am I misunderstanding something here, I'd appreciate clarification if possible.
The verification of repositories is done via the YUM metadata.
It chains like this:
repodata/repomd.xml (signature in repomd.xml.asc) this contains sha256 signatures of the XML files in repodata/: repodata/*.xml
these contain sha256 signatures of all RPMs and other files.
The RPM signature is usually not involved in this framework.
Thank you for clarifying.
Hope you don't mind me pestering a bit more:)
How easy is it the hypothetical mitm in this case?
It is not really possible I hope.
I imagine if the package is different it would fail at digest check anyway so this key issue wouldn't crop up but nevertheless, is it sensible to add the key 'trip point'?
I do not fully understand?
Also, since it is served over http, repodata.xml could be injected so digest would pass but not fail at package key check?
Sorry if I'm overbearing, but I'd like to understand why is it acceptable for zypper to process the offending package.
repomd.xml has a detached signature in repomd.xml.asc This signature is done by a GPG key that is either already in the system or zypper/yast2 will ask you about. If repomd.xml does not match the repomd.xml.asc signature zypper will put up a big fat warning. If repomd.xml.asc is not present, also a big warning will be printed. The trust concept we currently use does not to include the RPM embedded GPG signatures itself, although they are signed by the same key as repomd.xml usually. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Friday, March 14, 2014 08:17:23 Marcus Meissner wrote:
On Fri, Mar 14, 2014 at 03:10:27PM -0400, Jason wrote:
Hi Marcus,
On Friday, March 14, 2014 08:02:35 Marcus Meissner wrote:
On Fri, Mar 14, 2014 at 02:35:40PM -0400, Jason wrote:
On Friday, March 14, 2014 07:19:09 Marcus Meissner wrote:
On Fri, Mar 14, 2014 at 02:00:34AM +0200, Uwe Geuder wrote: <snip>
<snip>
It chains like this:
repodata/repomd.xml (signature in repomd.xml.asc)
this contains sha256 signatures of the XML files in repodata/: repodata/*.xml
these contain sha256 signatures of all RPMs and other files.
The RPM signature is usually not involved in this framework.
Thank you for clarifying.
Hope you don't mind me pestering a bit more:)
How easy is it the hypothetical mitm in this case?
It is not really possible I hope.
Lacks reassurance :P
I imagine if the package is different it would fail at digest check anyway so this key issue wouldn't crop up but nevertheless, is it sensible to add the key 'trip point'?
I do not fully understand?
I'm seldomly experiencing sha digest checks (no logging available so fwiw) where zypper stops and asks me what to do (btw, it should fail and not give me options) What I'm saying, this happens _before_ the warning that is the topic of the exchange. (Here I assume lack of my understanding in the process, will get to that later) And what was the question, 'trip point' where _before_ installation zypper won't install the package with non-matching key sig.
Also, since it is served over http, repodata.xml could be injected so digest would pass but not fail at package key check?
Sorry if I'm overbearing, but I'd like to understand why is it acceptable for zypper to process the offending package.
repomd.xml has a detached signature in repomd.xml.asc
This signature is done by a GPG key that is either already in the system or zypper/yast2 will ask you about.
If repomd.xml does not match the repomd.xml.asc signature zypper will put up a big fat warning. If repomd.xml.asc is not present, also a big warning will be printed.
Ok, i think I got it now, thank you. During the query/download process, if anything is modified _between_ me and the server it will put up at least a warning.
The trust concept we currently use does not to include the RPM embedded GPG signatures itself, although they are signed by the same key as repomd.xml usually.
Ciao, Marcus
This actually leaves to possibility of server-side compromise? If attacker signs with his key, or no key, package will be installed? -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Freitag, 14. März 2014, 15:41:34 wrote Jason:
On Friday, March 14, 2014 08:17:23 Marcus Meissner wrote: ...
The trust concept we currently use does not to include the RPM embedded GPG signatures itself, although they are signed by the same key as repomd.xml usually.
Ciao, Marcus
This actually leaves to possibility of server-side compromise? If attacker signs with his key, or no key, package will be installed?
not with zypp at least, since you need to re-generate and re-sign the rpm-md meta data (or susetag style metadata for product repos). -- Adrian Schroeter email: adrian@suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On Friday, March 14, 2014 08:48:20 Adrian Schröter wrote:
On Freitag, 14. März 2014, 15:41:34 wrote Jason:
On Friday, March 14, 2014 08:17:23 Marcus Meissner wrote: ...
The trust concept we currently use does not to include the RPM embedded GPG signatures itself, although they are signed by the same key as repomd.xml usually.
Ciao, Marcus
This actually leaves to possibility of server-side compromise? If attacker signs with his key, or no key, package will be installed?
not with zypp at least, since you need to re-generate and re-sign the rpm-md meta data (or susetag style metadata for product repos).
Fail at comprehension:) Thank you. FWIW, I'd prefer for zypper to: 1. Halt with a warning when digest check fails (ie no options to be dealt with) 2. Do not install package if key is not matching. I do understand the process more or less now, thank you gentlemen for explaining it to me so I see how this is is the _least_ possible issue. And as for server side, use separate keys for package signing and repo signing. In case the repo key is compromised (again, very unlikely) you'd have to consider the whole repo to be compromised (unless you find in the logs what packages have changed, but it would at least stop the packages from installing) I'm probably off by a margin so pardon my ignorance. Kind regards, Jason -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On 2014-03-14 21:04, Jason wrote:
On Friday, March 14, 2014 08:48:20 Adrian Schröter wrote:
Your clock might be wrong, too fast. It is now 19:24.
Fail at comprehension:) Thank you.
FWIW, I'd prefer for zypper to:
1. Halt with a warning when digest check fails (ie no options to be dealt with) 2. Do not install package if key is not matching. I do understand the process more or less now, thank you gentlemen for explaining it to me so I see how this is is the _least_ possible issue.
As I understand it, the repository metadata is signed, and both YaST and zypper will give a big warning if the signature check (of the metadata) fails. Individual packages are signed, but the signatures are not verified. However, those packages are listed in the metadata, with checksums, so that if a single package does not match the metadata contained checksum, you will get a warning. Zypper/yast would not install that package, as bad. So the overall process is gpg signed :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On Friday, March 14, 2014 19:30:01 Carlos E. R. wrote:
On 2014-03-14 21:04, Jason wrote:
On Friday, March 14, 2014 08:48:20 Adrian Schröter wrote: Your clock might be wrong, too fast. It is now 19:24.
Botched timezone during setup few days ago:) Good eye though.
Fail at comprehension:) Thank you.
FWIW, I'd prefer for zypper to:
1. Halt with a warning when digest check fails (ie no options to be dealt with) 2. Do not install package if key is not matching. I do understand the process more or less now, thank you gentlemen for explaining it to me so I see how this is is the _least_ possible issue.
As I understand it, the repository metadata is signed, and both YaST and zypper will give a big warning if the signature check (of the metadata) fails.
True.
Individual packages are signed, but the signatures are not verified.
Agreed. What I'm suggesting, (well, just thinking out loud) in case of repo key compromise, to have packages signed with a different key and fail to install the package if key doesn't match or there's no key. Or at the bare minimum, refuse to install package that isn't signed/signed with a different key. If repo key is compromised, any malicious package would be rejected by the local machine if signed by different key _and_ any malicious package would be easily recognized. It also removes a single point of failure. Though again, I'm probably missing something here.
However, those packages are listed in the metadata, with checksums, so that if a single package does not match the metadata contained checksum, you will get a warning. Zypper/yast would not install that package, as bad.
Yes, it will pull up a warning that digest checking failed and _offer_ you options. At this point what I'm suggesting is to drop it without options but with only a warning, or enter re-download loop few times, fail if unsuccessful _and_ pull up a warning Also, log warnings. Currently it isn't doing that AFAIK.
So the overall process is gpg signed :-)
But there are seemingly few points to discuss or clarify to uninformed like me :) -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
participants (5)
-
Adrian Schröter -
Carlos E. R. -
Jason -
Marcus Meissner -
Uwe Geuder