OpenBSD Errata: September 27, 2021 (libressl)

2021-09-26 Thread Sebastian Benoit 
An errata patch for LibreSSL has been released for OpenBSD 6.8 and
OpenBSD 6.9.

A stack overread could occur when checking X.509 name constraints.

Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility.  Source code patches can be found on the
respective errata page:

  https://www.openbsd.org/errata68.html
  https://www.openbsd.org/errata69.html

OpenBSD Errata: September 27, 2021 (sshd)

2021-09-26 Thread Sebastian Benoit 
An errata patch for sshd(8) has been released for OpenBSD 6.8 and
OpenBSD 6.9.

  sshd(8) from OpenSSH 6.2 (OpenBSD 5.3) through 8.7 (OpenBSD 6.9) failed to
  correctly initialise supplemental groups when executing an
  AuthorizedKeysCommand or AuthorizedPrincipalsCommand, where a
  AuthorizedKeysCommandUser or AuthorizedPrincipalsCommandUser directive has
  been set to run the command as a different user. Instead these commands
  would inherit the groups that sshd(8) was started with.

  Depending on system configuration, inherited groups may allow
  AuthorizedKeysCommand/AuthorizedPrincipalsCommand helper programs to gain
  unintended privilege.

  Neither AuthorizedKeysCommand nor AuthorizedPrincipalsCommand are enabled
  by default in sshd_config(5).

Binary updates for the amd64, i386 and arm64 platform are available
via the syspatch utility.  Source code patches can be found on the
respective errata page:

  https://www.openbsd.org/errata68.html
  https://www.openbsd.org/errata69.html

Re: sigwaitinfo(2) and sigtimedwait(2)

2021-09-26 Thread Mark Kettenis 
> Date: Fri, 24 Sep 2021 19:36:21 +0200
> From: Rafael Sadowski 
> 
> I'm trying to port the more KDE stuff so my question is from porter
> perspective.
> 
> I need sigwaitinfo(2)/sigtimedwait(2) and I found both functions in
> lib/libc/gen/sigwait.c with the comment "need kernel to fill in more
> siginfo_t bits first". Is the comment still up to date? If no, is it
> possible to unlock the functions?

Still true.  These functions are somewhat underspecified by POSIX so
it isn't really obvious whatadditional bits need to be filled in.
Having examples of code that use these interfaces from ports could
help with that.

snmpd(8): Log correct engineid

2021-09-26 Thread Martijn van Duren 
ober_get_nstring writes a pointer to buf and does not overwrite the
content of buf itself. So pushing an array in there will result in it
only writing the pointer address to the array, which is not exactly what
we want to show.

I choose to go for sizeof, instead of using the define to be a little
more on the safe side, but I didn't change SNMPD_MAXCONTEXNAMELEN to
keep the diff small.

OK?

martijn@

Index: snmpe.c
===
RCS file: /cvs/src/usr.sbin/snmpd/snmpe.c,v
retrieving revision 1.76
diff -u -p -r1.76 snmpe.c
--- snmpe.c 6 Sep 2021 13:32:18 -   1.76
+++ snmpe.c 26 Sep 2021 08:19:59 -
@@ -237,7 +237,7 @@ snmpe_parse(struct snmp_message *msg)
long longerrval, erridx;
u_intclass;
char*comn;
-   char*flagstr, *ctxname;
+   char*flagstr, *ctxname, *engineid;
size_t   len;
struct sockaddr_storage *ss = >sm_ss;
struct ber_element  *root = msg->sm_req;
@@ -300,9 +300,12 @@ snmpe_parse(struct snmp_message *msg)
}
 
if (ober_scanf_elements(a, "{xxeS$}$",
-   >sm_ctxengineid, >sm_ctxengineid_len,
-   , , >sm_pdu) != 0)
+   , >sm_ctxengineid_len, , ,
+   >sm_pdu) != 0)
goto parsefail;
+   if (msg->sm_ctxengineid_len > sizeof(msg->sm_ctxengineid))
+   goto parsefail;
+   memcpy(msg->sm_ctxengineid, engineid, msg->sm_ctxengineid_len);
if (len > SNMPD_MAXCONTEXNAMELEN)
goto parsefail;
memcpy(msg->sm_ctxname, ctxname, len);