10 ms·
Is it possible to apply the mitigations on an per-application level in Windows? IMHO it'd be pretty useful to be able have them on by default, but disable them
by m_eiman 7y ago
Is it possible to apply the mitigations on an per-application level in Windows? IMHO it'd be pretty useful to be able have them on by default, but disable them for specific applications where you care about maximum performance and know that you won't be running untrusted code.
- systemdtrigger 7y agoTagging on with a similar query. I am on Windows 10. If I were to run Firefox in sandboxie, would be the attacker have to deal with an extra layer of security or does it offer no help?
- dijit 7y agoIt will offer no help; for context, imagine that the attacker has access to all memory on the system. It's not -exactly- like that for a bunch of reasons but realistically it's very similar.
- alkonaut 7y agoSurely if you emulate a processor without speculative execution with good fidelity (Such as a good NES emulator) then the program running ON that emulator can't deduce anything from speculative execution? Is the answer (for home users) to just sandbox some processes under an emulator layer? I'd be happy to just sandbox some sensitive processes like my browser even if it took a huge performance hit, so long as some other apps like games did not take the same hit.
- m_eiman 7y agoI suppose you could run your trusted applications in the top-most Windows instance without mitigations, and run untrusted applications in a virtualized Windows instance with mitigations enabled. Wouldn't be pretty or very practical, but I suppose it might work?
- HelloNurse 7y agoNot very likely: the attacker is outside the emulated vulnerability-free sandbox, and the state of the emulator is exposed like the state of any other program. Accessing the emulator's memory means accessing the emulated program's memory, it's just slightly obfuscated.
- alkonaut 7y agoHow is the attacker outside, assuming it's a process running on the emulator (I.e. the attacker surface here in the emulator example would be only the NES game, so he has to work with NES cpu opcodes, NES memory locations etc)?
- HelloNurse 7y agoThe attacker is not a process running on the emulator, not even if you assume it is. Security is about the worst case, not about hit or miss partial solutions.
- alkonaut 7y agoI’m talking about a hypothetical future where there are mitigations in place such as running each app sandboxed in an emulator. Obviously if a malicious process can sidestep any such mitigation and run any way it wants, then presumably it can read the memory of any process too? Why would an app even need to rely on vulnerabilities then?
- HelloNurse 7y agoIf this is your scenario, the attacker runs in its own emulator. A fairly thick pair of gloves, but not enough to prevent exploiting speculative execution vulnerabilities and reaching outside the emulator to poke into other processes. As another comment points out, attacks from Javascript code that escape the browser sandbox have been demonstrated, which is exactly your sandboxing scenario minus the easy part of targeting what an emulator is emulating.