Re: (fwd) [FD] OpenBSD kernel relinking is not transactional and a local exploit exists
On Tue, Jun 20, 2023 at 9:27 AM Tomasz Rola wrote: > > [REDACTED] > > https://marc.info/?l=openbsd-bugs=159074964523007=2 (noted lack of > idempotency) > https://marc.info/?l=openbsd-bugs=168688579123005=2 (noted lack of > integrity or provenance verification and the consumption of invalid > objects) Had a flick through the threads listed above. That's some Olympics-level mental gymnastics right there. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: (fwd) [FD] OpenBSD kernel relinking is not transactional and a local exploit exists
Like Theo said, if an attacker has root on your system, having the kernel relink messed with is the least of your concerns. On Tue, Jun 20, 2023 at 9:27 AM Tomasz Rola wrote: > > This happened in my mailbox today. FD means "full disclosure" and is > publicly available mailing list. > > I repost onto misc because if this is a real cat, seems it is out of > the bag already. Other than being subscribed to FD, I have no > connection. > > - Forwarded message from "Schech, C. W. (\"Connor\")" > - > > Date: Sat, 17 Jun 2023 09:40:16 + > From: "Schech, C. W. (Connor)" > To: fulldisclos...@seclists.org > Subject: [FD] OpenBSD kernel relinking is not transactional and a local > exploit > exists > > The automatic and mandatory-by-default reordering of OpenBSD kernels > is NOT transactional and as a result, a local unpatched exploit exists > which allows tampering or replacement of the kernel. Arbitrary build > artifacts are cyclically relinked with no data integrity or provenance > being maintained or verified for the objects being consumed with > respect to the running kernel before and during the execution of the > mandatory kernel_reorder process in the supplied /etc/rc and > /usr/libexec scripts. The reordering occurs at the end of installation > process and also automatically every reboot cycle thereafter unless > manually bypassed by a knowledgable party. > > The kernel_reorder routine verifies a SHA256 signature for the linked > kernel from last boot but does not verify the integrity or provenance > of any objects kept in the kernel "link kit" installed in > /usr/share/relink, so arbitrary objects can be injected and > automatically relinked at the next startup. I have verified that it is > indeed the case that both valid kernels with a different uname and > kernels which cause data destruction due to over-tuning of a subset of > the components which were compiled manually and copied into > /usr/share/relink and crash the system after being booted once > relinked but which do not match the build of the running kernel at the > time they were copied into /usr/share/relink as working > proof-of-concept exploits. > > Install media are also open to tampering and exploitation as signed > checksum data are not carried with the install sets inside the > installation image and an improperly-encapsulated poorly-documented > tarball of unverifiable (in the sense of SLSA) kernel objects is > embedded in the base distribution and then relinked with a new random > ordering of the objects cyclically between boot cycles. > > Sites with a strong security posture are advised that this is a > critical vulnerability and likely deliberate back door into the > system. Additionally, OpenBSD leaks the state of the pseudorandom > number generator to predictable locations on disk and in system memory > at a fixed point during every start up and shutdown procedure. The > lack of build process hardening has been on-going for over three > years. Theo de Raadt is disinterested in improving or reviewing the > design or providing any further clarification, as he has stated on the > mailing list when shortfalls in the relinking process were reported > over the past ~3 years. I hope that this can come to the attention of > a third-party technical expert with standing in the computer security > industry. > > Workaround: > > As the link kit is embedded in the base distribution and automatically > relinked without an option to disable it in the provided installation > script it requires manual removal at present. > > Cf. > > https://marc.info/?l=openbsd-bugs=159074964523007=2 (noted lack of > idempotency) > https://marc.info/?l=openbsd-bugs=168688579123005=2 (noted lack of > integrity or provenance verification and the consumption of invalid > objects) > > https://slsa.dev/spec/v1.0/levels#build-l2-hosted-build-platform: > > "Track/Level Requirements Focus > Build L3 Hardened build platform Tampering during the build" > ___ > Sent through the Full Disclosure mailing list > https://nmap.org/mailman/listinfo/fulldisclosure > Web Archives & RSS: https://seclists.org/fulldisclosure/ > > > - End forwarded message - > -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: (fwd) [FD] OpenBSD kernel relinking is not transactional and a local exploit exists
That writeup is bullshit. If an attacker can replace files owned by root, they can replace other files rather than these files. Why replace some .o files and depend on a future reboot, I dunno, replacing ssh, or ksh, some things in /etc, or tens of thousands of other files? OR, why not replace the sha256 command? It is a completely garbage report, which was on our mailing list before, and the author is doubling down by taking his views to other places. Tomasz Rola wrote: > This happened in my mailbox today. FD means "full disclosure" and is > publicly available mailing list. > > I repost onto misc because if this is a real cat, seems it is out of > the bag already. Other than being subscribed to FD, I have no > connection. > > --- Forwarded Message > > Date: Sat, 17 Jun 2023 09:40:16 + > From: "Schech, C. W. (Connor)" > To: fulldisclos...@seclists.org > Subject: [FD] OpenBSD kernel relinking is not transactional and a local > exploit > exists > > The automatic and mandatory-by-default reordering of OpenBSD kernels > is NOT transactional and as a result, a local unpatched exploit exists > which allows tampering or replacement of the kernel. Arbitrary build > artifacts are cyclically relinked with no data integrity or provenance > being maintained or verified for the objects being consumed with > respect to the running kernel before and during the execution of the > mandatory kernel_reorder process in the supplied /etc/rc and > /usr/libexec scripts. The reordering occurs at the end of installation > process and also automatically every reboot cycle thereafter unless > manually bypassed by a knowledgable party. > > The kernel_reorder routine verifies a SHA256 signature for the linked > kernel from last boot but does not verify the integrity or provenance > of any objects kept in the kernel "link kit" installed in > /usr/share/relink, so arbitrary objects can be injected and > automatically relinked at the next startup. I have verified that it is > indeed the case that both valid kernels with a different uname and > kernels which cause data destruction due to over-tuning of a subset of > the components which were compiled manually and copied into > /usr/share/relink and crash the system after being booted once > relinked but which do not match the build of the running kernel at the > time they were copied into /usr/share/relink as working > proof-of-concept exploits. > > Install media are also open to tampering and exploitation as signed > checksum data are not carried with the install sets inside the > installation image and an improperly-encapsulated poorly-documented > tarball of unverifiable (in the sense of SLSA) kernel objects is > embedded in the base distribution and then relinked with a new random > ordering of the objects cyclically between boot cycles. > > Sites with a strong security posture are advised that this is a > critical vulnerability and likely deliberate back door into the > system. Additionally, OpenBSD leaks the state of the pseudorandom > number generator to predictable locations on disk and in system memory > at a fixed point during every start up and shutdown procedure. The > lack of build process hardening has been on-going for over three > years. Theo de Raadt is disinterested in improving or reviewing the > design or providing any further clarification, as he has stated on the > mailing list when shortfalls in the relinking process were reported > over the past ~3 years. I hope that this can come to the attention of > a third-party technical expert with standing in the computer security > industry. > > Workaround: > > As the link kit is embedded in the base distribution and automatically > relinked without an option to disable it in the provided installation > script it requires manual removal at present. > > Cf. > > https://marc.info/?l=openbsd-bugs=159074964523007=2 (noted lack of > idempotency) > https://marc.info/?l=openbsd-bugs=168688579123005=2 (noted lack of > integrity or provenance verification and the consumption of invalid > objects) > > https://slsa.dev/spec/v1.0/levels#build-l2-hosted-build-platform: > > "Track/Level Requirements Focus > Build L3 Hardened build platform Tampering during the build" > ___ > Sent through the Full Disclosure mailing list > https://nmap.org/mailman/listinfo/fulldisclosure > Web Archives & RSS: https://seclists.org/fulldisclosure/ > >
(fwd) [FD] OpenBSD kernel relinking is not transactional and a local exploit exists
This happened in my mailbox today. FD means "full disclosure" and is publicly available mailing list. I repost onto misc because if this is a real cat, seems it is out of the bag already. Other than being subscribed to FD, I have no connection. - Forwarded message from "Schech, C. W. (\"Connor\")" - Date: Sat, 17 Jun 2023 09:40:16 + From: "Schech, C. W. (Connor)" To: fulldisclos...@seclists.org Subject: [FD] OpenBSD kernel relinking is not transactional and a local exploit exists The automatic and mandatory-by-default reordering of OpenBSD kernels is NOT transactional and as a result, a local unpatched exploit exists which allows tampering or replacement of the kernel. Arbitrary build artifacts are cyclically relinked with no data integrity or provenance being maintained or verified for the objects being consumed with respect to the running kernel before and during the execution of the mandatory kernel_reorder process in the supplied /etc/rc and /usr/libexec scripts. The reordering occurs at the end of installation process and also automatically every reboot cycle thereafter unless manually bypassed by a knowledgable party. The kernel_reorder routine verifies a SHA256 signature for the linked kernel from last boot but does not verify the integrity or provenance of any objects kept in the kernel "link kit" installed in /usr/share/relink, so arbitrary objects can be injected and automatically relinked at the next startup. I have verified that it is indeed the case that both valid kernels with a different uname and kernels which cause data destruction due to over-tuning of a subset of the components which were compiled manually and copied into /usr/share/relink and crash the system after being booted once relinked but which do not match the build of the running kernel at the time they were copied into /usr/share/relink as working proof-of-concept exploits. Install media are also open to tampering and exploitation as signed checksum data are not carried with the install sets inside the installation image and an improperly-encapsulated poorly-documented tarball of unverifiable (in the sense of SLSA) kernel objects is embedded in the base distribution and then relinked with a new random ordering of the objects cyclically between boot cycles. Sites with a strong security posture are advised that this is a critical vulnerability and likely deliberate back door into the system. Additionally, OpenBSD leaks the state of the pseudorandom number generator to predictable locations on disk and in system memory at a fixed point during every start up and shutdown procedure. The lack of build process hardening has been on-going for over three years. Theo de Raadt is disinterested in improving or reviewing the design or providing any further clarification, as he has stated on the mailing list when shortfalls in the relinking process were reported over the past ~3 years. I hope that this can come to the attention of a third-party technical expert with standing in the computer security industry. Workaround: As the link kit is embedded in the base distribution and automatically relinked without an option to disable it in the provided installation script it requires manual removal at present. Cf. https://marc.info/?l=openbsd-bugs=159074964523007=2 (noted lack of idempotency) https://marc.info/?l=openbsd-bugs=168688579123005=2 (noted lack of integrity or provenance verification and the consumption of invalid objects) https://slsa.dev/spec/v1.0/levels#build-l2-hosted-build-platform: "Track/Level Requirements Focus Build L3 Hardened build platform Tampering during the build" ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/ - End forwarded message -
Re: newfs /usr/local
On June 19, 2023 8:57:34 PM GMT+02:00, "Pau A.S." wrote: >Hello, > >I would like to newfs /usr/local > >I have copied the contents to a different partition as root. > >My guess is that I would have to bring up the system in single user mode. > >My problem is that when I do that, /usr/local does not exist because it has >not been mounted. Well, that's kind of the point with going into single user mode. You wouldn't want the filesystem mounted while newfs'ing the underlying device. > I can however identify the UIID with fstab: > >afafa9bd7395733b.b none swap sw >afafa9bd7395733b.a / ffs rw 1 1 >afafa9bd7395733b.h /home ffs rw,nodev,nosuid 1 2 >afafa9bd7395733b.d /tmp ffs rw,nodev,nosuid 1 2 >afafa9bd7395733b.f /usr ffs rw,nodev 1 2 >afafa9bd7395733b.l /usr/X11R6 ffs rw,nodev 1 2 >afafa9bd7395733b.g /usr/local ffs rw,wxallowed,nodev 1 2 >afafa9bd7395733b.e /var ffs rw,nodev,nosuid 1 2 > >I can also see the name of the dev with df, > >Filesystem SizeUsed Avail Capacity Mounted on >/dev/sd1a 988M787M152M84%/ >/dev/sd1h 393G349G 24.9G94%/home >/dev/sd1d 989M 51.9M888M 6%/tmp >/dev/sd1f 3.9G1.3G2.4G36%/usr >/dev/sd1l 497M429M 43.2M91%/usr/X11R6 >/dev/sd1g 12.6G 10.7G1.3G90%/usr/local >/dev/sd1e 249M118M119M50%/var > >My question is: Do I run this upon rebooting as single user? > >$ newfs afafa9bd7395733b.g #, but yes. ;) > >and then reboot and, as root, > >$ cp -pR /path-to-backup-copy/* /usr/local > >? Assuming your paths are correct, that looks like it, yes. However since you probably want to copy in single user mode, you could just # newfs ... # fsck -p # mount -a # # reboot (or just exit to go multiuser) /Alexander > >Thanks
newfs /usr/local
Hello, I would like to newfs /usr/local I have copied the contents to a different partition as root. My guess is that I would have to bring up the system in single user mode. My problem is that when I do that, /usr/local does not exist because it has not been mounted. I can however identify the UIID with fstab: afafa9bd7395733b.b none swap sw afafa9bd7395733b.a / ffs rw 1 1 afafa9bd7395733b.h /home ffs rw,nodev,nosuid 1 2 afafa9bd7395733b.d /tmp ffs rw,nodev,nosuid 1 2 afafa9bd7395733b.f /usr ffs rw,nodev 1 2 afafa9bd7395733b.l /usr/X11R6 ffs rw,nodev 1 2 afafa9bd7395733b.g /usr/local ffs rw,wxallowed,nodev 1 2 afafa9bd7395733b.e /var ffs rw,nodev,nosuid 1 2 I can also see the name of the dev with df, Filesystem SizeUsed Avail Capacity Mounted on /dev/sd1a 988M787M152M84%/ /dev/sd1h 393G349G 24.9G94%/home /dev/sd1d 989M 51.9M888M 6%/tmp /dev/sd1f 3.9G1.3G2.4G36%/usr /dev/sd1l 497M429M 43.2M91%/usr/X11R6 /dev/sd1g 12.6G 10.7G1.3G90%/usr/local /dev/sd1e 249M118M119M50%/var My question is: Do I run this upon rebooting as single user? $ newfs afafa9bd7395733b.g and then reboot and, as root, $ cp -pR /path-to-backup-copy/* /usr/local ? Thanks
Wrong SHA256 sums for latest snapshot
Hi misc@, I have issues installing the latest snapshot from cdn.openbsd.org. $ sysupgrade -sn Fetching from https://cdn.openbsd.org/pub/OpenBSD/snapshots/amd64/ [Downloading SHA256.sig...] Signature Verified Verifying old sets. [Downloading sets...] Verifying sets. (SHA256) base73.tgz: FAILED (SHA256) bsd: FAILED (SHA256) bsd.mp: FAILED (SHA256) bsd.rd: FAILED (SHA256) comp73.tgz: FAILED (SHA256) game73.tgz: FAILED (SHA256) man73.tgz: FAILED (SHA256) xbase73.tgz: FAILED (SHA256) xfont73.tgz: FAILED (SHA256) xserv73.tgz: FAILED (SHA256) xshare73.tgz: FAILED $ cat /home/_sysupgrade/SHA256 [Omitted unused sums] SHA256 (INSTALL.amd64) = 2122f979265b296264e9db8f8dfe45d743e99ac545eca7fed6197c6feaa2 SHA256 (base73.tgz) = 1b548595d8f38d2d44f0cb1047e3d88c0bb7ef7c5ba03fdb38605be3228cdc23 SHA256 (bsd) = 260fc06d96ccb6863d1d560e2ea325661bcad97e9c68ee63f91a71ad99c1ce70 SHA256 (bsd.mp) = 8bfabfa56f9ac7284fbbc91f627ec70688afc1fb04687fcda0a600383d76f004 SHA256 (bsd.rd) = c3956bbdc7f00ace12f4d76802dbec842b22807a23246e09a170fe0372b1fe1e SHA256 (comp73.tgz) = fa0120f19fcf9e69467e8a0f3dbc9bd5087bee2cb3e5970ca3814bfd6c529004 SHA256 (game73.tgz) = faa4f878cc2881cc6ae861dd00ea7b1278f6c51c2c9760c36a24e803ef15d99b SHA256 (man73.tgz) = 4ef980ee22ad243c5ffb5dc61cffb6326abd61d33a2779e006b12460d67f20ca SHA256 (xbase73.tgz) = 1203bfa503b8d6bca475857e87cd375cb765fef15f84767faca4ead1d02f7c37 SHA256 (xfont73.tgz) = 08fda06cf5b2057d39d8bab807b4c66a0e70b49b84acc3534e4ba97924f88855 SHA256 (xserv73.tgz) = a6ae7ae16c4038cf3831acf6126491848f48ebdeb38b022a0ec78ec74d7aaf61 SHA256 (xshare73.tgz) = 8f59dddf19adec56b612d2c655638ce793d6979de4223a34d8b1bd5a94fb1903 $ sha256 /home/_sysupgrade/*.tgz SHA256 (base73.tgz) = 2cf3b11cc889575e6c9000edd355235d0c8e39935745058f4789a4d09bcf3a6b SHA256 (comp73.tgz) = 27616b664a505aae957013ce61a1d08ab32d07961d6dc22cbed4114df65c22a7 SHA256 (game73.tgz) = 464696e61eb54efab86aaa9499a24afe421e78b50e96e3744b853613ca65 SHA256 (man73.tgz) = dad1980b7a3f1dc520425d0471963d49f122329fd8f974f3fe169bb274c7cad3 SHA256 (xbase73.tgz) = a4ceaa9a8f783c54927519e2fac65711840595b8f5f98e5a46be0f6ff101b5f9 SHA256 (xfont73.tgz) = daf91ef0e41bc3ff5ba5b64f2b6ba046d68d3545c25290fb6cdac91e120539c6 SHA256 (xserv73.tgz) = 6e5856f6c602902458a64bbfa9dca3deeb86af5486203daff63581cc3eb642ac SHA256 (xshare73.tgz) = 78b668863779a8ebc1189401ef354bb1511a9bf81f3b13c8dd63bc72114f31b5 Best regards, Benjamin Stürz
Re: increasing NET_TASKQ for better performance?
Valdrin MUJA [valdrin_m...@outlook.com] wrote: > Hello Misc, > > I run OpenBSD 7.3 as L3 firewall under VMware. I have some rdr-to rules. > > Here System information: > cpu15: Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz, 1995.63 MHz, 06-6a-06 > I know CPU cores are not at too important at the moment but this server has > 16 cores on it. > I use vmx nics. dmesg is attached. > > When traffic becomes high(*) systems slows. (Users say RDP connections are > slow) > When I checked uptime load average was ok but yeah OpenBSD was slow. > For example, when I enter ifconfig command system was not too fast. > > After that I looked at top -SH output and see 3 of softnet tasks were over > %74 and was ~%40. > > Would you suggest to increase the NET_TASKQ value to 8 or 16 (number of cores > in the system) and use a custom kernel? Probably 8 since the kernel isn't optimized for hyper-threading. > Also, just wonder if it's CPU core dedicated value or not? > > P.S. I don't use pfsync and it's not in my plan... > There's a possible MP rework hitting the tree soon if you did want to use pfsync.
Re: Possible typo in pf NAT FAQ
Am 18.06.2023 20:35 schrieb Stephan Neuhaus: Here you can see that the "from" part is what the above description calls the src_addr, not the ext_addr, as it claims. This makes much more sense and is consistent with all the other documentation that I've seen. The "match" is rewriting to ext_addr from src_addr the moment it... matches. Thus the f'up pass rule is working on ext_addr. HTH, -- pb
Re: load custom acpi table
On Mon, Jun 19, 2023 at 08:55:10AM +0300, S V wrote: > Hello, list! > > Is it possible to load custom acpi table on boot ? > > in FreeBSD it was possible by strings in conf like > > acpi_dsdt_load="YES" acpi_dsdt_name="filename.aml" no
