full-disclosure - Re: Intel Hyperthreading Cache Vulnerability (was: Cisco IOS Shellcode Presentation)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20050729214459.GA2972@sentinelchicken.org>
Date: Fri Jul 29 22:45:11 2005
From: tim-security at sentinelchicken.org (Tim)
Subject: Re: Intel Hyperthreading Cache Vulnerability
	(was: Cisco IOS Shellcode Presentation)

Hello Steve,

> If this is the hyperthreading cache timing thing:
> 
> 	http://www.daemonology.net/hyperthreading-considered-harmful/
> 
> it's not nearly so simple as one thread stealing from the cache of
> another: there is no data sharing going on. Instead, one thread can get
> some vague hints about what's in the other guy's cache by watching the
> timing of his *own* cache.

I don't know much about architecture, but yes I read the paper.

> It's a bit of *outstanding* technical work, but I think it has really
> limited impact in the real world. Even in carefully controlled conditions
> it's going to be difficult to make this work, and I think that on a busy
> server it's going to be nearly impossible to even know at the instruction
> level which other process is running on the other thread.  (by the time
> you figure out that openssh has been scheduled, it's too late).
> 
> Unless I hear a lot more about this than I've seen so far, I would not
> give this matter a thought.

How about a little more instead:

Suppose I have access to a low-rights account on a Unix server.  Suppose
I first log into this server, and start up a cache monitoring program
similar to the one described in the paper.  Then I ssh in again on a
seperate session.  The ssh daemon has a significant amount of
computation to do, so it is likely to get on the CPU pretty quick.  My
monitoring process is constantly monitoring the cache, so it is also
likely to get on the CPU.

Even if there is only a 10% chance of getting them both on there at
once, I only need to try 32 times to have a greater than 95% chance of
nailing one of them.  I can continue trying all day long.  I believe the
paper stated it isn't hard to profile processes well enough to tell if
they are also on the CPU at the right time.

After I gain enough information to compromise the ssh daemon's private
key, I can begin performing man-in-the-middle attacks on other
connecting clients (provided I have some method to do that).  Let your
imagination run wild.  Other network services can be affected the same
way, provided you are allowed to run code on the target system.

Feel free to critique this scenario, in the event I overlooked
something.

thanks,
tim