4 ms·
Mitigations for inter-process side channels address the issue of local applications attacking each other. That includes your web browser, the JS in it, or any o
by titzer 5y ago
Mitigations for inter-process side channels address the issue of local applications attacking each other. That includes your web browser, the JS in it, or any other ad-laden crapware attack your local applications, e.g. to steal credit cards, SSH keys, etc.
Side-channels are pernicious. In the limit, they give applications unfettered read access across protection boundaries. If we don't shut them down, we might as well throw out the whole UNIX process boundary security model.
Ask yourself, would it be fine if every process had a 4KB/s (basically dialup speed) connection to read any desired byte of another process's address space?
Of course not. Thus, we need mitigations to shut these channels down.
- jfrunyon 5y ago> 4KB/s (basically dialup speed) I guess if "basically" means "takes 10x longer"?
- rcthompson 5y ago32 kb/s is on the same order of magnitude as dial-up (56 kb/s), not 10x slower. (I don't know if dial-up is still 56 kb/s these days, but that's the speed historically associated with the term.)
- jfrunyon 5y agoI was assuming that 4KB/s is peak speed, not sustained speed.
- pjmlp 5y agoThat would be only on the context of shmem, right? I would assume other IPC mechanisms are safe from it.
- msbarnett 5y agoYou would assume incorrectly.
- pjmlp 5y agoHow would Spectre exploit UNIX message boxes then?
- msbarnett 5y agoMultiple Spectre variants (RDCL, RSRR, Lazy FP state restore, SpectreRSB) bypass process boundaries. It doesn’t matter what IPC mechanism you use, they can read arbitrary privileged memory no matter who owns it. IPC really has nothing to do with anything, Spectre-wise; you don’t have to be using any IPC mechanism in either the attacker or attackee process to be vulnerable to these variants.
- pjmlp 5y agoI see, need to educate myself better on the subject then.
- userbinator 5y agoaddress the issue of local applications attacking each other. IMHO it's stupid to even try to isolate processes to that extent, as it's a really deep rabbithole that'll lead to worse performance and dubious increases in actual security. The best defense is to simply make everything running on the system be trusted. Process protection boundaries should be for protection against accidental cross-process corruption, a form of reliability, and nothing more. That's effectively what the early 286/386 documentation stated, so Intel never even intended these protections to be defenses against side-channels in the first place. Of course, the "security industry" needs to keep creating paranoia-fuel to justify their existence...
- nyanpasu64 5y ago> Ask yourself, would it be fine if every process had a 4KB/s (basically dialup speed) connection to read any desired byte of another process's address space? > Of course not. So if it's not OK for processes to read each others' address spaces, does that mean it's not OK to attach gdb to a running process to figure out where it's stuck at, without running gdb as root? I chose to reenable ptrace among sibling processes on my system out of convenience, and hopefully it's not too much of a vulnerability. (I also chose to enable passwordless sudo, which is convenient, but probably dangerous as well. I wonder if I can use my hardware security key for sudo instead.)