Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Theo de Raadt
Nan ZoE wrote: > Sure, thank you for your patient response. > > I will continue to refine my work and attempt to develop some > countermeasures against ROP mitigation. If there's good news, I will > contact OpenBSD again! By the way, the first idea I provided, which is > "Zeroing registers befor

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Nan ZoE
Sure, thank you for your patient response. I will continue to refine my work and attempt to develop some countermeasures against ROP mitigation. If there's good news, I will contact OpenBSD again! By the way, the first idea I provided, which is "Zeroing registers before function returns," has alre

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Theo de Raadt
> We would like to collaborate with OpenBSD in researching how to reduce the > number of gadgets and increase the difficulty of using gadgets. I've think I've vaguely explained how that works. All the mitigations efforst went like this: 1) come up with an idea 2) write a complete working prototy

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Nan ZoE
Hello, It's possible that using "exploitable" might not be an appropriate term. Perhaps I should change it to "evaluate". Our goal remains to assess the ROP construction capabilities of the gadget sets within programs, which is the correct approach. Additionally, it's great to see that OpenBSD ca

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Theo de Raadt
Nan ZoE wrote: > 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

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Nan ZoE
Hello, I'm sorry to bother you again, and I appreciate your thoughtful responses. I would like to clarify that the process of ROP exploitation may involve bypassing certain security mechanisms (such as address randomization) and the execution of gadgets. Our focus is on the latter part, which is h

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Theo de Raadt
Nan ZoE wrote: > 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

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Nan ZoE
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 sy

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Nan ZoE
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 involve

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Theo de Raadt
Nan ZoE wrote: > In comparison, a more straightforward example is the "as" program. The ROP > payload > > for > this program is relatively simple, and it can also achieve the ROP target > of calling ex

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Theo de Raadt
> 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 constr

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Theo de Raadt
Nan ZoE 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 meanin

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-12 Thread Nan ZoE
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. We are working on implementing a tool similar to angrop and ropium

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-11 Thread Theo de Raadt
Nan ZoE 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

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-09 Thread Nan ZoE
the suggested experiments other than to say that having a > wider audience may be of help. > > > > > > > Sent: Saturday, October 07, 2023 at 8:13 PM > From: "Nan ZoE" > To: misc@openbsd.org > Subject: Re: ROP Exploitation in openbsd-64 Programs After R

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-09 Thread fro
13 PM From: "Nan ZoE" To: misc@openbsd.org Subject: Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets Hello, Thank you very much for all your suggestions first. After our last discussion, I conducted some additional experiments and gained a more detailed understan

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-10-07 Thread Nan ZoE
shows improvements in these specific areas that you mention. >> >> However, I don't want to discourage you from testing mitigations but as >> Peter and Theo said you really need to put your focus on 7.3 release or >> -current if you are interested in someone taking you se

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-09-22 Thread Theo de Raadt
one is happening soon. > > > > > > > > > > Sent: Thursday, September 21, 2023 at 8:50 AM > > From: "Nan ZoE" > > To: misc@openbsd.org > > Subject: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets > > Hello, > > >

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-09-21 Thread Peter N. M. Hansteen
On Fri, Sep 22, 2023 at 12:50:37PM +0800, Nan ZoE wrote: > Because, as far as I understand, these ROP mitigation mechanisms seem to > have been updated only in the three versions of OpenBSD, namely 6.3 to 6.5 > . Of course, I have also studied some > programs under

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-09-21 Thread Nan ZoE
" > To: misc@openbsd.org > Subject: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets > Hello, > > > > I have read your paper regarding the ROP mitigation mechanism (Removing ROP > Gadgets from OpenBSD), and I find the defense against ROP quite ingeni

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-09-21 Thread fro
Why are you targeting 6.4? That was released in 2018. So, that's 5 years and 9 releases since then and another one is happening soon.       Sent: Thursday, September 21, 2023 at 8:50 AM From: "Nan ZoE" To: misc@openbsd.org Subject: ROP Exploitation in openbsd-64 Programs Aft

Re: ROP Exploitation in openbsd-64 Programs After Removing ROP Gadgets

2023-09-21 Thread Theo de Raadt
There is no comprehensive & final solution for RET polymorphism due to variable-sized instruction architecture, and the only solution is to move to fixed-sized architectures where all RETs can be protected and ROP-free therefore becomes possible. The best we can do is reduce it. The ability to re