Nan ZoE <zoen...@gmail.com> wrote: > Thank you for your response. It seems there might be some misunderstanding > about what > I'm researching. Allow me to explain the experiments I'm conducting in more > detailed.
I'm looking at the Subject. It uses the word "Exploitation". That word has a very specific meaning in this field. You are saying you are able to use ROP methods to *take advantage* of software, meaning, raise your capabilities and abuse the software to do something you should not be able to do. I do not see evidence to match that claim. > We are working on implementing a tool similar to angrop and ropium. These > tools aim to > automate ROP attacks. Such tools were initially introduced in the paper Q: > Exploit > Hardening Made Easy. These tools and papers generally assume the ability to > bypass > ASLR and other address randomization techniques, focusing more on automating > the > selection and chaining of Gadgets in a given program to construct an ROP > payload. I don't find that interesting, because it is extremely old news that you can't remove ALL the polymorphic gadgets in variable size instruction architectures. That is exactly why we work on adding other mitigations instead. Such as "ASLR and other address randomization techniques". > I'm not entirely clear about the meaning of your statement, "You cannot see > where in > memory the binary is mapped." However, I gather from the sentence, "What info > leak are > you exercising to extract libc.so's location, and per-boot layout, and then > precisely > target the specific 'syscall' instruction?" that you may be referring to the > challenge > of not being able to accurately determine the address of the 'syscall' > instruction due > to address randomization. So 5 emails deep in the thread, we are finally told the basis of your work is an assumption you have 100% visibility on the execution layout. Not just a tiny info leak, but the mother of all info leaks. That's not exploitation, that's synthetic. > I also checked the protection mechanisms for programs in OpenBSD 7.3 using the > 'checksec' tool from pwn. OpenBSD enables PIE (Position Independent > Executable) code > address randomization protection. When faced with address randomization, many > exploits > require first achieving an address leak or employing other ASLR bypass > techniques > before proceeding with further privilege escalation. However, our primary > focus is not > on address leak methods, as they can vary significantly and are closely tied > to the > specific vulnerability and program. Instead, we concentrate on automating the > Gadget > selection and chaining process to achieve privilege escalation ultimately. Your logic isn't based upon an info leak, but upon a info leak of the entire program by running it inside your exploit program. That's so synthetic it is laughable. > Our experiments revolve around evaluating the ROP construction capability of > each > program's Gadget collection. In other words, we assess the maximum ROP > construction > potential of each program's distinct Gadget collection. Initially, we assume > that the > issue of address randomization can be bypassed using known address leak > vulnerabilities/exploitation techniques. For our experiments, we disable the > address > randomization protection mechanism in the programs. That is incredibly boring, because there are no solutions that entirely remove polymorphic ROP. > In our experiments, we extracted 264 programs from OpenBSD 7.3, which we have > made > available in the orig folder on Github. We then injected simple stack overflow > vulnerabilities into these programs using objcopy, while preserving all the > original > program's code to ensure the integrity of the original Gadget collection. We > placed > the programs with injected vulnerabilities in the vuln folder on Github, with > each > program corresponding to a specific one in the orig folder. > > 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. Wow. > 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. There you go again, using the phase "exploitation". You have exploited nothing. Your approach is entirely synthetic and there is no escalation of privs or capabilities in it. It is IMPOSSIBLE to remove all the ROP gadgets on a variable instruction architecture, they occur polymorphically nested inside other instructions. This is well known. There were talks and papers about this 20 years ago. I see nothing original being shared here. We never claimed to have fixed this on amd64. A variety of improvements resulted in some reduction, but I suspect there are only small gains to be made with further toolchain instruction selection changes. The architecture is fast and common, but this problem is highly intractible. We do make much stronger (optimistic) claims about the improvement made on fixed-size-instruction architectures, where "ROP-free" is plausible. Previously you listed a couple of things which may slightly reduce the usability of gadgets, but you didn't supply any compiler modifications to try that, nor did you engage in measurement of the performance impact or the false positive behaviours in real world software (which must be fixed before any such proposals can move forward). None of them were original, either. They've been proposed before, but noone does the actual work to validate. I suspect that's because most people recognize the *OTHER MIGITATIONS YOU IGNORE* are making a big enough difference. So what I'm seeing from you can be summarized as "Just like in 2001, x86 ROP works if all other mitigation efforts are ignored". Well gee, the processors didn't change that much. I thought there would be something interesting, and I am dissapointed.
