Installation / verification should not pass if the (sub)key(s) has been revoked or expired #1598
Comments
|
Note dmantipov@0f8654d is not pretended to be correct in general and likely may handle the only particular case. I just want to make sure that I'm moving in the right direction. |
|
Revocation is one of the many unimplemented things in rpm's OpenPGP support. In other words, you're not seeing a bug as such, it's just not implemented at all, much like expiration is not. |
Given the complexity of a full implementation, I wonder if we would be better off ditching OpenPGP entirely in RPMv6. Something like signify would be trivial to implement, and we can just add new tags whenever we need to support new algorithms. |
What about offloading this to external library like gpgme? |
|
@DemiMarie , please stop throwing around RPMv6 so liberally. See the project description, it is not going to be the grand rewrite of everything but a strictly limited scope revision of what we have now, and bringing it up on every other ticket here can easily give people wrong ideas. There will eventually be a draft to comment on but until then the subject is not really open for discussion. |
So is it worth spending time trying to improve current OpenPGP support? Not sure about complete, RFC4880-compilant implementation, but revocation and expiration at least? |
Yes it is. Just note that the problem with revocation and expiry is not so much parsing it out of PGP than the actual interaction with the rest of rpm. |
dmantipov
changed the title
What about adding configure-time option, say, --enable-enforced-signatures? If configured and compiled with this one, RPM should refuse to install the package if no signature at all or (sub)key(s) has been revoked or expired. This may be useful for the distributions where paranoid security checks are essential. |
|
There's already an enforcing mode for signature checking at install time, and that's a point where revocation and expiry checks would seem fairly obvious. The open questions come after that. |
Is it controlled by the command-line option? I've found only --nodigest and --nosignature, both meaning an opposite to what we're talking about here. |
|
See Line 672 in 375bac6 (that stuff really needs proper docs, sigh...) |
Is it intended to describe mechanism or policy? It seems that these two are mixed through the whole code base in an obfuscating and weird way. For example, what's expected to happen if someone try |
|
Could someone please briefly review two patches above? Thanks. |
Revocation signatures are only valid if they are a valid signature of the key being revoked, and are made by either the key being revoked or a key that it has designated as valid for revocation. |
|
Well, it seems it would be helpful to have some advice here. In my local setup, packets analysis code detects the following, So, if [2] is detected and key id at [3] matches key id saved at [1], can I assume that the key (and so all subkeys) is revoked? |
Only if [2] is a valid signature of [1], made by [1]. And you should use fingerprints, not key IDs, if possible. Key IDs are not guaranteed to be unique. |
|
I'll investigate how to dig for fingerprints; here is the version with key IDs. |
Thanks! In addition to the fingerprint vs key ID issue, this still needs a cryptographic signature check. |
Is it enough to get zero from |
|
Note the following text from the gpgv manpage: So we're in good company ;-) |
|
Revocation checking requires a proper keystore, which RPM does not have. Expiration checking “merely” requires checking the expiration date of the self-signature. |
|
Related discussion of this over here ostreedev/ostree#2260 |
|
I don't think we need to support key revokation in rpm. My understanding is that the revokation handling in gpg is done that way because gpg can only merge new key material and never deletes existing data. But that's not the way rpm works, as it does not merge key material. I don't think it makes sense to have a revoked key in the database at all, you might as well just delete the key from the database. So we could state that it's up to the layer above rpm that manages the keys to handle this (libzypp does handle key updates, I don't know about dnf). But I do think rpm should check the expiry date of a key. We could make it configurable how rpm deals with an expired key. |
Perhaps a better option would be to replace the revoked key with an invalid stub entry, so future attempts to re-add the key fail. This also lets us provide better error messages to the user.
Agreed. |
|
@dmantipov Is there a CVE associated with this vulnerability? Also, on a different note, any idea if package managers that reply on rpm are vulnerable as well? Yum and Zypper for instance. |
|
An additional thing, once a key is revoked by a distro (for whatever reason), they usually sign new rpms with the new key. However it does not mean that the older rpms signed by the old key are no longer secure to use. Unless of-course the old key has been compromised by the attacker and they sign malicious rpms with that. So if revokation makes all the installed rpms, seem to be signed with the wrong key, than that could be a problem. Therefore there is some amount of onus on the administrator/user as well. |
I mean the rpms signed before the key was revoked.
|
OK, as there is some confusion here: There is no CVE (AFAIK) and there should not be a CVE. This is not a vulnerability. This is a basic misunderstanding on how rpm works. This does not mean that the current situation does not leave things to be desired as withdrawing a key requires quite some effort like issuing an updated that removes the key or using some sort of automation for local setups. But the topic is much more complicated than just adding support for GPG revocation keys to RPM. First the actual key look up and check needs to go into the updater level (e.g. dnf and zypper) as they are dealing with things on the network. More important than removing a key is probably a way to add a new one when the current one is no longer trusted. Just breaking (automatic) updates for everyone is not a great solution. And there are probably more things to consider. Some are already mentioned above. |
|
I agree with @ffesti about key revokation being more complex than what it seems like. When you revoke, you don't want to invalidate the signatures created before the revokation. That would require every existing package to be re-signed with the new key, which would be very disruptive. But how can you trust the signature date? An attacker could create a new signature with a forged date. Therefore you need to add support for trusted third-party timestamping to the signatures. Unless I am mistaken, there is no such support in GPG: The problem is not specific to RPM and package signatures. Git signatures, for example, also have the same issue: Short term, the simplest way to deal with a compromised key, is to remove it from the RPM DB, just as @ffesti suggested. There should be a tested and planned process for how to do this, for example by sending an emergency update, perhaps signed with the disaster recovery key (in Red Hat case). It would also require all packages are re-signed with a new key, since the old ones will be invalidated after the key removal. Long term, adding support for trusted timestamps would make key revokation much easier. |
Perhaps the best solution is to ensure (by appropriate use of HSMs) that the key cannot be leaked. |
Yes, that comes a long way to mitigating the problem and is hopefully already used by the major distributions. But the risk is not completely eliminated, since the usage of the HSM itself may have become compromised. An attacker may have gained access to a system with HSM access and issued malicious signatures. If this should happen, a key replacement is most probably warranted. Fedora has actually been through this before, over a decade ago. (Showing one possible way to manage the situation without GPG key revokation support in RPM): |
Absolutely! That said, I imagine any decent HSM can perform internal time-stamping, in which case only signatures before a certain point need to be invalidated. |
|
There is another issue that is not covered by revocation at all. A software package is obsolete as soon as a new version of the package is signed, especially if there is a known vulnerability in the old version. However, the signature of the vulnerable version obviously stays valid. If the security of updates were just based on package signatures, an attacker could just give you an old package version with a known vulnerability. |
The signature on an RPM by a vendor/distributor implies that the package has indeed been provided by the vendor and an MITM attacker has not tampered with it. It does not prove that the binaries in the package are non-malicious or free from known/unknown security defects, those are different security problems. Most likely someone who trusts his vendors signing keys would also trust that the vendor is providing him with known good binaries. |
|
To conclude, neither revocation or expiry is particularly meaningful in the rpm context, only a very limited subset of OpenPGP spec is relevant to rpm. Revoking has been discussed at length here already, and while expiry is far simpler on the outset, tick of the clock will not remove expired software from the system so checking for it at the door would only make things weirder, security would not be improved in the slightest. |
Shouldn't RPM treat the revoked (sub)key(s) as no longer valid? I'm trying to fix the simple use case with the only revoked subkey. IOW after importing:
the package previously signed as:
should not pass verification:
and warning should be issued during an installation:
The text was updated successfully, but these errors were encountered: