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

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

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

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

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.

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

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

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

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

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

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

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

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

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

2023-10-09 Thread Nan ZoE
uggested 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 Removi

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

2023-10-09 Thread fro
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 understanding

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

2023-10-07 Thread Nan ZoE
d to put your focus on 7.3 release or >> -current if you are interested in someone taking you seriously. >> >> 7.4 will also be released in the next month or so. >> >> >> >> >> >> Sent: Thursday, September 21, 2023 at 9:50 PM >> From: "N

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

2023-09-22 Thread Theo de Raadt
s 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 ingenious.

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 After Re

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