From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 16 21:53:36 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 730EC106568D; Sun, 16 Aug 2009 21:53:36 +0000 (UTC) (envelope-from daw@cs.berkeley.edu) Received: from taverner.cs.berkeley.edu (taverner.CS.Berkeley.EDU [128.32.168.222]) by mx1.freebsd.org (Postfix) with ESMTP id 398ED8FC15; Sun, 16 Aug 2009 21:53:36 +0000 (UTC) Received: from taverner.cs.berkeley.edu (localhost.localdomain [127.0.0.1]) by taverner.cs.berkeley.edu (8.14.2/8.14.2) with ESMTP id n7GL9JW5029607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Aug 2009 14:09:19 -0700 Received: (from daw@localhost) by taverner.cs.berkeley.edu (8.14.2/8.14.2/Submit) id n7GL9JNK029605; Sun, 16 Aug 2009 14:09:19 -0700 From: David Wagner Message-Id: <200908162109.n7GL9JNK029605@taverner.cs.berkeley.edu> To: rwatson@FreeBSD.org (Robert Watson) Date: Sun, 16 Aug 2009 14:09:19 -0700 (PDT) In-Reply-To: from "Robert Watson" at Aug 16, 2009 09:06:41 PM Secret-Bounce-Tag: 9a029cbee41caf2ca77a77efa3c13981 X-Mailer: ELM [version 2.5 PL6] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 16 Aug 2009 22:28:44 +0000 Cc: freebsd-hackers@FreeBSD.org, linux-kernel@vger.kernel.org, David Wagner , Oliver Pinter Subject: Re: Security: information leaks in /proc enable keystroke recovery X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2009 21:53:36 -0000 Thanks for the comments. > Beyond this, and assuming the correct implementation of the above, > we're into the grounds of classic trusted OS covert channel analysis, > against which no COTS UNIX OSes I'm aware of are hardened. This isn't to > dismiss these attacks as purely hypothetical -- we've seen some rather > compelling examples of covert channels being exploited in unexpected > and remarkably practical ways in the last few years (Steven Murdoch's > "Hot or Not" paper takes the cake in that regard, I think). To be pedantic, I'd say that the Usenix Security paper describes a side channel, not a covert channel. The paper shows how a malicious attacker can attack an unsuspecting victim application. Covert channels are when both the sender and the receiver are malicious and cooperating to transmit information from the sender to the receiver. In contrast, side channels arise when the "sender" is unintentionally and inadvertently leaking information that can be decoded by a malicious receiver, against the interests of the "sender". The attack in the paper is a side channel, not a covert channel. When it comes to covert channels, it is indeed reasonable to throw up your hands and say that defending against covert channels is basically impossible, so why bother? For side channels, though, it's less clear that this is a persuasive argument. I agree we certainly shouldn't discuss the keystroke recovery attack as hypothetical, because it is clearly not hypothetical: the authors implemented it and found that it works. > However, this next step up from "the kernel doesn't reveal information on > processes from other users" involves scheduler hardening, consideration > of inter-CPU/core/thread cache interactions, and so on -- things that we > don't have a good research, let alone production, OS understanding of. Indeed. A major challenge. Good to hear that, in its default configuration, FreeBSD does eliminate the attack vector described in the Usenix Security paper (the EIP/ESP leak). It seems a good starting point would be to limit access to information that we know can enable keystroke recovery -- as FreeBSD apparently already does, but Linux apparently does not.