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
| ||
|
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
Powered by blists - more mailing lists