From owner-freebsd-security@FreeBSD.ORG Tue May 17 22:54:29 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 32D8A16A4CE for ; Tue, 17 May 2005 22:54:29 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 838EF43D5F for ; Tue, 17 May 2005 22:54:28 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j4HMoOLm055682; Tue, 17 May 2005 18:50:24 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j4HMoNqR055681; Tue, 17 May 2005 18:50:23 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 17 May 2005 18:50:23 -0400 From: David Schultz To: Poul-Henning Kamp Message-ID: <20050517225023.GA55428@VARK.MIT.EDU> Mail-Followup-To: Poul-Henning Kamp , , freebsd-security@FreeBSD.ORG References: <245f0df105051318564b1ffb6b@mail.gmail.com> <94145.1116037219@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94145.1116037219@critter.freebsd.dk> cc: freebsd-security@FreeBSD.ORG cc: "Drew B. \[Security Expertise/Freelance Security research\]." Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 22:54:29 -0000 On Sat, May 14, 2005, Poul-Henning Kamp wrote: > In message <245f0df105051318564b1ffb6b@mail.gmail.com>, "Drew B. [Security Expe > rtise/Freelance Security research]." writes: > > >this sounds like trying to solve in the OS a problem that can only > >be solved in the application. Is there something more subtle > >that's going on? > > Well, the application could theoretically do something and Colin > advocated it this morning: make the crypto code footprint data > and key independent. While possible, it is both very tricky to > do (in particular in highlevel languages) and generally found > to be much slower than speed-optimized code. Some colleagues and I have a paper in submission that addresses the issue of key-dependent control flow, much as you describe. You're right that it's hard to do in a high-level language; you'd be surprised (okay, maybe not) at the sort of vulnerabilities that are introduced into perfectly reasonable C programs by gcc. The issue of how to address key-dependent memory accesses is harder to address in general. Consider RC5, which has some key-dependent table lookups built into the algorithm. The Dan Bernstein paper I cited in my last email has some good guidelines about how to do better, but it doesn't offer a generic solution. HTT aside, there are some interesting open problems here. > The fact that one user would be able to spy on another users editor > application and be able to extract for instance the word lengths > and layout of a document would also be considered a major security > problem in many installations. > > Or how about just being able to monitor another customers apache > instance to figure out how much traffic they get and which pages > they get it on ? If you're willing to wait a day or two, you don't even need to have a local account: http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html I'm just reading Colin's paper now---so as you say, it sounds like the punchline is that having a local account buys you a few orders of magnitude in attack time. Kewl. > The correct (technical) workaround (IMO) is to restrict HTT to be > used only for threads from the same process. That's probably satisfactory, but if you want to be really picky, even that isn't quite sufficient. Consider a Java virtual machine running web applications, for instance. There's one process, but potentially many different protection domains within it. The OS would need to understand that in order to completely prevent this kind of timing attack. (In FreeBSD, perhaps something could be done with multiple KSEGs...)