Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
On 03/08/2015 08:02 AM, Mark Kubacki wrote:
On 03/06/2015 09:50 AM, Mark Kubacki wrote:
And by default you cannot compare the result with any authoritative source.
2015-03-08 0:26 GMT+01:00 Zac Medico zmed...@gentoo.org:
Ideally, we can rely on security mechanisms built into git [1], possibly
involving signed commits.
Some brownfield thinking here, without GIT and not replacing GIT:
1. Find and compile all directories two levels deep in a file
category.idx and sign it.
2. Sign every Manifest.
3. Distribute that as usual.
Will need N+1 checks (N × Manifest + 1 × category present/missing) and
doesn't break anything already deployed.
I think it's an unnecessary expenditure of effort to implement our own
Merkle tree, considering that git's Merkle tree is good enough for the
time being, and will likely implement stronger security soon enough.
Contributors (individuals, teams) need to provide a public key before
submitting, and the mirror source (authority) just checks against
the author's signature
Ideally, this signature check would be implemented as a server-side git
hook, so that a push would be automatically rejected if any of the
pushed commits lacked a good signature.
and signs (1) and (2) with its own key
(official portage tree root key X). That way, in the end, it's
enough to announce only one signing key for every tree.
Or just rely on signed commits in git. We can automatically generate an
empty signed commit with the root key every 30 minutes or something like
that.
(It's easier with binhosts, because all you need to sign is Packages{,gz}.)
Yes, much easier. We might also want to embed signatures directly in
each binary package, so that they can be independently verified without
needing a copy of the original Packages file.
--
Thanks,
Zac
Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
On 03/08/2015 07:59 AM, Patrick Schleizer wrote: Zac Medico: On 03/06/2015 09:50 AM, Mark Kubacki wrote: We're on the same side here. Do we have numbers showing the ratio portage used with defaults vs. where [webrsync-gpg] is described in many hardening guides for gentoo and widely used among the security conscious applies? DNS not being encrypted is just painting the whole picture. Point is, the default is that emerge --sync results in a transfer using RSYNC (or http). And by default you cannot compare the result with any authoritative source. Ideally, we can rely on security mechanisms built into git [1], possibly involving signed commits. [1] https://github.com/gentoo/gentoo-portage-rsync-mirror Then the question is, how secure are signatures when used wit hgit? And once we answer that question, the question is, is git secure enough for our needs? A while ago I wrote a blog post asking that question, referencing a lot related information, started a discussion and also posted this on the git mailing list. How safe are signed git tags? Only as safe as SHA-1 or somehow safer? [1] [2] Cheers, Patrick [1] https://www.whonix.org/blog/how-safe-are-signed-git-tags-only-as-safe-as-sha-1-or-somehow-safer [2] http://www.mail-archive.com/git@vger.kernel.org/msg61087.html For the time being, I think that git is secure enough for our needs, and I trust that git will implement stronger security soon enough. -- Thanks, Zac
Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
Zac Medico: On 03/06/2015 09:50 AM, Mark Kubacki wrote: We're on the same side here. Do we have numbers showing the ratio portage used with defaults vs. where [webrsync-gpg] is described in many hardening guides for gentoo and widely used among the security conscious applies? DNS not being encrypted is just painting the whole picture. Point is, the default is that emerge --sync results in a transfer using RSYNC (or http). And by default you cannot compare the result with any authoritative source. Ideally, we can rely on security mechanisms built into git [1], possibly involving signed commits. [1] https://github.com/gentoo/gentoo-portage-rsync-mirror Then the question is, how secure are signatures when used wit hgit? A while ago I wrote a blog post asking that question, referencing a lot related information, started a discussion and also posted this on the git mailing list. How safe are signed git tags? Only as safe as SHA-1 or somehow safer? [1] [2] Cheers, Patrick [1] https://www.whonix.org/blog/how-safe-are-signed-git-tags-only-as-safe-as-sha-1-or-somehow-safer [2] http://www.mail-archive.com/git@vger.kernel.org/msg61087.html
Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
On 03/06/2015 09:50 AM, Mark Kubacki wrote: We're on the same side here. Do we have numbers showing the ratio portage used with defaults vs. where [webrsync-gpg] is described in many hardening guides for gentoo and widely used among the security conscious applies? DNS not being encrypted is just painting the whole picture. Point is, the default is that emerge --sync results in a transfer using RSYNC (or http). And by default you cannot compare the result with any authoritative source. Ideally, we can rely on security mechanisms built into git [1], possibly involving signed commits. [1] https://github.com/gentoo/gentoo-portage-rsync-mirror -- Thanks, Zac
Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
On Sat, 07 Mar 2015 15:26:26 -0800 Zac Medico zmed...@gentoo.org wrote: On 03/06/2015 09:50 AM, Mark Kubacki wrote: We're on the same side here. Do we have numbers showing the ratio portage used with defaults vs. where [webrsync-gpg] is described in many hardening guides for gentoo and widely used among the security conscious applies? DNS not being encrypted is just painting the whole picture. Point is, the default is that emerge --sync results in a transfer using RSYNC (or http). And by default you cannot compare the result with any authoritative source. Ideally, we can rely on security mechanisms built into git [1], possibly involving signed commits. [1] https://github.com/gentoo/gentoo-portage-rsync-mirror Actually, git makes it nearly impossible to get the correct info required to re-process the git commit signature. It is all embedded into the commit itself, but not in a way for gpg to be able to re-verify it. Git relies on the issuer's gpg verification status which it records in it's data before the push. So, without some major hacking on git data, it is not viable for routine verification purposes. When we move from cvs to git, newer git makes it possible to git push --sign. That info is available on the recieving server and the receiving server also runs gpg to verifiy the incoming data. Only problem there is git does not store that data. There is however a hook that gathers the info and saves it in git's metadata for that repo. That makes it possible to run a verification on the repo at any other time. Not just during the recieve operation. When we do move to a git tree. My information is that pushes will not contain a signed manifest like they are now for cvs. Instead the Manifest files will be generated for the rsync distribution tree and signed with gentoo gpg key. Replicating the existing tree structure. I will likely have a patch for portage very soon which uses gkeys libs to verify the Manifests. gkeys- is able to verify the Manifest files now if the gentoo-devs keys are installed. Main questions for now is. Do we want to have a post sync hook that checks the tree for invalid Manifest sigs? Or do we just have it verify the manifest for the pkg at build/merge time? Or both? -- Brian Dolbec dolsen
Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
On Sat, 07 Mar 2015 18:31:44 -0800 Zac Medico zmed...@gentoo.org wrote: On 03/07/2015 05:24 PM, Brian Dolbec wrote: On Sat, 07 Mar 2015 15:26:26 -0800 Zac Medico zmed...@gentoo.org wrote: On 03/06/2015 09:50 AM, Mark Kubacki wrote: We're on the same side here. Do we have numbers showing the ratio portage used with defaults vs. where [webrsync-gpg] is described in many hardening guides for gentoo and widely used among the security conscious applies? DNS not being encrypted is just painting the whole picture. Point is, the default is that emerge --sync results in a transfer using RSYNC (or http). And by default you cannot compare the result with any authoritative source. Ideally, we can rely on security mechanisms built into git [1], possibly involving signed commits. [1] https://github.com/gentoo/gentoo-portage-rsync-mirror Actually, git makes it nearly impossible to get the correct info required to re-process the git commit signature. It is all embedded into the commit itself, but not in a way for gpg to be able to re-verify it. Git relies on the issuer's gpg verification status which it records in it's data before the push. So, without some major hacking on git data, it is not viable for routine verification purposes. Maybe we can use the relatively recently added git verify-commit command [1]. If we run that command with --verbose, then we can use that to verify that that a commit was signed with a trusted key. Shouldn't verification of the HEAD commit be enough to vouch for the integrity of the entire tree? [1] https://github.com/git/git/commit/d07b00b7f31d0cb6675b4bdba269ce7f087ddd24 GREAT! So, same as for push --sign, we just need to configure a replacement gpg command for git that uses gkeys instead of gpg directly. That will simplify things over the previous. A replacement gpg command is needed because of the way gkeys stores the developer keys in separate keyrings. gkeys determines which keyring to use and runs gpg with the correct settings. It is also capable of searching is db for the correct keyring to verify against as well. -- Brian Dolbec dolsen
Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
On 03/07/2015 05:24 PM, Brian Dolbec wrote: On Sat, 07 Mar 2015 15:26:26 -0800 Zac Medico zmed...@gentoo.org wrote: On 03/06/2015 09:50 AM, Mark Kubacki wrote: We're on the same side here. Do we have numbers showing the ratio portage used with defaults vs. where [webrsync-gpg] is described in many hardening guides for gentoo and widely used among the security conscious applies? DNS not being encrypted is just painting the whole picture. Point is, the default is that emerge --sync results in a transfer using RSYNC (or http). And by default you cannot compare the result with any authoritative source. Ideally, we can rely on security mechanisms built into git [1], possibly involving signed commits. [1] https://github.com/gentoo/gentoo-portage-rsync-mirror Actually, git makes it nearly impossible to get the correct info required to re-process the git commit signature. It is all embedded into the commit itself, but not in a way for gpg to be able to re-verify it. Git relies on the issuer's gpg verification status which it records in it's data before the push. So, without some major hacking on git data, it is not viable for routine verification purposes. Maybe we can use the relatively recently added git verify-commit command [1]. If we run that command with --verbose, then we can use that to verify that that a commit was signed with a trusted key. Shouldn't verification of the HEAD commit be enough to vouch for the integrity of the entire tree? [1] https://github.com/git/git/commit/d07b00b7f31d0cb6675b4bdba269ce7f087ddd24 -- Thanks, Zac
Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
On 03/06/15 08:53, Mark Kubacki wrote: 2015-03-06 1:56 GMT+01:00 Rick Zero_Chaos Farina zeroch...@gentoo.org: tl;dr webrsync-gpg is a built in feature of the package manager which OPTIONALLY adds a significant amount of security against the attacks described on your website. This is not currently the default setting, however, it is described in many hardening guides for gentoo and widely used among the security conscious. Without numbers backing that up this is speculation. 5,7,16,38,42. There are some numbers to back up what I'm saying. I have been doing security work for over 15 years and I'm a professional pen-tester. If you want to read the portage code to verify what I said that's fine, but I'm reasonably confident I distilled what portage does into english. Given the default settings (without webrsync-gpg)…: (8) Wrong software installation. Observe the DNS requests for the rsync- or webrsync mirror. They're not encrypted and give you a nice heads-up. Yup, dns is basically never encrypted, this is not new information or a new attack. A. (data in transit) It's almost never HTTPS and/or without authentication, so you can easily proceed to hijacking the connection. - Primed that way (DNS) insert a new rule into a router (or nameserver) along the path or within the DC to redirect the transaction. (See quantum insert.) Yup, this was discussed, however, it doesn't matter, and I'll explain why. The portage tree itself is a tarball with a signature attached, that means that short of coercion, the information in the portage tree should be correct (in the case of webrsync-gpg). The Manifest file for each package contains a sha256, sha512, and whirlpool hash for each file (including the source tarballs which would be downloaded to install) and ALL of them must match. Good luck modifying the file and getting all three hashs to match, I would suggest that is statistically impossible. Yes, an attacker could easily pass any file they like, but portage would fail to validate it and refuse to continue. B. (data at rest) Bribe or coerce the owner of the (portage tree) mirror. Manifests and ebuilds are not centrally signed and there is no authoritative signing transparency/record (see certificate transparency). Only the portage tree is centrally signed, and currently the manifest signatures aren't even verified automatically at this point. Yes, I completely agree that a gentoo dev could be coerced or bribed to add malicious code to the repository which would then get signed and shipped with the secure tarball. This avenue of attack is very difficult to stop. If would be cool to have some kind of automated check for malicious codes, however, I doubt it would be all that effective. -Zero signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
Hi, it was naive of me to attempt to create such a comparison table. Takes much more time than I have available for this. It was to be expected that there are disagreements and I cannot resolve them without checking the code myself and perhaps without coming up with proof of concept exploitation code to settle it. To prevent spreading false information, I took that wiki page offline. If someone else wants to maintain such a wiki comparison page, I could still help with hosting, mediawiki markup and such stuff. Sorry for the noise! Your answered were appreciated and helpful! We had somewhat a bad timing. I am sure Vlad in the Portage and Updater Security thread is much more knowledgeable, realistic and dedicated. (I am not part of the TUF team, just interested in their work.) Cheers, Patrick
Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
2015-03-06 1:56 GMT+01:00 Rick Zero_Chaos Farina zeroch...@gentoo.org: tl;dr webrsync-gpg is a built in feature of the package manager which OPTIONALLY adds a significant amount of security against the attacks described on your website. This is not currently the default setting, however, it is described in many hardening guides for gentoo and widely used among the security conscious. On 03/06/15 08:53, Mark Kubacki wrote: Without numbers backing that up this is speculation. 2015-03-06 16:20 GMT+01:00 Rick Zero_Chaos Farina zeroch...@gentoo.org: 5,7,16,38,42. There are some numbers to back up what I'm saying. I have been doing security work for over 15 years and I'm a professional pen-tester. If you want to read the portage code to verify what I said that's fine, but I'm reasonably confident I distilled what portage does into english. We're on the same side here. Do we have numbers showing the ratio portage used with defaults vs. where [webrsync-gpg] is described in many hardening guides for gentoo and widely used among the security conscious applies? DNS not being encrypted is just painting the whole picture. Point is, the default is that emerge --sync results in a transfer using RSYNC (or http). And by default you cannot compare the result with any authoritative source. -- Mark
Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
I used the footnote numbers to reference the attacks. I am afraid, this might cause some confusion. The numbers you have used won't stay stable. Those were autogenerated numbers of footnotes. As footnotes change, these numbers change. To keep your post understandable, I created a snapshot before modifying footnotes: http://www.webcitation.org/6Wo9Cb2ox However, numbers (1), (2), (3), etc. that won't be automatically changed, have just been added now. Rick Zero_Chaos Farina: webrsync-gpg would appear to mitigate Actually, I was aware of it. The issue is, signing is not everything. Signatures need a validity range. Otherwise mirrors can also show half a year etc. old signatures that are valid. See also: http://blog.ganneff.de/blog/2008/09/23/valid-until-field-in-release-f.html attacks 3, 11, and 12. There was no attack 3. Now, before we talk past each other, would you mind to repost by referencing attack by name or by their new, real numbers? Cheers, Patrick
Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
On 03/05/15 14:14, Patrick Schleizer wrote: I used the footnote numbers to reference the attacks. I am afraid, this might cause some confusion. The numbers you have used won't stay stable. Those were autogenerated numbers of footnotes. As footnotes change, these numbers change. To keep your post understandable, I created a snapshot before modifying footnotes: http://www.webcitation.org/6Wo9Cb2ox However, numbers (1), (2), (3), etc. that won't be automatically changed, have just been added now. HA, my fault, sorry about that. Actually, I was aware of it. The issue is, signing is not everything. Signatures need a validity range. Otherwise mirrors can also show half a year etc. old signatures that are valid. See also: http://blog.ganneff.de/blog/2008/09/23/valid-until-field-in-release-f.html attacks 3, 11, and 12. There was no attack 3. Now, before we talk past each other, would you mind to repost by referencing attack by name or by their new, real numbers? Well now there is an attack 3 :-) webrsync-gpg would ALERT the user in the case of attack 3. Portage checks the timestamp file from inside the gpg signed snapshot and alerts the user if the last sync was too long ago. In the case of a freeze attack, it should alert the user that the sync is old. Not that it fixes the attack, but it won't go unnoticed for long. Likewise, webrsync-gpg would also completely prevent 7 and 8. The snapshot is the entire tree, so it is not possible to mix and match without modifying the signed tarball. Nor would it be possible to provide the user with the wrong package since the checksums from inside the signed portage tarball wouldn't match if the source package was traded for a different one. Attack 8 shouldn't work either, as the checksums for everything are protected in the gpg signed portage tarball it should not be possible to trade out a source tarball for a different one. While gentoo doesn't typically use binary packages, it does have the support for it. Nothing in the binary package installation is protected by signatures, so I would expect this kind of attack to be possible when installing a binary package. Might be non-trivial to do, but certainly possible. Attack 9 won't work either, assuming the user can avoid the freeze attack (3) the user will have an up to date knowledge of what it expects on the mirrors and will simply ask other mirrors for the right file in case of 404 or bad checksum. tl;dr webrsync-gpg is a built in feature of the package manager which OPTIONALLY adds a significant amount of security against the attacks described on your website. This is not currently the default setting, however, it is described in many hardening guides for gentoo and widely used among the security conscious. -Zero_Chaos signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Security and Comparison of Portage with other Package Managers
On 03/05/15 09:49, Patrick Schleizer wrote: Hi, I am currently working on a comparison of package managers in which Portage is part of. https://www.whonix.org/wiki/Comparison_Of_Package_Managers Would you be interested to check if the current assessments are correct and/or to fill the remaining gaps? Where the comparison table is hosted or licensing (as long as it's Libre Software) doesn't matter much to me. Edits can be made by both anonymous and registered users. Those need to be verified by admins before they go visible by default for everyone. If you like to have an account without that limitation, that is also possible. Cheers, Patrick Looking at the table, it appears to be unaware of using FEATURES=webrsync-gpg instead of standard rsync. We offer a full copy of the repo which is compressed and gpg signed which would seem to mitigate a lot of the attacks in your table. Not that I nessesarily agree that some of them even qualify as attacks, but webrsync-gpg would appear to mitigate attacks 3, 11, and 12. Attack 7 is possible, but the user would know since emerge tells you every time it is run how long it has been since a successful update based on a timestamp in the portage tree which for webrsync-gpg the attacker cannot modify. Attack 14 is not possible in gentoo as emerge will jump from mirror to mirror until it successfully gets the desired file. One would have to own all the mirrors (or at least hijack dns) to stop the user from getting a file, but at that point it's no longer a malicious mirror attack. I used the footnote numbers to reference the attacks. -Zero signature.asc Description: OpenPGP digital signature
