Hello, Thank you for your response. We don't have 100% visibility into memory. We are merely using a simple stack overflow vulnerability to verify the feasibility of the ROP we generate. Bypassing addresses randomization issues in program code segments (e.g., .text code segment) and often involves addressing leakage using gadgets from the code segment. However, bypassing address randomization for stack and heap addresses can be more challenging, and these leakage methods are closely related to the specific vulnerabilities. Nevertheless, our main focus remains on the problem of linking gadgets. While this issue is not new, I'd like to emphasize that, in light of some solutions proposed for OpenBSD regarding reducing gadgets to mitigate ROP attacks <https://www.openbsd.org/papers/asiabsdcon2019-rop-paper.pdf>, we aim to enhance the capabilities of these solutions. Our goal is to reduce the number of gadgets in the program. It's impossible to eliminate gadgets entirely, but there's an ongoing adversarial process. Our tool can systematically evaluate the limitations of these mitigation mechanisms and make gadget utilization more challenging in this adversarial context. These contributions may be modest, but they are certainly valuable.
Additionally, it's reasonable to assess the correctness of the ROP payloads we generate for a program by injecting vulnerabilities. Firstly, the original gadget set in the program remains intact and usable. Secondly, this method of injecting vulnerabilities is equivalent to assuming the existence of easily exploitable ROP attack vulnerabilities in the program. In both cases, the ROP payloads can be executed, and the gadgets in these ROP payloads are all from the original program. In other words, if a program has vulnerabilities that require ROP attack techniques, then the ROP payloads generated by our tool are entirely applicable. In our experiments, we extracted over a thousand programs from OpenBSD, and while most of them do not have syscall instruction gadgets, there are still more than 240 programs that contain syscall instruction gadgets. This is confirmed by various tools such as ropper <https://github.com/sashs/Ropper>and ROPgadget <https://github.com/JonathanSalwan/ROPgadget> that we used to extract gadget sets. Even in cases where programs are dynamically linked, the syscall instructions are not solely located within their ld.so. Best regards, ZoE Theo de Raadt <dera...@openbsd.org> 于2023年10月12日周四 22:59写道： > > Please note that after injecting the vulnerabilities, the programs > execute > > the '*main*' function from the vulnerable program, not the entry function > > from the original program. However, the Gadgets from the original program > > are still usable. This approach allows us to evaluate the ROP > construction > > capability of the original program's Gadget collection and use the > injected > > vulnerabilities to validate the correctness of ROP exploitation. > > Which means you do all your work before a program can self-protect > itself using pledge() or unveil() or a whole bunch of other mechanisms. > > You are not just ignoring address space randomization, but also a bunch > of other mechanisms. > > int > main() > { > pledge("stdio, NULL); > while (1) > sleep(100: > } > > You would do an execve() inside this program image because you've never > started running the program. But since the program never ran any of it's > own code, you haven't done it in the program, but only in your own code. > > And this work is done through offline calculation obviously, since the > program's text segment is not readable (on most modern machines with PKU) > due to the xonly work which makes the text segment not readable. > > That is so synthetic, it is uninteresting. > > > I too can become very rich quickly by assuming the banks have turned off > all their protections. >
