Nan ZoE <zoen...@gmail.com> 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.
