I found a few bugs in portsnap and freebsd-update that I'd like to bring to the community's attention and hopefully recruit people to help fix. I mentioned them to Colin (their author) a few years ago and he agreed that they're issues that need to be addressed, but in the time since neither he nor I have been able to get around to fixing them. I'm hoping that someone reading this is able and willing to pitch in. I've also taken this to secteam@, but no one there's made any progress on them in the past 6 months so I figured it was time to approach the broader community. Surely there's a benevolent sh-savvy hacker out there who has time to take these on. They're pretty simple fixes -- the functionality that's needed exists in the scripts already, it just needs to be reused in a few key places. I also think it would be an appropriate time to discuss retiring portsnap. Problem Summary 1. Both portsnap and freebsd-update extract fetched data prior to its SHA256 verification. The extraction libraries used have a long history of bugs so it's reasonable to assume there might be more. Both freebsd-update and portsnap are run as root. Using a vulnerability in the decompression libraries an attacker who was MITM-capable could compromise any FreeBSD system running portsnap or freebsd-update. 2. The portsnap mirroring script (pmirror.sh) lacks of any sort of mechanism to verify the data prior to processing and mirroring it. Without this, mirrors are open to compromise via methods similar to those found in the client-side scripts (decompression library exploitation). It also means an attacker could feed a mirror a corrupt archive, opening users of that mirror to compromise. 3. Both portsnap and freebsd-update are vulnerable to freeze attacks. 4. The addition of subversion in base makes portsnap redundant. Solution Summary 1. A re-working of the snapshot hashing and hash verification process. 2. The addition of hashing and hash verification code to pmirror.sh. 3. The server-side inclusion of date-stamps, and strict client-side enforcement of expiration policies. 4. Retire portsnap. Details The functions of concern in portsnap.sh are fetch_snapshot(), fetch_update(), and fetch_snapshot_verify(). The lines of concern in pmirror.sh are 99-103, 121-125, 138-149, and 153-157 (using revision 257073). The functions of concern in freebsd-update.sh are fetch_metadata(), fetch_files_premerge(), and fetch_files(). Retiring Portsnap With the inclusion of svnlite in 10 I think the valid question comes up as to whether we really need the portsnap system or whether it could be safely retired. Obviously if the conclusion of that discussion is that we don't need it then these bug fixes would be unnecessary. The reason I see for it to be retired is that subversion allows us to easily and securely check out the ports tree. It's a one-line command: `svn co https://...`. Keeping it up-to-date it is another one-liner: `cd /usr/ports; svn update`. With the inclusion of svnlite in base, the portsnap code and servers acting as mirrors become redundant and seem like a waste of resources. PR's I've avoided filing PR's to give myself, Colin, or secteam@ the chance to fix these bugs first. Since none of us have had the time free to do so and because I'm now sharing these bugs publicly with the list I figure it would be an appropriate time to file PR's for them. MITM attacks against freebsd-update: http://www.freebsd.org/cgi/query-pr.cgi?pr=188429 MITM attacks against portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188428 Freeze attacks against freebsd-update: http://www.freebsd.org/cgi/query-pr.cgi?pr=188434 Freeze attacks against portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188430 MITM attacks against portsnap mirrors (pmirror.sh): http://www.freebsd.org/cgi/query-pr.cgi?pr=188432 Retiring portsnap: http://www.freebsd.org/cgi/query-pr.cgi?pr=188433 David Noel
[Trimming the list to -security plus Colin in hopes of reducing the number of partial conversations. Sending to four lists and an alias is a list etiquette violation.] [Also dropping the discussion of replacing portsnap since that is a mostly unrelated discussion.] On Thu, Apr 10, 2014 at 12:03:45PM -0500, David Noel wrote:> Problem Summary > > 1. Both portsnap and freebsd-update extract fetched data prior to its > SHA256 verification. The extraction libraries used have a long history > of bugs so it's reasonable to assume there might be more. Both > freebsd-update and portsnap are run as root. Using a vulnerability in > the decompression libraries an attacker who was MITM-capable could > compromise any FreeBSD system running portsnap or freebsd-update. > 2. The portsnap mirroring script (pmirror.sh) lacks of any sort of > mechanism to verify the data prior to processing and mirroring it. > Without this, mirrors are open to compromise via methods similar to > those found in the client-side scripts (decompression library > exploitation). It also means an attacker could feed a mirror a corrupt > archive, opening users of that mirror to compromise.These seem like serious issues and a verify-first design would have been better. That said, I'm not convinced that a rototil of the protocol and all the associated storage duplication is worth the effort. It's better in my mind to commit one of the patches to sandbox gzip with Capsicum which will protect from everything except filling the disk by denying gunzip the ability to do anything but write to the file opened by the script. That will protect all gzip users.> 3. Both portsnap and freebsd-update are vulnerable to freeze attacks.What do you mean by a freeze attack? I'm not familiar with this term and I didn't find this post, the PRs, or a quick Google search illuminating. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 326 bytes Desc: not available URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140410/c6a8db4b/attachment.sig>
Bryan Drewery
2014-Apr-10 23:38 UTC
Retiring portsnap [was MITM attacks against portsnap and freebsd-update]
On 4/10/2014 12:03 PM, David Noel wrote:> I found a few bugs in portsnap and freebsd-update that I'd like to > bring to the community's attention and hopefully recruit people to > help fix. I mentioned them to Colin (their author) a few years ago and > he agreed that they're issues that need to be addressed, but in the > time since neither he nor I have been able to get around to fixing > them. I'm hoping that someone reading this is able and willing to > pitch in. I've also taken this to secteam@, but no one there's made > any progress on them in the past 6 months so I figured it was time to > approach the broader community. Surely there's a benevolent sh-savvy > hacker out there who has time to take these on. They're pretty simple > fixes -- the functionality that's needed exists in the scripts > already, it just needs to be reused in a few key places. > > I also think it would be an appropriate time to discuss retiring portsnap. >[snip]> > With the inclusion of svnlite in 10 I think the valid question comes > up as to whether we really need the portsnap system or whether it > could be safely retired. Obviously if the conclusion of that > discussion is that we don't need it then these bug fixes would be > unnecessary. > > The reason I see for it to be retired is that subversion allows us to > easily and securely check out the ports tree. It's a one-line command: > `svn co https://...`. Keeping it up-to-date it is another one-liner: > `cd /usr/ports; svn update`. With the inclusion of svnlite in base, > the portsnap code and servers acting as mirrors become redundant and > seem like a waste of resources.Your report aside, I find portsnap to be far superior in security for ports and users. I wish it knew how to checkout source as well. 1. It only allows a secure checkout. You can't accidentally checkout svn:// or http://. 2. It blows away directories with updates. I've witnessed a trojaned ports checkout before. 'svn update' does not remove unexpected files, nor remove changes. Yes this is a decrease in usability when you've modified the file and want to keep the changes, but you can easily make a wrapper script to merge in your changes, or use SVN if you really want. 3. SVN too often gets into confusing situations on 'svn update' that require knowledge of how SVN works to resolve the conflict. Even I with my ~10 years of SVN experience I get confused often and frustrated when not even 'svn revert -R dir; svn up dir' will revert to the upstream version (I may have my example off, but that's the point, it's confusing.) 4. SVN asks the user to confirm the public key when first using the HTTPS repository. I worry this step will be done poorly by users. 5. SVN requires 'svn upgrade' sometimes, this is also confusing for users. 6. The way we do HTTPS is through mirrors only, if you pick the wrong mirror it's against hard for the user who doesn't know SVN to change to a different mirror. Portsnap already handles mirrors excellently by geo location. Teaching portsnap how to speak SVN, while still behaving the same, may cover my concerns. To be fair SVN does have its advantages: 1. Quicker updates for users. 2. Easier patch generation for PR submission. 3. Similarly, viewing your changes more easily. -- Regards, Bryan Drewery -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 553 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20140410/103aeb30/attachment.sig>