From owner-freebsd-security@FreeBSD.ORG Sat May 14 05:35:03 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 7226416A4CE for ; Sat, 14 May 2005 05:35:03 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 163A943D82 for ; Sat, 14 May 2005 05:35:03 +0000 (GMT) (envelope-from d4rkstorm@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so299386rne for ; Fri, 13 May 2005 22:35:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VtP5ICypu2/O4rSddww9r/lZ6QmsaPa4HVUYHZs18e165MOkWkgpS9UBW4QvV1L4OBp7MTE+00BBUzB3FA6L4EDj3vkBeT3K4rgB1cAs3N6ucrpWEHv8PDCOv5riDhUq3OdgnYYODlwjEpbqGhoUUkWBe2UuAz7ZN8vRGKrYJTY= Received: by 10.38.104.2 with SMTP id b2mr1211281rnc; Fri, 13 May 2005 22:35:02 -0700 (PDT) Received: by 10.38.101.18 with HTTP; Fri, 13 May 2005 22:35:02 -0700 (PDT) Message-ID: <245f0df105051322354e8e86eb@mail.gmail.com> Date: Sat, 14 May 2005 15:35:02 +1000 From: "Drew B. [Security Expertise/Freelance Security research]." To: Poul-Henning Kamp In-Reply-To: <94145.1116037219@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <245f0df105051318564b1ffb6b@mail.gmail.com> <94145.1116037219@critter.freebsd.dk> cc: freebsd-security@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 Reply-To: "Drew B. \[Security Expertise/Freelance Security research\]." 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 05:35:03 -0000 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. Hehehe... I cannot help but giigle abit, I didnt think this went that deep :o , definately interesting stuff regarding the future of HT and O/S Types,ty even though the answer may help someone else more, Regards, Drew B. (Enlightening myself to inspire others is my answer to everything *No-Comme= nt*) On 5/14/05, Poul-Henning Kamp wrote: > In message <245f0df105051318564b1ffb6b@mail.gmail.com>, "Drew B. [Securit= y Expe > rtise/Freelance Security research]." writes: >=20 > >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? >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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 ? >=20 > 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). >=20 > That takes the attack from the "if you were really lucky" to the > "almost always in first try" category. >=20 > The correct (technical) workaround (IMO) is to restrict HTT to be > used only for threads from the same process. >=20 > 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. >=20 > Poul-Henning >=20 > -- > 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 incompetenc= e. >=20 --=20 -------------------------------------------------------------------- Drew B. Independant Security analysis,for Aussies. Security researcher/expert,threat-focus,Freelance.