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

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 <phk@phk.freebsd.dk> 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.
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"