Re: snmpd; Fix use after free for appl_request_upstream

2023-10-27 Thread Martijn van Duren
On Thu, 2023-10-26 at 21:38 +0200, Theo Buehler wrote: > On Thu, Oct 26, 2023 at 11:51:00AM +0200, Martijn van Duren wrote: > > This case is covered by the new regress' backend_get_toofew and > > backend_get_toomany tests. However, even with MALLOC_OPTIONS cranked > > to the max it's really hard

Re: Removing syscall(2) from libc and kernel

2023-10-27 Thread Lucas Gabriel Vuotto
On Fri, Oct 27, 2023 at 09:36:25AM -0600, Theo de Raadt wrote: > Index: sys/arch/m88k/m88k/trap.c > === > RCS file: /cvs/src/sys/arch/m88k/m88k/trap.c,v > diff -u -p -u -r1.128 trap.c > --- sys/arch/m88k/m88k/trap.c 2 Aug 2023

Re: Removing syscall(2) from libc and kernel

2023-10-27 Thread Theo de Raadt
Theo de Raadt wrote: > Piece by piece, I've been trying to remove the easiest of the > terminal-actions that exploit code uses (ie. getting to execve, or performing > other system calls, etc). > Snapshots for some architectures now contain kernel diffs which reject > syscall(2). The symbol

Re: Removing syscall(2) from libc and kernel

2023-10-27 Thread Theo de Raadt
Theo de Raadt wrote: > Piece by piece, I've been trying to remove the easiest of the > terminal-actions that exploit code uses (ie. getting to execve, or performing > other system calls, etc). > So in this next step, I'm going to take away the ability to perform syscall #0 > (SYS_syscall), with

Removing syscall(2) from libc and kernel

2023-10-27 Thread Theo de Raadt
Piece by piece, I've been trying to remove the easiest of the terminal-actions that exploit code uses (ie. getting to execve, or performing other system calls, etc). I recognize we can never completely remove all mechanisms they use. However, I hope I am forcing attack coders into using

Re: bgpd: cleanup optparamlen handling in session_open

2023-10-27 Thread Theo Buehler
On Fri, Oct 27, 2023 at 01:06:31PM +0200, Claudio Jeker wrote: > In the big ibuf API refactor I also broke the optparamlen handling > by using one variable for two things. > > All the size handling in session_open() can be simplified since > ibuf_size() is cheap to call. > > I think the result

bgpd: cleanup optparamlen handling in session_open

2023-10-27 Thread Claudio Jeker
In the big ibuf API refactor I also broke the optparamlen handling by using one variable for two things. All the size handling in session_open() can be simplified since ibuf_size() is cheap to call. I think the result is cleaner than the code before. It is still somewhat funky because there are

Re: bgpd fix holdtime in session_open

2023-10-27 Thread Theo Buehler
On Fri, Oct 27, 2023 at 11:27:11AM +0200, Claudio Jeker wrote: > While looking for something else I noticed this error. > > The holdtime is written into the buffer with ibuf_add_n16() so the htons() > call is done in the ibuf add call. So there is no need for the htons() > when assigning

bgpd fix holdtime in session_open

2023-10-27 Thread Claudio Jeker
While looking for something else I noticed this error. The holdtime is written into the buffer with ibuf_add_n16() so the htons() call is done in the ibuf add call. So there is no need for the htons() when assigning holdtime. -- :wq Claudio Index: session.c