BranchScope: A New Side-Channel Attack on Directional Branch Predictor
arstechnica.com
arstechnica.com
The researchers looked only at Intel processors, using the attacks to leak information protected using Intel's SGX (Software Guard Extensions), a feature found on certain chips to carve out small sections of encrypted code and data such that even the operating system (or virtualization software) cannot access it.
Perhaps the other good thing to come of this. Fuck that DRM shit.
Or consider a colocation friendly host / dedicated hosting only. Of course this doesn't mean you have any guarantees there wont be any bad state actors on the premise at any moment (if this is a concern), but it beats sharing a machine with some skiddies.
But I get your point.
Also, the attack surface is less about the port, and more about the protocol. A Node HTTP interface is going to prioritise being correct as much as possible, because you're coding to the API. Nginx on the other hand will often by default (or at least with configuration) give a much more restricted implementation because it knows that there are bad people out there on the web.
To take a totally made up example that may or may not actually be the case, but should make the point... you can upload files in web forms with multipart/form-data - I would expect Node to either not have a limit, or have a very high limit, so that you can set it up how you want. Nginx on the other hand has a default of something like 2MB, which is maybe a bit low for apps that need file upload, but will crucially prevent certain kinds of denial of service attacks.
There are many similar areas of attack, abusing edge cases of the HTTP spec that Nginx will handle well out of the box. Not to mention the HTTPS support being probably much more complete in Nginx (in terms of cipher suites and browser compatibility).
Well, except for people using web browsers…
In our rush to get rid of Flash on the web we turned the web into Flash. At least it's an open standard now, I suppose.
Images and other codecs might also be an issue but it seems like a more complicated attack vector and one that could be mitigated more effectively.
You mean, unless you browse the web and enable javascript...
Also, which code do you "trust"? Computer games? Phone apps? The OS?
Even then, if you're only hitting Gmail, Facebook and reddit, hackernews maybe a few news sites, you're gonna be fine most of the time. Yeah sometimes malware gets distributed via ad networks, so you're even better to use an ad blocker.
It's not like the average user spends a lot of time on random sketchy sites, most of their time is on the big companies sites.
(Only slightly joking.)
You need to meet more average users then :). Plenty of sketchy sites are just one Google search away. The most common ways I've seen people end up in such places are free video streaming, browser games and (obviously) porn.
The only safe computer is a computer that has been submerged in liquid lead, cooled, poured into a solid 6m by 6m by 6m concrete cube, placed into the deepest edge of a saltmine and finally detonating a charge and collapsing a mounting over the computer.
That computer will be reasonably out of reach for everyone.
It's also quite useless.
And then someone will find a vulnerability in the thermocouple data processing code and will pwn the box by cunningly heating and cooling the surface above (possibly with low-yield nuclear warheads).
On the end-user/device side, JavaScript has proven that sharing hardware with untrusted code is just too valuable to give up, and a similar dynamic continues to play out in the cloud.
I'm also happy whenever a headline brings attention to these types of problems because I believe we can fix them.
I think it's spot-on. Isolation has never been the top priority. Regardless of the priority, if one simply views all "untrusted code" as "code created by my enemy" the solution becomes clear - don't run it.
>> JavaScript has proven that sharing hardware with untrusted code is just too valuable to give up...
This is something I strongly disagree with. Javascript has become a common way to handle things but it's not the only way. In my opinion it's the lazy way - most people want to just use what's there and common rather than solve a few problems.
>> I'm also happy whenever a headline brings attention to these types of problems because I believe we can fix them.
One thing I'm seeing is that CPUs with speculative execution have lower performance/watt and performance/area. So in the cloud space it seem like just going to simpler CPU cores may be a solution (risc-v Esperanto Minions for example). Obviously that's not a solution where single thread performance is critical.
This seems like an odd thing to say. There are plenty of very good reasons to not run your own hardware.... lower cost, uptime, ability to scale with demand all comes to mind.
Cloud providers will figure out how to mitigate threats like this...
[0] https://sawtooth.hyperledger.org/docs/core/releases/1.0/sysa...
Which isn't to say that this is bad work, nor even that the authors are over-hyping it (in fact, the paper mentions Spectre... very early in the introduction only.) But this article makes it easy to over-estimate the impact.
As always, crypto code (in particular) must be constant-time (constant-everything) to avoid key recovery via such attacks. But again, that isn't new - cache-based attacks have broken lots of non-constant-time crypto code.
Even if every individual aspect of these vulnerabilities had been recognized before, it is undeniable that the risks of their synergistic (from the point of view of an attacker) combination had not been properly appreciated prior to deployment of the affected technology, and for some time after.
This happens everywhere; hell, that's how we ended up with Unix. "Worse is better".
I really do not think it should be a surprise to anyone that these vulnerabilities are being announced. Yeah, it certainly stands up shake up our industry... but I am not sure we were blindsided by it.
Using shard or managed hardware has always been a compromise between the increased risk against the convenience. Nobody wants to build a data center out of their office anymore.
Some of this risk can be mitigated by using managed but dedicated hardware. More expensive, but the option exists just about everywhere.
In retrospect, we can say that people were making decisions that favored convenience over security, but were they aware at the time what specific compromises they were making? Either way, there is an important issue here that does not go away by saying they should or could have known.
As a sysadmin, I am NOT looking forward to the next few months...
People run code from different security domains on the same L1/L2 cache. Why is that beneficial? Compared to, say, having the kernel flush the cache entirely whenever a context switch goes from one (uid/chroot/...) tuple to another, and only running processes/threads with the same tuple on the same cache at the same time?
Usermode processes call privileged processes often (kernel APIs for example), if you flush the cache every time a context switch occurs, processing is now orders of magnitude slower.
You can absolutely can do this today. It is just slow as heck.
Could there be a separate OS cache and a regular user code cache? Would it also speed up things (if cheap enough)?
That could technically even be handled transparently by hardwiring caches for usage in Ring 3 or Ring 0 and then introducing additional opcode for explicitly allowing certain addresses to be put into Ring 3 cache when it goes into Ring 0 cache.
PCID already does per-process caching, somewhat, though it's a bit neutered atm.
The good thing is that it only needs to be backwards compatible in the sense that an OS that has no idea about this should at worst have a performance penalty.
The hard point will be the additional hardware. L2 cache is expensive, L1 even moreso.
It seems to boil down to performance-critical untrusted code that performs many kernel calls.
It doesn't seem credible that completely clearing cache and repopulating it every time a privileged context switch occurs would cause performance degradation?
> It seems to boil down to performance-critical untrusted code that performs many kernel calls.
You're conflating the current branch prediction hotfixes with what the person above asked about which was completely clearing cache when the context is switched into a privileged state. Those are two entirely different things.
The current hotfixes try to continue to utilize many performance benefits of speculative execution, while patching out the side-channel attacks from branch prediction. The person above was asking about a complete change in the underlying model we use today, which would promote security at the cost of performance.
I run some heavy jobs today. Many CPU seconds each. I don't see that those have to suffer. They can stay married to a CPU core for seconds at a time, uninterrupted, just like today. They perform few system calls, and the ones they do perform never fail any in-kernel check.
The javascript that runs in the browser suffers, sure, but that javascript has other reasons not to need several seconds of CPU.
BTW, that person was me, and you misunderstand the question. Not into a privileged state. Out of. Such that an unprivileged/unstrusted process would see cache contents produced by others.
Many older generations of ARM (v5 and earlier) used a virtually indexed, virtually tagged (VIVT) cache to reduce latency but this required an L1 flush on every context switch and that was incredibly painful!