Date: Thu, 10 Apr 2014 15:26:00 -0500 From: David Noel <david.i.noel@gmail.com> To: Brooks Davis <brooks@freebsd.org> Cc: freebsd-security@freebsd.org, bapt@FreeBSD.org, Colin Percival <cperciva@freebsd.org> Subject: Re: MITM attacks against portsnap and freebsd-update Message-ID: <CAHAXwYCLqXsASj3FJ8XuPFeg0iUPcj1ip2X72rcJBCKD27astw@mail.gmail.com> In-Reply-To: <CAHAXwYAE6dv7GYj4yrbUqQ06BXTB6MH_gPtYBsm7FYvCm6gBkw@mail.gmail.com> References: <CAHAXwYCGkP-o0VvMXj5S8-KNA45aTvy%2BsrjDL_=8-x9Dza5z5Q@mail.gmail.com> <20140410183330.GB31394@lor.one-eyed-alien.net> <CAHAXwYAE6dv7GYj4yrbUqQ06BXTB6MH_gPtYBsm7FYvCm6gBkw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/10/14, David Noel <david.i.noel@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHAXwYCLqXsASj3FJ8XuPFeg0iUPcj1ip2X72rcJBCKD27astw>