4 ms·

Currently ls.so upon linking in libc; invoking msyscall() is only permitted once per process. Seeing as msyscall() is itself a system call, any calls to it mus

by Reelin 7y ago

Currently ls.so upon linking in libc; invoking msyscall() is only permitted once per process. Seeing as msyscall() is itself a system call, any calls to it must themselves originate from an authorized region.

ori_b 7y ago
Correct. So, now, if you want to allow any program, and presumably its libraries, to register their regions of memory as being syscall-worthy you need to lift the called-once restrictions, which opens a hole for an attacker.
- ianlevesque 7y ago
  I think the idea here is to just let the linker do it.
  - ori_b 7y ago
    Which is why go is such a problem -- because the linker can't do it without hacks and guesswork, in the case of a static binary that dlopens libc. I'm aware of the issues. I was a part of the discussions in the hut when they were being implemented.
- Reelin 7y ago
  > you need to lift the called-once restrictions, which opens a hole for an attacker I don't see how that's the case; my original question was essentially asking what that security hole is. Provided that syscall ability is opt-out by default and that only code subjected to ASLR is permitted to be authorized, it doesn't seem terribly risky to allow additional such regions to be registered. An exploit has to contend with ASLR either way; either by locating libc, or by locating some other authorized region within the current process.
  - ori_b 7y ago
    ASLR isn't a complete solution. It's not that hard to find libc, so this is just another hurdle, not a full barrier. You're proposing weakening the barrier.
    - Reelin 7y ago
      I'm not proposing anything, I'm asking for a concrete explanation of the supposed security hole. I agree that ASLR isn't a complete security solution and never implied otherwise. AFAIU, the entire security benefit here is due to ASLR alone. If an exploit manages to track down libc, it can go right ahead and make all the system calls it wants. (Unless there's some other piece to the puzzle that I've missed? Is there something special about libc in particular?) As such, I still don't understand how the called-once restriction is supposed to meaningfully increase security - by the time you've found the msyscall() function, you've also found _all the others_ anyway.
      - ori_b 7y ago
        > AFAIU, the entire security benefit here is due to ASLR alone. If an exploit manages to track down libc, it can go right ahead and make all the system calls it wants It has to create the appropriate gadgets to generate function call sequences, and generating gadgets is hard.

by Reelin 7y ago

ori_b 7y ago

Correct. So, now, if you want to allow any program, and presumably its libraries, to register their regions of memory as being syscall-worthy you need to lift the called-once restrictions, which opens a hole for an attacker.

ianlevesque 7y ago
I think the idea here is to just let the linker do it.
- ori_b 7y ago
  Which is why go is such a problem -- because the linker can't do it without hacks and guesswork, in the case of a static binary that dlopens libc. I'm aware of the issues. I was a part of the discussions in the hut when they were being implemented.
Reelin 7y ago
> you need to lift the called-once restrictions, which opens a hole for an attacker I don't see how that's the case; my original question was essentially asking what that security hole is. Provided that syscall ability is opt-out by default and that only code subjected to ASLR is permitted to be authorized, it doesn't seem terribly risky to allow additional such regions to be registered. An exploit has to contend with ASLR either way; either by locating libc, or by locating some other authorized region within the current process.
- ori_b 7y ago
  ASLR isn't a complete solution. It's not that hard to find libc, so this is just another hurdle, not a full barrier. You're proposing weakening the barrier.
  - Reelin 7y ago
    I'm not proposing anything, I'm asking for a concrete explanation of the supposed security hole. I agree that ASLR isn't a complete security solution and never implied otherwise. AFAIU, the entire security benefit here is due to ASLR alone. If an exploit manages to track down libc, it can go right ahead and make all the system calls it wants. (Unless there's some other piece to the puzzle that I've missed? Is there something special about libc in particular?) As such, I still don't understand how the called-once restriction is supposed to meaningfully increase security - by the time you've found the msyscall() function, you've also found _all the others_ anyway.
    - ori_b 7y ago
      > AFAIU, the entire security benefit here is due to ASLR alone. If an exploit manages to track down libc, it can go right ahead and make all the system calls it wants It has to create the appropriate gadgets to generate function call sequences, and generating gadgets is hard.