121–130 of 137 posts
I've pointed this problem out early last year to libsodium, but they chose to ignore it. My memset_s does a full memory barrier, but no others do. Esp. the so-called "secure" libs.
Which would be more difficult, reading the secret at some point before the memory was cleared, or reading it _after_ the memory was cleared, but _before_ the cache was overwritten?
Before people get all nutty as usual: This is another TSX (transactional memory) issue, and you can disable TSX without much of a problem. The attacker basically needs to be running a binary on the machine (not JS in a browser or anything). The leakage is extremely slow, about 225 byte/minute for ASCII text (a 4k page in 18 minutes). I'm not sure if that was an exact recovery either, just a probabilistic one. With no…
"It seems to be able to only be able to control the bottom 12-bits of the address to recover (but I didn't fully get why)" That looks conspicuously like the load/store port address aliasing size (look up "4K Aliasing"), which can be used to stall data availability while the conflict is resolved. I'll read up on this particular one, but there's a growing family of vulnerabilities with 12-bit address aliasing in their…
It is on you to make sure something interesting is in the cache, but if you can make your target execute, 12-bits is fairly good selectivity.
Before people get all nutty as usual: This is another TSX (transactional memory) issue, and you can disable TSX without much of a problem. The attacker basically needs to be running a binary on the machine (not JS in a browser or anything). The leakage is extremely slow, about 225 byte/minute for ASCII text (a 4k page in 18 minutes). I'm not sure if that was an exact recovery either, just a probabilistic one. With no…
The "nutty"ness comes from people getting frustrated with intel fucking up the security of yet another feature they promised, and intel's overall poor security record. Luckily there are other vendors who seem to know what they're doing: We just received our first batch of non-intel servers at work and have no intention of returning to intel for the foreseeable future. What they offer is simply not worth the risk. I e…
Unless you are running untrusted VM from others, you're not making a rational, knowledgeable decision.
Most people are just using this to falsely justify their Intel hate, similar to Microsoft in the 2000s.
Earlier quoted context omitted.
The market is noticing that we're losing a whole lot of performance on Intel to these security-related mitigations, though...
Intel reports record profits again.
Earlier quoted context omitted.
The "nutty"ness comes from people getting frustrated with intel fucking up the security of yet another feature they promised, and intel's overall poor security record. Luckily there are other vendors who seem to know what they're doing: We just received our first batch of non-intel servers at work and have no intention of returning to intel for the foreseeable future. What they offer is simply not worth the risk. I e…
At the level where large, security-centric organizations make decisions, these instances argue for getting AMD in the door like nothing else that I can recall. So, it's a good time for AMD to have such performant hardware and a process advantage. If it stays this way for a decade, I'll be able to put in a PO for AMD hardware...
There are cache architectures (such as pseudo random replacement) that are much more difficult to perform side channel attacks on, but have slightly lower performance.
Intel's problem has been its relentless pursuit of per clock performance, and that has led to some of these side channel attacks. Cache coherency on multi-core is hard.
My guess is that if the market share of Intel and AMD were swapped, you would see similar cache attacks on AMD.
Earlier quoted context omitted.
Does this mean we could see 16x larger L1?
All of hardware is tradeoffs. A huge L1 would be slower to access. You might end up slowing down all memory accesses by a cycle (or more) just for accessing the large cache. You also have to find some place to put the thing in your floorplan, and route everything else around it. This may result in timing challenges in other parts of the chip, which might require additional delay to resolve. A huge L1 would take up mo…
Earlier quoted context omitted.
That's a lot of work, but the instant it's in a rootkit everybody will be able to do it. 113 bytes is extracting an AES key from memory in about a minute. It's only really hard and messy for the first guy who implements it, after that it is much easier, albeit still fairly messy. I'm not saying we need to panic, but it's more than a "non-issue".
113 bytes is extracting an AES key from memory in about a minute. How do you know where the key is, and how are you guaranteed to be able to read enough of it before the "shifting sands" that is timing unpredictability and general noise in the system make you read something else? That's what really irritates me about all these side-channels that have been found ever since the first Spectre/Meltdown --- they all demon…
perhaps package servers and package management software should round up the package size to hide the identity of the package? use oblivious transfer to hide the identity of the package from the package server itself?
Earlier quoted context omitted.
That's a lot of work, but the instant it's in a rootkit everybody will be able to do it. 113 bytes is extracting an AES key from memory in about a minute. It's only really hard and messy for the first guy who implements it, after that it is much easier, albeit still fairly messy. I'm not saying we need to panic, but it's more than a "non-issue".
113 bytes is extracting an AES key from memory in about a minute. How do you know where the key is, and how are you guaranteed to be able to read enough of it before the "shifting sands" that is timing unpredictability and general noise in the system make you read something else? That's what really irritates me about all these side-channels that have been found ever since the first Spectre/Meltdown --- they all demon…
It's really not that hard. E.g. people working on browser exploits have been working on exactly this for years and years, back when just having an out-of-bounds read due to a regular browser bug was the mechanism. Turns out that programs are absolutely chock full of pointers and it doesn't take long to run across one that points to what you are looking for. Especially because programs tend to have lots of data structures that end up pointing to more and more important data structures, funneling you into the guts of the program.
Sure, reverse engineering takes work, but blindly hunting in memory with no clue it is definitely not.
Side-channel attacks are basically a persistent out-of-bounds read mechanism. That is a very bad thing (TM).
There are literally thousands of people who work on this day in and day out, and millions in bug bounty programs out there.
Earlier quoted context omitted.
By your own numbers, this could translate to a 30-second AES key exfiltration in the cloud. This isn't a non-issue, even if you personally aren't affected.
you have to find the address first, which is a lot of rummaging around. you aren't just handed it. that is going to quite a bit, especially the program build any security measures in (eg, allocate at a random address). good luck with that.