> 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"