This gave me a weird impression:
"In this case, the attack surface is the context buffer. A hacker may attack an application with a vulnerability and may be able to modify the context buffer. So, when the register or stack context is set for a trampoline, the values may have been tampered with. From an attack surface perspective, this is similar to Trampoline Emulation. But with trampfd, user code can retrieve a trampoline's context from the kernel and add defensive checks to see if the context has been tampered with."
I'm completely out of my depth here, but does this mean each and every app using trampolines has to take protective measures against outside tampering for the proposal to be safe?
Also, how does it cover a scenario where the app invoking a tampered trampoline is actually malicious in nature? Is it possible this tampering could provide access to info outside the context of the malicious app, or is this boundary already already enforced otherwise?
"In this case, the attack surface is the context buffer. A hacker may attack an application with a vulnerability and may be able to modify the context buffer. So, when the register or stack context is set for a trampoline, the values may have been tampered with. From an attack surface perspective, this is similar to Trampoline Emulation. But with trampfd, user code can retrieve a trampoline's context from the kernel and add defensive checks to see if the context has been tampered with."
I'm completely out of my depth here, but does this mean each and every app using trampolines has to take protective measures against outside tampering for the proposal to be safe?
Also, how does it cover a scenario where the app invoking a tampered trampoline is actually malicious in nature? Is it possible this tampering could provide access to info outside the context of the malicious app, or is this boundary already already enforced otherwise?
Comment