From owner-freebsd-current@freebsd.org Thu Jun 9 13:02:56 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 8278DB6ECC6 for ; Thu, 9 Jun 2016 13:02:56 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49AA91207 for ; Thu, 9 Jun 2016 13:02:56 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-io0-x233.google.com with SMTP id 5so36968341ioy.1 for ; Thu, 09 Jun 2016 06:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=oxJ7YAtpb6CiJEazSRGwm5jqWTCIhMwdKWE0diNQhDs=; b=XFxBASmaqKdbbfqqbUfMi05NvSr7wBy87+ReJXHhccbjYN1Zg9hx5xVoNs6sCWcnnM NQQIngEiXLNLJTnvO0C3ZvZynyLaRPkQMr3DC1ynSrCTeSJSyR7z608dfO5oVlqKCAcj jpoyK6wCYO56PGwou4ZFSUQtKE8xa01HVoDUicyns0XR9Ib5QJvggn7l/iYvqzfCg2ZH R0dL+efH/8Qcs/hss2e6yMNKwRyQ+NWQLG5u62on8qtmDy2+8CNE+YlDnzd/x7T51sRn fYNirENH7+9QKf9oKyxw51OGJ0WlKLPYJhkC6/Nunw61UQCM/5b40H8edtShrNN6gcaI i+mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=oxJ7YAtpb6CiJEazSRGwm5jqWTCIhMwdKWE0diNQhDs=; b=g7LHh8C1/ktsaOYcHaHGNSvSnrN/smlnx8N6pzfV5/w+YbyVyBXzLXUvUfN0tNjuvU 5ZFYSvRQCmIqf1Q6hZFDHwTEV8nIpD97r63xTsffVZ9vG7bC+yvaJUbsUXBXt+CxaUbT fTEgS7uNKcHF3EEONEjDwRlF4e55rX49nEW0lEreDlZqvQhW537m5/k731Fr/HzxdWje qJgbzOr0upZMyD1NhfuleTnGo0MZI+ibyH+Casfy0uvEN1vXiEEpD+CjZpStWPLmHXyN sfD3k84fJE+Iyy2Qgvb+I6Okjv3+kgL6r62ILtjLQGUQDuP4Iy8FFLkGPyxKBFhVfRd2 US8w== X-Gm-Message-State: ALyK8tLWk/Un9CpJIYD/0dksXiE/o2gXJZqFhy2G0s6OJViUkaU/Thqfm+GNaLJZEBQPAcuu X-Received: by 10.107.29.18 with SMTP id d18mr18960094iod.22.1465477375449; Thu, 09 Jun 2016 06:02:55 -0700 (PDT) Received: from mutt-hardenedbsd ([137.122.64.8]) by smtp.gmail.com with ESMTPSA id o201sm3130607ioe.15.2016.06.09.06.02.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jun 2016 06:02:54 -0700 (PDT) Date: Thu, 9 Jun 2016 09:02:52 -0400 From: Shawn Webb To: David Chisnall Cc: "O. Hartmann" , FreeBSD CURRENT Subject: Re: CURRENT: bhyve and Kernel SamePage Mergin Message-ID: <20160609130252.GA55960@mutt-hardenedbsd> References: <20160608170102.6a0ee504.ohartman@zedat.fu-berlin.de> <2DE58803-9030-44D3-9AD3-BD189CBA002E@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2DE58803-9030-44D3-9AD3-BD189CBA002E@FreeBSD.org> X-Operating-System: FreeBSD mutt-hardenedbsd 11.0-ALPHA2-HBSD FreeBSD 11.0-ALPHA2-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.6.0 (2016-04-01) 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 13:02:56 -0000 Hey David, I'm responding inline. On Thu, Jun 09, 2016 at 09:18:40AM +0100, David Chisnall wrote: > If this paper is the one that I think it is, then I was one of the reviewers. Their attack is neat, but it depends quite a lot on being able to deterministically trigger deduplication. Their proof-of-concept exploit was on Windows (and JavaScript attack was really fun) and I???m 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. > > We don???t currently have a FreeBSD implementation, but if someone wanted to provide one then a defence against this attack would be fairly simple: count the number 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 being 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 pathological case that most memory deduplication implementations need to handle (as well as being a security hole, it???s also a big performance killer). Competely agreed. This is a "nothing to see here" situation. The paper simply doesn't apply to FreeBSD. > > Kib has been working on ASLR for FreeBSD (I think it???s in 11?), but at this point it???s more of a checkbox item than a serious mitigation technique. It adds a little bit of work for attackers, but there are so many attacks that can bypass ASLR even with strong entropy that it just increases the work factor slightly. If you???re running code written in C, then you???re better off relying on Capscium compartmentalisation to limit what the attacker can do once they???ve compromised it. Kib's ASR implementation hasn't made it to HEAD, yet. It differs from ASLR in pretty drastic ways. Using heap spraying attacks, an attacker will easily be able to disable the ASR implementation Kib has proposed. The same does not hold true for the proper ASLR implementation that has existed for a number of years--HardenedBSD's. Simply forcing address space fragmentation should not disable ASLR, which is the case for FreeBSD's ASR. Kib's implementation requires a lot of further work, especially in regards to stack and shared page randomization, which doesn't exist in his patch. He views stack and shared page randomization outside the scope of ASR and I have no clue why as no explanation has been given. While ASLR bypasses exist (ROP, SROP, JROP, etc.), they require a number of additional vulnerabilities to be able to effectively control [ER]IP. Just like any security technology, ASLR isn't meant to be the end-all-be-all of security, but just one more layer in a defense-in-depth strategy. The more layers an attacker has to punch through, the higher the burden. Capsicum would indeed be something to look into, but is heavy-handed and requires modification of source code. Capsicum cannot be applied to proprietary applications without coordination from the vendor, whereas ASLR can be. I like Capsicum, but integrating "ALL THE THINGS!" with it takes a lot of work. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE