From owner-freebsd-security@FreeBSD.ORG Sat May 14 02:20:24 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 AADF416A4CE; Sat, 14 May 2005 02:20:23 +0000 (GMT) Received: from lists.soekris.com (lists.soekris.com [64.105.92.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCED543D7F; Sat, 14 May 2005 02:20:20 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by lists.soekris.com (8.12.11/8.12.11) with ESMTP id j4E2Ka1Y047755; Fri, 13 May 2005 19:20:37 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) To: "Drew B. [Security Expertise/Freelance Security research]." From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 14 May 2005 11:56:30 +1000." <245f0df105051318564b1ffb6b@mail.gmail.com> Date: Sat, 14 May 2005 04:20:19 +0200 Message-ID: <94145.1116037219@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-security@freebsd.org cc: das@freebsd.org 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: Sat, 14 May 2005 02:20:24 -0000 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. And while that could solve the immediate panic with OpenSSL and similar, it does not solve the general problem that you can spy very efficiently on the behaviour of another program. 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 ? The fundamental trouble is that HTT makes the spying far more efficient than it is with SMP or even UP (I think we are talking in the order of a million times more efficient). That takes the attack from the "if you were really lucky" to the "almost always in first try" category. The correct (technical) workaround (IMO) is to restrict HTT to be used only for threads from the same process. The political problem is that if all operating systems do that, Intel has a pretty dud feature on their hands, and they are not particularly eager to accept that fact. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.