3 ms·

ROP has problems with ALSR on 64 bit machine. Security is not a binary on off thing. The harder you make it for the attacker, the better. (however ALSR makes

ROP has problems with ALSR on 64 bit machine. Security is not a binary on off thing. The harder you make it for the attacker, the better. (however ALSR makes it difficult to deal with core dumps, ouch)

AstralStorm 9y ago
ASLR often makes it a requirement to get data disclosure (heap layout or at least GOP) before a full break. A funny thing is that a fully static LTO processed and inlined app is extremely hard to crack once ASLR is in play since you get no returns and get to mess only with what is inside. (Unless you find some dlopen, exec or system, perhaps mmap with unsafely handled flags.) Add good NX and read only pages and it becomes a real puzzle. And no, it does not make dealing with debugging info equipped dumps any harder, as long as walking the stack is all you need.
- pcwalton 9y ago
  > A funny thing is that a fully static LTO processed and inlined app is extremely hard to crack once ASLR is in play since you get no returns and get to mess only with what is inside. How often does that actually happen? On macOS and Windows the answer should be "never" since the syscall ABI is not stable...
  - gok 9y ago
    > On macOS and Windows the answer should be "never" since the syscall ABI is not stable... Dear Golang...
  - user5994461 9y ago
    #define WINAPI __stdcall The windows API ABI is stable and unchanged for decades.
    - pcwalton 9y ago
      The Windows API is. The NT syscall ABI is not.
    - vardump 9y ago
      That has absolutely nothing to do with Windows syscall ABI.
  - AstralStorm 9y ago
    On both of these platforms, ABIs and APIs are stable until you get to drawing. Which means you should probably use real process separation for the GUI - it has to be linked dynamically.
    - pcwalton 9y ago
      No part of the Windows syscall ABI is stable on Windows. Not win32k, not core NTAPI. You need core NTAPI to send IPC messages.
      - AstralStorm 9y ago
        It is stable in the terms of "actually didn't change in a way to break apps" not "guaranteed to be kept compatible". Last time they did a major break there is in Windows 2000. I recommend reading up on how LPC works. There have been extensions though. Such as very useful pico processes in Windows 10... Major extensions in Vista too, related to security and async operation. I recommend j00ru's blog as a good starting point. And of course Windows Internals books.
- MichaelMoser123 9y ago
  > And no, it does not make dealing with debugging info equipped dumps any harder, as long as walking the stack is all you need. I didn't quite get that: the core dump is just a dump of (some of) the memory mappings of the dumped process. in my experience gdb often does not manage to make sense of it (with ALSR). (one replacement strategy is to suspend a faulting process with SIGSTOP so that it is possible to attach to it later on)
  - AstralStorm 9y ago
    For debug equipped binaries, gdb will easily spot code addresses, after walking some stack. The trouble is, if the stack is damaged it ends up being worthless.

AstralStorm 9y ago

ASLR often makes it a requirement to get data disclosure (heap layout or at least GOP) before a full break. A funny thing is that a fully static LTO processed and inlined app is extremely hard to crack once ASLR is in play since you get no returns and get to mess only with what is inside. (Unless you find some dlopen, exec or system, perhaps mmap with unsafely handled flags.) Add good NX and read only pages and it becomes a real puzzle. And no, it does not make dealing with debugging info equipped dumps any harder, as long as walking the stack is all you need.

pcwalton 9y ago
> A funny thing is that a fully static LTO processed and inlined app is extremely hard to crack once ASLR is in play since you get no returns and get to mess only with what is inside. How often does that actually happen? On macOS and Windows the answer should be "never" since the syscall ABI is not stable...
- gok 9y ago
  > On macOS and Windows the answer should be "never" since the syscall ABI is not stable... Dear Golang...
- user5994461 9y ago
  #define WINAPI __stdcall The windows API ABI is stable and unchanged for decades.
  - pcwalton 9y ago
    The Windows API is. The NT syscall ABI is not.
  - vardump 9y ago
    That has absolutely nothing to do with Windows syscall ABI.
- AstralStorm 9y ago
  On both of these platforms, ABIs and APIs are stable until you get to drawing. Which means you should probably use real process separation for the GUI - it has to be linked dynamically.
  - pcwalton 9y ago
    No part of the Windows syscall ABI is stable on Windows. Not win32k, not core NTAPI. You need core NTAPI to send IPC messages.
    - AstralStorm 9y ago
      It is stable in the terms of "actually didn't change in a way to break apps" not "guaranteed to be kept compatible". Last time they did a major break there is in Windows 2000. I recommend reading up on how LPC works. There have been extensions though. Such as very useful pico processes in Windows 10... Major extensions in Vista too, related to security and async operation. I recommend j00ru's blog as a good starting point. And of course Windows Internals books.
MichaelMoser123 9y ago
> And no, it does not make dealing with debugging info equipped dumps any harder, as long as walking the stack is all you need. I didn't quite get that: the core dump is just a dump of (some of) the memory mappings of the dumped process. in my experience gdb often does not manage to make sense of it (with ALSR). (one replacement strategy is to suspend a faulting process with SIGSTOP so that it is possible to attach to it later on)
- AstralStorm 9y ago
  For debug equipped binaries, gdb will easily spot code addresses, after walking some stack. The trouble is, if the stack is damaged it ends up being worthless.