Nice talk! One thing to note is that in the explanation of how functions are called by the debugger (38:25), Simon said "JIT compile to machine code". To clarify, from my experience (and looking at the source code for GDB), what GDB does when you call a precompiled function is a bunch of trickery with the debuggee's state, like adding a dummy call stack frame and calling the memory allocation function on behalf of the debuggee. But ultimately, it will transfer execution to the original pre-compiled function and let it do the job. Simon mentions that LLDB does JIT compile the expressions being evaluated so I presume it would do that for the function call "shim" as well, but I don't think it would re-compile the function being called, either. (Unless it's a template function or some other special case, and you're using a modern LLDB version with experimental features enabled.) Just wanted to clarify that detail.
I was trying to remember where I saw this guy last, it was this: "CppCon 2018: Brand & Nash “What Could Possibly Go Wrong?: A Tale of Expectations and Exceptions”" also a useful talk.
@30:50 He explains that the ptrace only reads 1 word at a time. Then he gives the alternative of "process_vm_readv" which I decided to look up and found this useful kernel doc: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fcf634098c00dd9cd247447368495f0b79be12d1 It seems to be known as CROSS_MEMORY_ATTACH which seems to ne enabled by default? and has security implications, ie: other processes are allowed to access other processes virtual memory space; although I am not qualified enough to assess these implications. I think this process_vm_readv needs more explanation on if/how this mechanism might be abused.
This document from Microsoft about how Windows does the security descriptors makes a lot more sense to me, docs.microsoft.com/en-us/windows/desktop/procthread/process-security-and-access-rights . Where you have to manually assign the PROCESS_VM_READ access right with SetSecurityInfo() and it requires the SeDebugPrivelege in your user token to do so, before you are allowed to do anything with another process's memory. So I still don't know how Linux compares to this. If anyone wants to explain...
Interestingly, Alex Ionescu wrote about a similar but opposite vulnerability, where he is concerned about malware turning themselves into Windows Protected Processes (where PROCESS_VM_READ, among other things, is disabled), so Anti-Virus/Anti-Malware won't be able to scan the address space to detect threats. www.alex-ionescu.com/?p=34
What a great talk and quite a good sport answering so many questions in the middle of his talk!
Glad you enjoyed it!
Nice talk!
One thing to note is that in the explanation of how functions are called by the debugger (38:25), Simon said "JIT compile to machine code".
To clarify, from my experience (and looking at the source code for GDB), what GDB does when you call a precompiled function is a bunch of trickery with the debuggee's state, like adding a dummy call stack frame and calling the memory allocation function on behalf of the debuggee.
But ultimately, it will transfer execution to the original pre-compiled function and let it do the job.
Simon mentions that LLDB does JIT compile the expressions being evaluated so I presume it would do that for the function call "shim" as well, but I don't think it would re-compile the function being called, either. (Unless it's a template function or some other special case, and you're using a modern LLDB version with experimental features enabled.)
Just wanted to clarify that detail.
Phenomenal talk in every regard. Thanks!
One of the best talks in CppCon this year I attended.
Really good Simon Brand.
I was trying to remember where I saw this guy last, it was this: "CppCon 2018: Brand & Nash “What Could Possibly Go Wrong?: A Tale of Expectations and Exceptions”" also a useful talk.
Also : How to write well-behaved value wrappers (2018) hhh
Amazing video! Thank you so much!
"So this is how stack unwinding would work if you have easy access to frame pointers." (casual ohcrap) "Sometimes you don't."
@30:50 He explains that the ptrace only reads 1 word at a time. Then he gives the alternative of "process_vm_readv" which I decided to look up and found this useful kernel doc: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fcf634098c00dd9cd247447368495f0b79be12d1 It seems to be known as CROSS_MEMORY_ATTACH which seems to ne enabled by default? and has security implications, ie: other processes are allowed to access other processes virtual memory space; although I am not qualified enough to assess these implications. I think this process_vm_readv needs more explanation on if/how this mechanism might be abused.
This document from Microsoft about how Windows does the security descriptors makes a lot more sense to me, docs.microsoft.com/en-us/windows/desktop/procthread/process-security-and-access-rights . Where you have to manually assign the PROCESS_VM_READ access right with SetSecurityInfo() and it requires the SeDebugPrivelege in your user token to do so, before you are allowed to do anything with another process's memory. So I still don't know how Linux compares to this. If anyone wants to explain...
Interestingly, Alex Ionescu wrote about a similar but opposite vulnerability, where he is concerned about malware turning themselves into Windows Protected Processes (where PROCESS_VM_READ, among other things, is disabled), so Anti-Virus/Anti-Malware won't be able to scan the address space to detect threats. www.alex-ionescu.com/?p=34
56:55 The annotation should read ptrace calls not petrie skulls
Very enlightening👍
Glad you think so!
Great talk!
Can't find slides on github by link in description
Sorry, these slides are unfortunately unavailable.
They might be at the QR code that pops onto the screen around minute 52?
11:08 I got so scared! Lmfao
Stylówe ma nie do podrobienia