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

[David Schultz]

On Sat, May 14, 2005, Poul-Henning Kamp 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.

Some colleagues and I have a paper in submission that addresses
the issue of key-dependent control flow, much as you describe.
You're right that it's hard to do in a high-level language; you'd
be surprised (okay, maybe not) at the sort of vulnerabilities that
are introduced into perfectly reasonable C programs by gcc.

The issue of how to address key-dependent memory accesses is
harder to address in general.  Consider RC5, which has some
key-dependent table lookups built into the algorithm.  The Dan
Bernstein paper I cited in my last email has some good guidelines
about how to do better, but it doesn't offer a generic solution.
HTT aside, there are some interesting open problems here.

> 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 ?

If you're willing to wait a day or two, you don't even need to
have a local account:

	http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html

I'm just reading Colin's paper now---so as you say, it sounds like
the punchline is that having a local account buys you a few orders
of magnitude in attack time.  Kewl.

> The correct (technical) workaround (IMO) is to restrict HTT to be
> used only for threads from the same process.

That's probably satisfactory, but if you want to be really picky,
even that isn't quite sufficient.  Consider a Java virtual machine
running web applications, for instance.  There's one process, but
potentially many different protection domains within it.  The OS
would need to understand that in order to completely prevent this
kind of timing attack.  (In FreeBSD, perhaps something could be
done with multiple KSEGs...)