Nan ZoE <zoen...@gmail.com> wrote:
> In *OpenBSD 7.3,* out of 264 programs, we only
> managed to generate ROP for 134 programs, with a success rate of *50.75%*.
Please provide a list of all programs where you *ESCALATED PRIVILEGE*
via ROP methods. I ask, because:
1. If you are playing with a setuid static program, you cannot see where
in memory the binary is mapped, so you do not know the precise
syscall stub that is permitted for execve(2).
2. If you are playing with a setuid dynamic program, you cannot see
where in memory libc.so is mapped, so you do not know the precise
syscall stub that is permitted for execve(2).
3. If you are attacking a daemon, you cannot see where in memory it's
execve stub (dynamic or static) is mapped, so you do not know the
precise syscall stub to address which will perform execve(2).
Please explain how you perform the step of determining the execve system
call entrypoint for a memory image which is not readable.
>From innovations.html:
ld.so and crt0 register the location of the execve(2) stub with the
kernel using pinsyscall(2), after which the kernel only accepts an
execve call from that specific location. Theo de Raadt, Feb 2023.
What info leak are you exercising to extract libc.so's location, and
per-boot layout, and then precisely target the specific "syscall"
instruction?
My theory is that you are performing tests which are highly synthetic
(like -- reading a binary, checking it's in-memory layout once it starts
executing), and then you conclude that all the steps to your ROP methodology
are sufficient to plausibly gain *ESCALATED PRIVILEGE*.
So either you have new methodology that allows you to bypass these other
mitigations, or you have jumped to conclusion that the existance of polymorphic
ROP learned from (impossible) runtime inspection gaurantees exploit.
