FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED]

Drew B. [Security Expertise/Freelance Security research]. d4rkstorm at gmail.com
Fri May 13 22:35:03 PDT 2005


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-Comment*)


On 5/14/05, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> In message <245f0df105051318564b1ffb6b at 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 at 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.
> 


-- 
--------------------------------------------------------------------
Drew B.
Independant Security analysis,for Aussies.
Security researcher/expert,threat-focus,Freelance.


More information about the freebsd-security mailing list