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