Re: Starting Homebridge / nodejs daemon at boot

[Aaron Mason]

On Wed, Oct 11, 2023 at 11:38 AM Manuel Kuklinski  wrote:
>
> Hi!
>
> I can't get homebridge started at boot - it starts with the following
> rc.d script if running as root after logging in, but fails to be present
> at boot time:
>

I have a similar issue with PHP and Perl based FastCGI apps. My
solution was a startup script that runs every minute in cron, that
would give me the ability to command a restart and offer a brake if
the program crashes. Something like this:

#!/bin/sh

NOSTART=~/path/to/nostart
KILLFILE=~/path/to/killfile
PIDFILE=~/path/to/pidfile

if [ -e "$KILLFILE" ]
then
# Kill and cleanup
kill `cat "$PIDFILE"`
rm -f $KILLFILE $PIDFILE
elif [ -e "$PIDFILE" ]
then
# Check if it's still running
if ! kill -0 `cat "$PIDFILE" 2>/dev/null
then
rm -f $PIDFILE
else
exit 0
fi
fi

# Don't try to start if the nostart file is there
[ -e "$NOSTART" ] && exit 0

/path/to/the/executable --option1 -o 2 &
echo $!>>$PIDFILE

# Create no start file so it doesn't try to restart after a failure
touch $NOSTART

-- 
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse

Re: OpenBSD 7.4

[Jacqueline Jolicoeur]

On Oct 12 19:54, Karel Lucas wrote:
> Is it already known when openBSD 7.4 will be released? I would like to know
> that, because of a project I am working on.

I usually track the following file.

https://cvsweb.openbsd.org/src/etc/root/root.mail

Date: Oct 16 07:04:00 MDT 2023

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: vmd and /dev/sd*

[Mike Larkin]

On Thu, Oct 12, 2023 at 09:24:33AM -0600, Theo de Raadt wrote:
> Manuel Giraud  wrote:
>
> > > Manuel Giraud  writes:
> > >
> > >> Hi,
> > >>
> > >> I can't find the information on this list (or elsewhere).  Is it
> > >> possible to have a vm that access a disk through its device?  The
> > >> following does not seem to work:
> > >>
> > >> # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm
> > >> vmctl: start vm command failed: Unknown error: -1
> > >
> > > No, passing file descriptors to devices over ipc sockets isn't currently
> > > allowed by the kernel. You'd need to use the raw character device, too,
> > > afaik if passing them were allowed.
> >
> > Ok, noted.  BTW I have the same error passing the raw character device.
>
>
>
> I made the decision to not allow passing of weird file descriptor types
> very intentionally.  I'm still very sure that is the right decision.
>
> Here's 1 program which wants to do it, but the other 1000 pledge'd programs
> are being protected from being passed an incorrect fd and then doing system
> calls upon it which behave "different".  By that, I mean seek, read, and
> write short-operation behaviours are subtly different outside of files and
> sockets, and it would also expose some ioctl (which is MOSTLY limited by
> pledge, but ioctl "request" values are just numbers, and they can overlap in
> surprising ways).
>

I would like to make clear that vmd does not "want to do it", and that I agree
that the current design of not being able to pass these types of fds is
correct. It may be slightly inconvient for certain niche use cases, but not
worth weakening everything else or putting in hacks. Just dd the device you
want to a .raw file and use that.

-ml

Re: OpenBSD 7.4

[Daniele B.]

Thanks for the date, helpful and well received..



-- Daniele Bonini

Re: OpenBSD 7.4

[Theo de Raadt]

Don't be ridiculous, there is no point to be so obtuse.

The date is already visible in many files in our tree, and you know it.

Oct 16.

Peter N. M. Hansteen  wrote:

> On Thu, Oct 12, 2023 at 07:54:04PM +0200, Karel Lucas wrote:
> > Is it already known when openBSD 7.4 will be released? I would like to know
> > that, because of a project I am working on.
> 
> The exact date will not be generally known until it happens if recent releases
> are anything to go by. 
> 
> That said, you can be quite sure that the project has planned for
> a specific date. 
> 
> Traditionally the release dates have been November 1st and May 1st, but 
> several times the release has been earlier, up to a couple of weeks
> in some cases. 
> 
> So my advice would be to plan for November 1st as a time that release
> will be available. 
> 
> And anyway it will be useful to move any not yet upgraded systems to
> 7.3 ahead of that date, since 7.2 will join the ranks of no longer 
> supported releases the moment 7.4 becomes generally available.
> 
> - 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: OpenBSD 7.4

[Peter N. M. Hansteen]

On Thu, Oct 12, 2023 at 07:54:04PM +0200, Karel Lucas wrote:
> Is it already known when openBSD 7.4 will be released? I would like to know
> that, because of a project I am working on.

The exact date will not be generally known until it happens if recent releases
are anything to go by. 

That said, you can be quite sure that the project has planned for
a specific date. 

Traditionally the release dates have been November 1st and May 1st, but 
several times the release has been earlier, up to a couple of weeks
in some cases. 

So my advice would be to plan for November 1st as a time that release
will be available. 

And anyway it will be useful to move any not yet upgraded systems to
7.3 ahead of that date, since 7.2 will join the ranks of no longer 
supported releases the moment 7.4 becomes generally available.

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

OpenBSD 7.4

[Karel Lucas]

Is it already known when openBSD 7.4 will be released? I would like to 
know that, because of a project I am working on.

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: vmd and /dev/sd*

[Theo de Raadt]

Manuel Giraud  wrote:

> > Manuel Giraud  writes:
> >
> >> Hi,
> >>
> >> I can't find the information on this list (or elsewhere).  Is it
> >> possible to have a vm that access a disk through its device?  The
> >> following does not seem to work:
> >>
> >> # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm
> >> vmctl: start vm command failed: Unknown error: -1
> >
> > No, passing file descriptors to devices over ipc sockets isn't currently
> > allowed by the kernel. You'd need to use the raw character device, too,
> > afaik if passing them were allowed.
> 
> Ok, noted.  BTW I have the same error passing the raw character device.



I made the decision to not allow passing of weird file descriptor types
very intentionally.  I'm still very sure that is the right decision.

Here's 1 program which wants to do it, but the other 1000 pledge'd programs
are being protected from being passed an incorrect fd and then doing system
calls upon it which behave "different".  By that, I mean seek, read, and
write short-operation behaviours are subtly different outside of files and
sockets, and it would also expose some ioctl (which is MOSTLY limited by
pledge, but ioctl "request" values are just numbers, and they can overlap in
surprising ways).

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: vmd and /dev/sd*

[Manuel Giraud]

Dave Voutila  writes:

> Manuel Giraud  writes:
>
>> Hi,
>>
>> I can't find the information on this list (or elsewhere).  Is it
>> possible to have a vm that access a disk through its device?  The
>> following does not seem to work:
>>
>> # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm
>> vmctl: start vm command failed: Unknown error: -1
>
> No, passing file descriptors to devices over ipc sockets isn't currently
> allowed by the kernel. You'd need to use the raw character device, too,
> afaik if passing them were allowed.

Ok, noted.  BTW I have the same error passing the raw character device.

>> What would be the alternatives?
>
> None I know of.

FTR, I end up creating a disk image, configure as vnd and copy my files
here.  I could then use this image as vmctl disk.  Thanks.
-- 
Manuel Giraud

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: vmd and /dev/sd*

[Dave Voutila]

Manuel Giraud  writes:

> Hi,
>
> I can't find the information on this list (or elsewhere).  Is it
> possible to have a vm that access a disk through its device?  The
> following does not seem to work:
>
> # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm
> vmctl: start vm command failed: Unknown error: -1

No, passing file descriptors to devices over ipc sockets isn't currently
allowed by the kernel. You'd need to use the raw character device, too,
afaik if passing them were allowed.

>
> What would be the alternatives?

None I know of.

vmd and /dev/sd*

[Manuel Giraud]

Hi,

I can't find the information on this list (or elsewhere).  Is it
possible to have a vm that access a disk through its device?  The
following does not seem to work:

# vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm 
vmctl: start vm command failed: Unknown error: -1

What would be the alternatives?

Thanks,
-- 
Manuel Giraud

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: debugging "invalid argument" errors when loading elf files

[Lorenz (xha)]

> PT_PHDR is the tag for an entry in the program headers that points to the
> program headers themselves.  Some ELF files (for example, core files) have
> a program header but don't include a PT_PHDR entry in it.  It's presumably
> not added by ld because you supplied a linker script and ld is trying to
> give you as much control as possible.  Some of the other arguments you
> supplied may have required it to fill in other details, but including a
> DT_PHDR entry in the program header is apparently not one of them.
> 
> As Theo says, this sort of thing makes linker scripts very subtle, with
> arch dependencies**, interactions with RELRO and W^X processing, and plain
> ABI weirdness.  Even those of us who have written several of them often
> have to start from what 'readelf -lS' shows the default is to put together
> a starting point and massage it from there to achieve whatever our goal for
> going through this effort is.
> 
> ** e.g., permissions on and immutability of .plt, .got, etc sections vary.
> Some archs have
> required some sections to be before or after others due to the CPU treating
> a limited range
> offset in some instructions as unsigned, so 'before' cannot be reached
> 

thank you for the explaination :)

> The .init section of the executable itself is invoked by the entry point
> code in crt0 before main is called, not libc.  At a low level, that's done
> not via DT_INIT's value or the section name but via a symbol placed in the
> section which would presumably be carried along if you renamed the section,
> so you can't affect that.
> 
> The .init_array section is handled by ld.so in dynamic programs where it's
> located via DT_INIT_ARRAY, and by crt0 in static programs where it's
> located via *_start and *_end symbols which I _guess_ would be from
> whatever ended up with the .init_array section name, so maybe renaming the
> section would prevent them from being invoked in that case, but I'm not
> sure and that an implementation detail that might change.
> 
> (Moving a chunk of the crt0 code into libc would be possible (glibc did it,
> for example) and might make some evolution easier, but it hasn't happened.)
> 
> ...but, backing up...what problem exists with the ordering that currently
> happens that makes you believe you need to interpose and have the "hare
> runtime" (sorry, I'm not familiar with that) execute them?  How will you
> measure success of the change?

the problem is that in hare, the @init functions expect stuff like the
global envpointer array (rt::envp) to be initilized. so that needs to be
done before the @init functions are ran.

so, digging deeper into crt0.c, i found the .preinit_array section which
looks perfect to what i am trying to do. i added the init function to that
section and indeed, it works as expected! :)

now i don't need a linker script anymore; thanks for the help and
showing me how horrible linker scripts are

- lorenz