From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 3437E138359 for ; Sat, 10 Oct 2020 20:10:54 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A592DE0822; Sat, 10 Oct 2020 20:10:50 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 62E95E07A7 for ; Sat, 10 Oct 2020 20:10:50 +0000 (UTC) To: gentoo-dev@lists.gentoo.org References: <20201006095814.101719-1-mgorny@gentoo.org> From: Thomas Deutschmann Organization: Gentoo Foundation, Inc Subject: Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs Message-ID: <8d0c19ec-55cd-222f-998d-ec82c87df4f2@gentoo.org> Date: Sat, 10 Oct 2020 22:10:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/78.3.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: <20201006095814.101719-1-mgorny@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WO2n3ZkjiJj5bceZsfXBPgpvqNJYOdhno" X-Archives-Salt: 5bcf523f-56ec-41a3-bb1c-126a718cfc81 X-Archives-Hash: 1573fcc4cd5c4d2b97559867da2a58f7 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WO2n3ZkjiJj5bceZsfXBPgpvqNJYOdhno Content-Type: multipart/mixed; boundary="f0lR2PqwVsdlanoHpVsZtfUbYOKlcb9JA"; protected-headers="v1" From: Thomas Deutschmann To: gentoo-dev@lists.gentoo.org Message-ID: <8d0c19ec-55cd-222f-998d-ec82c87df4f2@gentoo.org> Subject: Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs References: <20201006095814.101719-1-mgorny@gentoo.org> In-Reply-To: <20201006095814.101719-1-mgorny@gentoo.org> --f0lR2PqwVsdlanoHpVsZtfUbYOKlcb9JA Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, I am really unhappy with this addition. Another example for something that was not thought to the end and which=20 was rushed and pushed to our users. Sorry for being late to this but any = addition should really add a benefit. What is the benefit verify-sig is=20 adding? When mgorny started to propose this in #-qa, he used the argument to=20 improve security of Gentoo because we cannot know if every Gentoo=20 developer is really verifying distfiles or just copying ebuild to new=20 version and let `repoman commit` fetch the distfile and be done with the = bump. While I agree with the idea in general, i.e. when you would be=20 able to provide an automatism for that, that would be a great addition. But there is a problem. You cannot automate trust. And anyone who is trying to do that shows that he/she does not=20 understand how signing works and because of the fact he/she will claim=20 security was improved, security was actually lowered due to that. How is that? Because the statement you can get from a signature depends on the trust=20 in the used key. I.e. you assume that the key used to create that=20 signature is only accessible by the designated owner and that nobody=20 else have access to it. In the moment you learn that somebody else=20 gained access to that key, i.e. can create signatures using the same=20 key, you can no longer trust that key. More important, you should start=20 questioning previously seen signatures (if you take it serious you will=20 distrust any files signed by that key and demand on a new signature with = a new key where you managed to establish a new trust). Short excerpt: Code signing is nothing new. It is an important layer in Microsoft=E2=80=99= s=20 security defense. Even Apple is relying on signatures for their sandbox=20 they introduced some years ago. But does a signature prevent anything?=20 Of course not. StuxNet was signed with a valid signature from Realtek=20 Semiconductor Corp. and switched later to a signature which belongs to=20 JMicron Technology Corp when Realtek=E2=80=99s signature got revoked. A=20 post-mortem analysis suggested that cybercriminals compromised both=20 organizations and have stolen their development certificates, including=20 the private keys used to sign the executables. In 2014, when Sony=20 Pictures got hacked, attackers had signed the malware with valid=20 certificates from *Sony*. But that is only the tip of the iceberg, see=20 https://attack.mitre.org/techniques/T1553/002/ for more examples. My=20 point here is, and I believe we all agree on this, that signatures alone = are meaningless. To add a meaning to signatures you must trust the signer that he/she=20 will immediately revoke the certificate once he/she gets aware that an=20 unauthorized third party gained access to the certificate. If we, for an = unknown reason, assume that this will happen, we will face another=20 problem: We must receive this information. If we do not know that=20 something has happened to the key, we will not take any actions. I guess you all still remember how you created your GPG key for Gentoo,=20 don=E2=80=99t you? Do you still have access to the revocation certificate= you=20 created during that process? I am sure you do. But do you know how this=20 process works? Right, you need to upload that certificate to a key=20 server. But then 2019 happened. Key servers are dead now. You can no=20 longer rely on key servers, especially not that once you have uploaded=20 your revocation certificate that it will spread and reach users. Just do = an easy exercise: Check who committed to Gentoo repository in past 6=20 months. Now try to fetch the GPG key of all committers without using=20 *.gentoo.org. Good luck! And no, WKD cannot help you with that (revocatio= n). Coming back to my initial statement that it is all about automatization. The whole idea started with assumption that not every developer will=20 verify the distfile (an assumption I share). But why should we trust=20 these developers that they will keep an eye on upstream=E2=80=99s used=20 certificate instead? That does not make any sense for me. Another point I just want to mention was patch 5 of 6 for=20 net-libs/miniupnpc. Did you notice that the ebuild will fetch public key = via HTTP instead of HTTPS? This will create a chicken-egg problem here:=20 We will record key information metadata the same way we store=20 information about distfiles which is temper proofed. But because this is = happening in an automatic way there is not just a theoretical chance=20 that we will store an attacker=E2=80=99s key in our metadata because who = is=20 going to verify they key? The same developer we distrust (or where we=20 just want to avoid to trust) that he/she verified the distfile? Do you see the contradiction? Please do not get me wrong. I like the idea. But I also understand that=20 you cannot implement it in a secure and really working way -- you will=20 always require a human paying attention. But now that we pretend, we=20 managed to implement that and even show a fancy green message that we=20 verified (any) signature, we actually lowered security because more=20 people will now stop paying attention: - Previous developers who carefully checked distfiles will stop doing that. - Nobody will question anything because there is a new passed check. In worst case scenario, we are now emerging a signed malicious package=20 we could be aware of if some human would have checked upstream and=20 noticed that release key was revoked. But this will not happen anymore=20 because we rely that once we have recorded a key in the metadata that=20 some system will tell us in case there is a problem. And what do you=20 expect what will happen when after the download something will tell us=20 =E2=80=9COh, this file is not signed with currently known key=E2=80=9D? R= ight, that=20 developer who we do not want to trust that he/she verified the distfile=20 will just add a reference to the new matching key which will silence any = warning. No, sorry. Security required education. You need to understand where=20 security is depending on so that you know when you need to take action. Every attempt to move this away from the user will actually add needless = complexity, allow for new attack vectors and will not improve security. The purpose of this email is to get this addition removed ASAP. PS: I assume that the "Arch Linux is using something similar" argument=20 will appear. I am not going to make an in depth statement about what=20 Arch Linux is doing here. But they have a total different security model = which you have to take into account. And please don't forget that we=20 already have that working Manifest mechanism which isn't promising=20 anything it cannot do. --=20 Regards, Thomas Deutschmann / Gentoo Security Team fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 --f0lR2PqwVsdlanoHpVsZtfUbYOKlcb9JA-- --WO2n3ZkjiJj5bceZsfXBPgpvqNJYOdhno Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEExKRzo+LDXJgXHuURObr3Jv2BVkFAl+CFUMFAwAAAAAACgkQRObr3Jv2BVlh OQgAnXN24YlABNNDy2tL8/P4FWhyEkWPZ8c7/KdgKUoUzp3jF1fwiCabXosj3uPNxak4JOLH7TbO PwegvQbHny9OMbUNOJorkIpzhNXDm154a5KQXZmnTWWhmHGuz9yI6RlnXYqrklrpunHSTfwGOGxh ++z8dbUJgT1q4w6Lhrt1dbC5auQ0smWaC1YPV4vRw1c4Jg6DLyfetp+q3W4qoJHkVjnisFNZ4/XJ bmux8eLvhE+SdWVRiFJqEbxcGDbaxQOObrJ8/8gQb6E3rNnmSB40rqHoPEvqdTR8Spg3zDL/XfcT nxdbRAeiQfmBMgl5XjXcyxuNngsQtCKzm1A+YCi7fA== =hyg6 -----END PGP SIGNATURE----- --WO2n3ZkjiJj5bceZsfXBPgpvqNJYOdhno--