Re: MITM attacks against portsnap and freebsd-update
On 4/10/14, David Noel wrote: >> I'm not convinced that a rototil of the protocol and all the associated >> storage duplication is worth the effort. > > As far as portsnap is concerned I'm not convinced that ANY amount of > effort is worth it. That is why I was hoping to start a conversation > on the possibility of phasing it out. > >> It's better in my mind to commit one of the patches to sandbox gzip >> with Capsicum... > > Portsnap also passes un-verified files to tar, so that would need to > be patched too. > >> ...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. > > I agree that what you're proposing is probably the simplest solution, > but I'm not convinced that it would guarantee system security. Nothing > against Robert Watson, but sandboxes are always being broken out of. > There's a history of vulnerabilities in the jail subsystem, isn't it > likely that someone some day will find a bug in Capsicum? As unlikely > as it seems that someone would be able to pull off a MITM attack, > posses a tar or gzip 0day, and also posses a Capsicum 0day, there is > -- like Murphy's law -- that old saying* "Any bug that can be > exploited will be." > > *I definitely just made that up, but I do firmly believe it to be true. > >> 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. > > Sorry. A freeze attack is similar to a replay attack. In a replay > attack an attacker would feed the system an older, exploitable version > of the software being updated so that they could break in. A freeze > attack is when an attacker feeds the system the same version of the > software being updated so that critical updates are not installed. > While portsnap and freebsd-update do check to ensure that what's being > updated is no older than what's currently on the system they do not > check to ensure that what's being updated is not the same version as > what's currently installed. > > -David > A paper I found useful back when I first started digging into portsnap and freebsd-update is titled "Package Management Security" and can be found at ftp://ftp.cs.arizona.edu/reports/2008/TR08-02.pdf. It reviews common attacks against package management systems, analyzes both APT and YUM, and points out a number of flaws in them. Many of the attacks discussed also apply to the design of our ports tree management and binary update systems. A very good read for anyone interested in that sort of thing. Baptiste, this conversation made me think of your work on pkgng (I love it, by the way!), so I thought I'd cc you as well. I don't know how knowledgeable you are about common attack vectors against package management systems so I thought maybe this paper would be of some interest to you. I realize I cut off the first email, so if you're curious and didn't see my initial message you can find it here: http://www.mail-archive.com/freebsd-security@freebsd.org/msg04777.html Regards, David Noel ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: MITM attacks against portsnap and freebsd-update
> I'm not convinced that a rototil of the protocol and all the associated > storage duplication is worth the effort. As far as portsnap is concerned I'm not convinced that ANY amount of effort is worth it. That is why I was hoping to start a conversation on the possibility of phasing it out. > It's better in my mind to commit one of the patches to sandbox gzip > with Capsicum... Portsnap also passes un-verified files to tar, so that would need to be patched too. > ...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. I agree that what you're proposing is probably the simplest solution, but I'm not convinced that it would guarantee system security. Nothing against Robert Watson, but sandboxes are always being broken out of. There's a history of vulnerabilities in the jail subsystem, isn't it likely that someone some day will find a bug in Capsicum? As unlikely as it seems that someone would be able to pull off a MITM attack, posses a tar or gzip 0day, and also posses a Capsicum 0day, there is -- like Murphy's law -- that old saying* "Any bug that can be exploited will be." *I definitely just made that up, but I do firmly believe it to be true. > 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. Sorry. A freeze attack is similar to a replay attack. In a replay attack an attacker would feed the system an older, exploitable version of the software being updated so that they could break in. A freeze attack is when an attacker feeds the system the same version of the software being updated so that critical updates are not installed. While portsnap and freebsd-update do check to ensure that what's being updated is no older than what's currently on the system they do not check to ensure that what's being updated is not the same version as what's currently installed. -David ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: MITM attacks against portsnap and freebsd-update
[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 pgpx9sqWDt_0g.pgp Description: PGP signature
