Date: Tue, 17 May 2005 18:50:23 -0400 From: David Schultz <das@FreeBSD.ORG> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: "Drew B. \[Security Expertise/Freelance Security research\]." <d4rkstorm@gmail.com> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] Message-ID: <20050517225023.GA55428@VARK.MIT.EDU> In-Reply-To: <94145.1116037219@critter.freebsd.dk> References: <245f0df105051318564b1ffb6b@mail.gmail.com> <94145.1116037219@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 14, 2005, Poul-Henning Kamp wrote: > In message <245f0df105051318564b1ffb6b@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...)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050517225023.GA55428>