Re: Starting Homebridge / nodejs daemon at boot

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

Re: OpenBSD 7.4

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

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

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

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

Re: vmd and /dev/sd*

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

Re: OpenBSD 7.4

Thanks for the date, helpful and well received.. -- Daniele Bonini

Re: OpenBSD 7.4

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

Re: OpenBSD 7.4

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

OpenBSD 7.4

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

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

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

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

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

Nan ZoE wrote: > Hello, Thank you for your response. > > I'm sorry, I just looked at the introduction of pinsyscall. If OpenBSD only > uses > pinsyscall, calling syscall is a challenge in exploitation. However, I'm not > sure if > this is a required protection mechanism for all programs.

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

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

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

Nan ZoE wrote: > Additionally, it's reasonable to assess the correctness of the ROP payloads > we generate for a program by injecting vulnerabilities. Firstly, the > original gadget set in the program remains intact and usable. Secondly, > this method of injecting vulnerabilities is equivalent

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

Hello, Thank you for your response. I'm sorry, I just looked at the introduction of pinsyscall. If OpenBSD only uses pinsyscall, calling syscall is a challenge in exploitation. However, I'm not sure if this is a required protection mechanism for all programs. What happens if a user inlines the

Re: vmd and /dev/sd*

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

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

Hello, Thank you for your response. We don't have 100% visibility into memory. We are merely using a simple stack overflow vulnerability to verify the feasibility of the ROP we generate. Bypassing addresses randomization issues in program code segments (e.g., .text code segment) and often

Re: vmd and /dev/sd*

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

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

Nan ZoE wrote: > In comparison, a more straightforward example is the "as" program. The ROP > payload > > for > this program is relatively simple, and it can also achieve the ROP target > of calling

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

> Please note that after injecting the vulnerabilities, the programs execute > the '*main*' function from the vulnerable program, not the entry function > from the original program. However, the Gadgets from the original program > are still usable. This approach allows us to evaluate the ROP

Re: vmd and /dev/sd*

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:

vmd and /dev/sd*

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

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

Nan ZoE wrote: > Thank you for your response. It seems there might be some misunderstanding > about what > I'm researching. Allow me to explain the experiments I'm conducting in more > detailed. I'm looking at the Subject. It uses the word "Exploitation". That word has a very specific

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

Thank you for your response. It seems there might be some misunderstanding about what I'm researching. Allow me to explain the experiments I'm conducting in more detailed. We are working on implementing a tool similar to angrop and ropium

Re: debugging "invalid argument" errors when loading elf files

> 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