3 ms·

Uh, if the syscalls are in random order how would your code know how to reach the proper one? If there is identifying meta-data (such as names) associated with

by unwind 6y ago

Uh, if the syscalls are in random order how would your code know how to reach the proper one? If there is identifying meta-data (such as names) associated with each then I guess malicious code can parse that too, or steal it from some authorized source after that has parsed it, or whatever. On the other hand, I s*ck at security so perhaps this is the best idea ever ... honest question.

fwsgonzo 6y ago
Well the table would have fixed indexes that translate either into addresses that go to trampoline functions that would then execute the system call, or just some kind of translation 0 -> write etc. It's not important. That said, I have no idea what works and what doesn't for security. I'm just asking questions, too. :)
- fuzzybear3965 6y ago
  I'm confused about this. I think you understand what you're saying. I've seen your RISC-V runtime library. Can you explain in a bit more detail how I navigate this randomized table as a syscall user to call the right one? I call socket(), say. And that is mapped to index 12 of the randomized syscall table. How is it found at runtime?
  - fwsgonzo 6y ago
    When Linux loads your program it actually puts quite a bit of stuff on the stack. The first thing it puts is the argc followed by an array of argv pointers, followed by a zero. After that it puts the environment variables, followed by a zero. And then it puts the aux-vector, which contains lots of useful things. And that's where you could pass the address of a system call translation/jump table. This aux-vector is already used to enable multi-threading, because it contains the necessary information to create the thread-local storage. One drawback here is that your simple hello-world write/printf in assembly becomes complicated, because you need to get the table address so you can access the write/exit information. As far as what this would help for security, I have no idea, other than making it harder to exploit cases where you don't have a lot of room. We don't hear a lot about all the exploits that didn't happen because of all the extra hoops you have to jump through with each change over the years.
Karliss 6y ago
Once you get to execute arbitrary code there is little you can't do that the real program can, but unless everything is very bad a vulnerability won't allow you to directly execute arbitrary malicious code. A buffer overflow might only allow you to overwrite few bytes or do a single jump. Attacker then has to leverage this very limited execution and turn it into running bigger piece of code. Many mitigation techniques focus on making this part as difficult as possible. If locating or parsing information to disable security features requires running few hundred lines of code but vulnerability allows you to directly execute only 10 instructions which can't even be freely chosen, attack might be prevented.

by unwind 6y ago

fwsgonzo 6y ago

Well the table would have fixed indexes that translate either into addresses that go to trampoline functions that would then execute the system call, or just some kind of translation 0 -> write etc. It's not important. That said, I have no idea what works and what doesn't for security. I'm just asking questions, too. :)

fuzzybear3965 6y ago
I'm confused about this. I think you understand what you're saying. I've seen your RISC-V runtime library. Can you explain in a bit more detail how I navigate this randomized table as a syscall user to call the right one? I call socket(), say. And that is mapped to index 12 of the randomized syscall table. How is it found at runtime?
- fwsgonzo 6y ago
  When Linux loads your program it actually puts quite a bit of stuff on the stack. The first thing it puts is the argc followed by an array of argv pointers, followed by a zero. After that it puts the environment variables, followed by a zero. And then it puts the aux-vector, which contains lots of useful things. And that's where you could pass the address of a system call translation/jump table. This aux-vector is already used to enable multi-threading, because it contains the necessary information to create the thread-local storage. One drawback here is that your simple hello-world write/printf in assembly becomes complicated, because you need to get the table address so you can access the write/exit information. As far as what this would help for security, I have no idea, other than making it harder to exploit cases where you don't have a lot of room. We don't hear a lot about all the exploits that didn't happen because of all the extra hoops you have to jump through with each change over the years.

Karliss 6y ago

Once you get to execute arbitrary code there is little you can't do that the real program can, but unless everything is very bad a vulnerability won't allow you to directly execute arbitrary malicious code. A buffer overflow might only allow you to overwrite few bytes or do a single jump. Attacker then has to leverage this very limited execution and turn it into running bigger piece of code. Many mitigation techniques focus on making this part as difficult as possible. If locating or parsing information to disable security features requires running few hundred lines of code but vulnerability allows you to directly execute only 10 instructions which can't even be freely chosen, attack might be prevented.