Hello, Thank you for your response. I'm sorry, I just looked at the introduction of pinsyscall. If OpenBSD only uses pinsyscall, calling syscall is a challenge in exploitation. However, I'm not sure if this is a required protection mechanism for all programs. What happens if a user inlines the syscall instruction when writing a program? Or can it be bypassed through address leakage? I am currently uncertain. The presence of protection mechanisms like address randomization is not unique to OpenBSD; many exploitation scenarios encounter these issues. Ensuring that these addresses are known is a prerequisite for using gadgets in ROP attacks. Studying the automated ROP construction capabilities of a program's gadget collection is a general problem. We analyze whether these gadgets can be chained into a working ROP, and whether this ROP can achieve the exploitation target. We can enhance the difficulty of ROP attacks through adversarial approaches related to ROP mitigation mechanisms (which aim to reduce gadgets in the program and increase their complexity). This is a cost-effective endeavor. I believe OpenBSD has been continuously improving in this regard since 2018, making it more advanced compared to other operating systems. By simply adjusting compilation parameters, you can reduce the number of gadgets and make ROP attacks more difficult. With the results of our tool's experiments, we can mutually enhance this aspect, making it better!
However, the ultimate goal of ROP attacks is not just to call the syscall instruction. They can also perform arbitrary function calls, arbitrary memory writes, or arbitrary memory reads, among various types of exploitation primitives. All of these primitives can assist in the final exploitation. Still, they require the selection and chaining of gadgets to achieve these actions, making it meaningful to increase the difficulty of using gadgets. Best regards, ZoE Nan ZoE <zoen...@gmail.com> 于2023年10月12日周四 23:21写道： > 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. >> >
