3 ms·
Just guessing here, but suppose an attacker is able to get unprivileged code to run on your machine (by taking over some process). He is now able to extract sec
by chmod775 7y ago
Just guessing here, but suppose an attacker is able to get unprivileged code to run on your machine (by taking over some process). He is now able to extract secrets from other processes on the machine that he ordinarily wouldn't have access to. Think SSL keys etc.
But I believe you're right in that those exploits are not as dangerous in a non-shared hosting scenario.
- zorked 7y agoQuick reminder that a browser with JavaScript is a way to run unprivileged code on your machine.
- phire 7y agoI'm not even sure code execution is strictly necessary for this style of attacks. An attacker could carefully craft network packets to force the control flow of existing software to manipulate the CPU state. They could and then use the timing differences in network packets to read data out. Would be painfully slow, but theoretically possible.
- bannable 7y agoI don't think this is correct. The timing attacks here all require extremely high resolution timers, and network + I/O latency would obscure the variance entirely.
- dymk 7y agoPeople are able to crack poor password comparison implementations over a jittery, latency heavy network. It’s possible to get almost arbitrarily high resolution when doing timing side channel attacks, you’ll just need many more samples.
- _hl_ 7y agoA while a go there was a post on here describing exactly that. I can't find it anymore unfortunately (maybe someone else has it?), but judging from my memory of that discussion this should be doable-ish. But if you're just running a local home system the chances of being targeted with such an unreliable attack are virtually zero.
- acdha 7y ago> suppose an attacker is able to get unprivileged code to run on your machine (by taking over some process). He is now able to extract secrets from other processes on the machine that he ordinarily wouldn't have access to. Think SSL keys etc. I think that's the catch: it's the set of cases where someone can get code execution without being able to directly retrieve the targeted data, which is already pretty low, and where the best mitigation technique is to harden against these attacks rather than use a dedicated service (e.g. if you're using an HSM for crypto or have a dedicated SSL-offload box, you don't have to worry about keys being compromised when someone finds a bug in the much greater exposed surface area of your application).