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

[Poul-Henning Kamp]

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.