3 ms·

I'm not the person to answer but let me try. Anyone correct me please. Side channel attacks are AIUI about information leakage. They extract info on the state,

I'm not the person to answer but let me try. Anyone correct me please. Side channel attacks are AIUI about information leakage. They extract info on the state, not modify state[0]. I don't think privilege escalation is really related because that needs to modify state you should not have access to[1]. Capabilities at the OS and software level are software enforced, which is built on assumptions about the security (correctness guarantees) of the hardware. If the hardware leaks, the software is vulnerable unless/until patched to try to paper over the leaky cracks in the hardware. Again, AIUI. [0] Though such extracted data might be a security token that can subsequently be used to actively attack, such as logging in via someone's newly pwned admin password. [1] I suppose rowhammer is exactly that, though, an attack that intentionally leads to a handy state change for the attacker.

magicalhippo 7y ago
> I don't think privilege escalation is really related because that needs to modify state you should not have access to. But in a capability-based OS, privilege is all about the keys you hold, no? So assuming a malicious process can copy keys from other processes, can the OS detect and prevent the malicious process from using the key? I tried reading up on KeyKOS[1] and there was very little info on what exactly a key is and how it is verified by the OS, at least that I could see. [1]: http://cap-lore.com/CapTheory/KK/Arch/ http://cap-lore.com/CapTheory/KK/Arch/
- throwaway_pdp09 7y ago
  You are right - see my note [0] but I missed the bleedin obvious. Thanks for pointing it out. In that case the hardware is effectively broken and all that's left is attempted software mitigation. Which may/may not work, but surely will cost performance. And extra complexity. And consequential possible bugs. From memory a key can be represented as a random 64-bit integer taken from a sparse set. IOW you'd have bugger all chance of guessing another currently used 64-bit int, and if you tried and guessed wrong the OS, which would keep a list of caps allocated to each process) would say when you tried to use it "and where exactly did this come from, eh?" and kill you. But that's from memory and guesswork. HTH and don't trust what I say too much!

magicalhippo 7y ago

> I don't think privilege escalation is really related because that needs to modify state you should not have access to. But in a capability-based OS, privilege is all about the keys you hold, no? So assuming a malicious process can copy keys from other processes, can the OS detect and prevent the malicious process from using the key? I tried reading up on KeyKOS[1] and there was very little info on what exactly a key is and how it is verified by the OS, at least that I could see. [1]: http://cap-lore.com/CapTheory/KK/Arch/ http://cap-lore.com/CapTheory/KK/Arch/

throwaway_pdp09 7y ago
You are right - see my note [0] but I missed the bleedin obvious. Thanks for pointing it out. In that case the hardware is effectively broken and all that's left is attempted software mitigation. Which may/may not work, but surely will cost performance. And extra complexity. And consequential possible bugs. From memory a key can be represented as a random 64-bit integer taken from a sparse set. IOW you'd have bugger all chance of guessing another currently used 64-bit int, and if you tried and guessed wrong the OS, which would keep a list of caps allocated to each process) would say when you tried to use it "and where exactly did this come from, eh?" and kill you. But that's from memory and guesswork. HTH and don't trust what I say too much!