Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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. > Signing on the package level is a nice extra feature, but it is only a piece > in a working security concept. It is not even covering the update process. > Even if key revocation worked (which in general it does not, Google does not > even use it for TLS any more), a valid signature on the package level is no > guarantee that the update is correct. > This is of course solved by signing of update lists in short intervals, which > makes signatures on the package level unnecessary in the first place. 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-874388985___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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. Signing on the package level is a nice extra feature, but it is only a piece in a working security concept. It is not even covering the update process. Even if key revocation worked (which in general it does not, Google does not even use it for TLS any more), a valid signature on the package level is no guarantee that the update is correct. This is of course solved by signing of update lists in short intervals, which makes signatures on the package level unnecessary in the first place. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-874332436___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Improve the OpenSSL crypto backend (#1610)
@ffesti ping -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1610#issuecomment-874242576___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Avoid undefined shifts (#1547)
@ffesti ping -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1547#issuecomment-874223347___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Header signatures alone are not sufficient (#1672)
@ffesti ping -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1672#issuecomment-874223443___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Check that padding is zeroed and regions are consistent (#1613)
@ffesti would you mind looking at this? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1613#issuecomment-874124913___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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. 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-873998097___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-873946795___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> 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: > https://dev.gnupg.org/T4108 > https://dev.gnupg.org/T4537 > > The problem is not specific to RPM and package signatures. Git signatures, > for example, also have the same issue: > https://petertodd.org/2016/opentimestamps-git-integration > > 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, and therefore does not need to be revoked. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-873937456___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
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: https://dev.gnupg.org/T4108 https://dev.gnupg.org/T4537 The problem is not specific to RPM and package signatures. Git signatures, for example, also have the same issue: https://petertodd.org/2016/opentimestamps-git-integration 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-873935952___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Installation / verification should not pass if the (sub)key(s) has been revoked or expired (#1598)
> @dmantipov Is there a CVE associated with this vulnerability? > I'm asking so that I can keep an eye out for the fix. > > Also, on a different note, any idea if package managers that reply on rpm are > vulnerable as well? Yum and Zypper for instance. 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. RPM by design works on the local system only and does not look things up on the internet. It does not make decisions on its own but relies the user or other tools to be told what needs to be done - including adding or removing key. The RPM way of no longer trusting a key is to remove it from the RPM DB. This works just fine. 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1598#issuecomment-873881324___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
