From owner-freebsd-current@freebsd.org Thu Jun 9 17:00:20 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9067B706A2 for ; Thu, 9 Jun 2016 17:00:20 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A26C1D9B; Thu, 9 Jun 2016 17:00:20 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bB3JU-001ZjL-AT>; Thu, 09 Jun 2016 19:00:12 +0200 Received: from x5ce139cf.dyn.telefonica.de ([92.225.57.207] helo=thor.walstatt.dynvpn.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (envelope-from ) id <1bB3JU-001rKg-0J>; Thu, 09 Jun 2016 19:00:12 +0200 Date: Thu, 9 Jun 2016 19:00:09 +0200 From: "O. Hartmann" To: David Chisnall Cc: FreeBSD CURRENT , Shawn Webb Subject: Re: CURRENT: bhyve and Kernel SamePage Mergin Message-ID: <20160609190009.071fbde6.ohartman@zedat.fu-berlin.de> In-Reply-To: <2DE58803-9030-44D3-9AD3-BD189CBA002E@FreeBSD.org> References: <20160608170102.6a0ee504.ohartman@zedat.fu-berlin.de> <2DE58803-9030-44D3-9AD3-BD189CBA002E@FreeBSD.org> Organization: FU Berlin X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/bzAVfP5w/QidhSo/WkVjMPQ"; protocol="application/pgp-signature" X-Originating-IP: 92.225.57.207 X-ZEDAT-Hint: A X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 17:00:20 -0000 --Sig_/bzAVfP5w/QidhSo/WkVjMPQ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am Thu, 9 Jun 2016 09:18:40 +0100 David Chisnall schrieb: > If this paper is the one that I think it is, then I was one of the review= ers. Their > attack is neat, but it depends quite a lot on being able to deterministic= ally trigger > deduplication. Their proof-of-concept exploit was on Windows (and JavaSc= ript attack > was really fun) and I=E2=80=99m not convinced that it would work reliably= on Linux or VMWare > ESX, which both defer deduplication for as long as possible to avoid NUMA= -related > overheads. >=20 > We don=E2=80=99t currently have a FreeBSD implementation, but if someone = wanted to provide one > then a defence against this attack would be fairly simple: count the numb= er of CoW > faults that a process is receiving and if it reaches a certain threshold = then remove > all of its memory from the set of eligible pages. The attack relies on b= eing able to > repeatedly trigger CoW faults and time whether they occur, with the same = set of pages. > At least some existing implementations will make this impossible as these= pages will > repeatedly be deduplicated and then duplicated and this is already a path= ological case > that most memory deduplication implementations need to handle (as well as= being a > security hole, it=E2=80=99s also a big performance killer). >=20 > Kib has been working on ASLR for FreeBSD (I think it=E2=80=99s in 11?), b= ut at this point it=E2=80=99s > more of a checkbox item than a serious mitigation technique. It adds a l= ittle bit of > work for attackers, but there are so many attacks that can bypass ASLR ev= en with strong > entropy that it just increases the work factor slightly. If you=E2=80=99= re running code > written in C, then you=E2=80=99re better off relying on Capscium compartm= entalisation to limit > what the attacker can do once they=E2=80=99ve compromised it. >=20 > David >=20 > > On 8 Jun 2016, at 16:01, O. Hartmann wrot= e: > >=20 > > A couple of days I got as a responsible personell for a couple of syste= ms a warning > > about the vulnerabilities of the mechanism called "Kernel SamePage Merg= in". On this > > year's IEEE symposion there has been submitted a paper by Bosman et al.= , 2016, > > describing an attack on KSM. This technique, also referred to as memory= /page > > deduplication, seems to be vulnerable by design under certain circumsta= nces. I guess > > the experts of the readers here do already know, but I consider myself = a non-expert > > and therefore, I'd like to ask about the status of that kind of develop= ment in > > FreeBSD. I read about a project of last year's Google Summer of Code 20= 15 targetting > > KSM on FreeBSD. > >=20 > > In Linux, this deduplication techniques is implemented since kernel 2.6= .38 and Windows > > Kernel uses this techniques since Windows 8.1 and sibblings (also Windo= ws Server). We > > were strongly advised to disable those "features" in Windows clients, s= ervers and > > Linux servers, if used. > >=20 > > Other papers describe successful attacks on memory contents and ASLR by= misusing KSM. > > On Windows, mmap() entropy is 19bit, on Linux usually 28bit. And FreeBS= D (if > > planned/used/already implemented?)?=20 > >=20 > > If you are interested I could provide links or PDFs of the papers I alr= eady gathered > > about that subject (it is not much, simply google for "KSM FReeBSD" or = KSM > > deduplication ASLR). > >=20 > > Thanks in advance, > >=20 > > oh =20 >=20 Hello David, sorry for the lack of references.=20 Bosman et al., 2016: doi: 10.1109/SP.2016.63 (http://www.ieee-security.org/TC/SP2016/papers/0824a987.pdf), this paper ha= s been subject of a warning given to institutions. An older one, but also interesting, is Xiao et al., 2013: doi: 10.1109/DSN.2013.6575349 (http://www.cs.wm.edu/~hnw/paper/memdedup.pdf)=20 and this one=20 Barresi et al., 2015 (https://www.usenix.org/node/191961). The first paper is of (my) concern, since it triggered some interests and c= ouriosities of mine. Regards, Oliver Hartmann --Sig_/bzAVfP5w/QidhSo/WkVjMPQ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXWaCZAAoJEOgBcD7A/5N8DTQH/j+FFgPrSNxLnuIVAoVeTiF0 +1wwZqWjdtvQWSSLgzlMATUQ3U3wQFcYj5rAqXB0Mt7YpRVC0UOd3OsBre0y3F4O +mw/I8gYHnGJCDweLSDa7HhhhW8HhLr8xHigVxFXrVU4FFcVOGyRWEQg64OsyJ8L PCvNekcCwwVZYR3KC0cG2UwQpZHvWebYLnbI7sfjb1DaIImc9GRPep7msDNSPbG3 r8e0LJDhGCjKTXtl7eXCWofERL8R8KoWKos/9d8TZlmh9N86F3K3ksDX3w8Ds6Li 10GjNo0ppa7W5F165QuAkVeBAkh8Auy2a4GbRJfNTP407Z2Hn+OuIPMLw0XzgFg= =Dxth -----END PGP SIGNATURE----- --Sig_/bzAVfP5w/QidhSo/WkVjMPQ--