Re: (fwd) [FD] OpenBSD kernel relinking is not transactional and a local exploit exists
On Mon, Jun 19, 2023 at 05:34:12PM -0600, Theo de Raadt wrote: > That writeup is bullshit. Ok, I see. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_r...@bigfoot.com **
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 -
