From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out02.mta.xmission.com ([166.70.13.232]:38941 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752334AbbJBQK2 (ORCPT ); Fri, 2 Oct 2015 12:10:28 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Ben Hutchings Cc: stable@vger.kernel.org, Greg Kroah-Hartman , Sasha Levin , Jiri Slaby , Willy Tarreau , Li Zefan References: <87a8s2a7kc.fsf@x220.int.ebiederm.org> <1443753950.2730.164.camel@decadent.org.uk> <87k2r6ueyd.fsf@x220.int.ebiederm.org> Date: Fri, 02 Oct 2015 11:01:31 -0500 In-Reply-To: <87k2r6ueyd.fsf@x220.int.ebiederm.org> (Eric W. Biederman's message of "Thu, 01 Oct 2015 22:28:10 -0500") Message-ID: <87vbaptg2s.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [PATCHES] Bind mount escape fixes (CVE-2015-2925) Sender: stable-owner@vger.kernel.org List-ID: ebiederm@xmission.com (Eric W. Biederman) writes: > Ben Hutchings writes: > >> On Thu, 2015-10-01 at 11:15 -0500, Eric W. Biederman wrote: >>> With a strategically placed rename bind mounts can be tricked into >>> giving processes access to the entire filesystem instead of just a piece >>> of it. This misfeature has existed since bind mounts were introduced >>> into the kernel. This issue has been fixed in Linus's tree and below >>> are my tested backports of the fixes to 4.2.1, 4.1.8, 3.18.21, 3.14.53, >>> 3.12.48, 3.10.89, 3.4.109, 3.2.71, 2.6.32.68. All of the kernels >>> currently listed as being active. >> >> I'm not convinced that this is necessary for the 2.6.32, 3.2 or 3.4 >> stable branches. While it is possible for an administrator to screw >> this up, there is no possibility of a user being able to exploit this >> from a user namespace where they have namespaced-CAP_SYS_ADMIN. > > It is cheap and easy to fix. I made and tested the changes. So why > not. > Having thought about this I definitely think we need this on older kernels. I am aware of at least one piece of software that predates 2.6.32 is vulnerable to this escape. The software in all innocence bind mounted a users /home directory into a root filesystem that was stored in the users /home directory. That is enough to allow the escape with a simple unprivileged rename. So since this is actually exploitable on real userspace software that predates 2.6.32 I think this fix needs to be backported, as it is not a theoretical issue. Eric