4 ms·

I believe most people see security through obscurity has an attempt to hide an insecurity. ASLR/KASLR intends to make attackers lives harder by having non cons

I believe most people see security through obscurity has an attempt to hide an insecurity. ASLR/KASLR intends to make attackers lives harder by having non consistent offsets of known data structures. Its not obscuring a security flaw, instead its raises an attacks 'single run' effectivness. The ASLR attack that i believe is being referenced is specific to abuse within the browser, and running with a single process. This single attack vector does not mean that KASLR globally is not effective. Your quote has some choice words, but its contextually poor.

ryao 2y ago
That attack does not require a web browser. The web browser being able to do it showed it was higher severity than you would think than if the proof of concept had been in C, since web browsers run untrusted code all of the time.
- worthless-trash 2y ago
  The 'attack' there does require you to be able to run code and test within a single process with a single randomized address space, which is the exact vector that the web browser provides. Most times in C, each fork() (rather than thread) has a differential address space, so it's actually less severe than you think.
  - ryao 2y ago
    The kernel address space is the same regardless of how many fork() calls have been done. I would assume the exploitation path for a worst case scenario would be involve chaining exploits to do: AnC on userspace, JavaScript engine injection to native code, sandbox escape, AnC on kernel space, kernel native code injection. That would give complete control over a user’s machine just by having the user visit a web page. I am not sure why anyone would attempt what you described, for the exact reason you stated. It certainly is not what I had in mind.
    - worthless-trash 2y ago
      Its been a few days and a thousand kilometers since I've read the paper, I thought it referenced userspace. How is it able to infer kernel addresses that are not mapped in that process ?

ryao 2y ago

That attack does not require a web browser. The web browser being able to do it showed it was higher severity than you would think than if the proof of concept had been in C, since web browsers run untrusted code all of the time.

worthless-trash 2y ago
The 'attack' there does require you to be able to run code and test within a single process with a single randomized address space, which is the exact vector that the web browser provides. Most times in C, each fork() (rather than thread) has a differential address space, so it's actually less severe than you think.
- ryao 2y ago
  The kernel address space is the same regardless of how many fork() calls have been done. I would assume the exploitation path for a worst case scenario would be involve chaining exploits to do: AnC on userspace, JavaScript engine injection to native code, sandbox escape, AnC on kernel space, kernel native code injection. That would give complete control over a user’s machine just by having the user visit a web page. I am not sure why anyone would attempt what you described, for the exact reason you stated. It certainly is not what I had in mind.
  - worthless-trash 2y ago
    Its been a few days and a thousand kilometers since I've read the paper, I thought it referenced userspace. How is it able to infer kernel addresses that are not mapped in that process ?