| Message ID | 1710313714-12541-36-git-send-email-wangmy@fujitsu.com |
|---|---|
| State | New |
| Headers | show |
| Series | [01/36] debianutils: upgrade 5.16 -> 5.17 | expand |
On Wed, 2024-03-13 at 15:08 +0800, wangmy via lists.openembedded.org wrote: > From: Wang Mingyu <wangmy@fujitsu.com> > > License-Update: > ================ > *COPYING: > Add the license for the XZ logo. > Change most public domain parts to 0BSD. > Update COPYING about the man pages of the scripts. > *getopt.c > MSVC: Don't #include <unistd.h>. > lib/getopt*.c: Include <config.h> only HAVE_CONFIG_H is defined. > lib: Update getopt.c from Gnulib with modifications. > lib: Silence -Wsign-conversion in getopt.c. > Add SPDX license identifiers to GPL, LGPL, and FSFULLR files. > > Changelog: > ============= > * liblzma: Fixed two bugs relating to GNU indirect function (IFUNC) > with GCC. > * xz: Changed the messages for thread reduction due to memory > constraints to only appear under the highest verbosity level. > * Build: > - Fixed a build issue when the header file <linux/landlock.h> > was present on the system but the Landlock system calls were > not defined in <sys/syscall.h>. > - The CMake build now warns and disables NLS if both gettext > tools and pre-created .gmo files are missing. Previously, > this caused the CMake build to fail. > * Minor improvements to man pages. > * Minor improvements to tests. https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/8737 Cheers, Richard
I know this request is a week or so old.. But do NOT upgrade to 'xz' 5.6.0 or 5.6.1. It has been compromised: https://www.openwall.com/lists/oss-security/2024/03/29/4 --Mark On 3/14/24 8:40 AM, Richard Purdie wrote: > On Wed, 2024-03-13 at 15:08 +0800, wangmy via lists.openembedded.org > wrote: >> From: Wang Mingyu <wangmy@fujitsu.com> >> >> License-Update: >> ================ >> *COPYING: >> Add the license for the XZ logo. >> Change most public domain parts to 0BSD. >> Update COPYING about the man pages of the scripts. >> *getopt.c >> MSVC: Don't #include <unistd.h>. >> lib/getopt*.c: Include <config.h> only HAVE_CONFIG_H is defined. >> lib: Update getopt.c from Gnulib with modifications. >> lib: Silence -Wsign-conversion in getopt.c. >> Add SPDX license identifiers to GPL, LGPL, and FSFULLR files. >> >> Changelog: >> ============= >> * liblzma: Fixed two bugs relating to GNU indirect function (IFUNC) >> with GCC. >> * xz: Changed the messages for thread reduction due to memory >> constraints to only appear under the highest verbosity level. >> * Build: >> - Fixed a build issue when the header file <linux/landlock.h> >> was present on the system but the Landlock system calls were >> not defined in <sys/syscall.h>. >> - The CMake build now warns and disables NLS if both gettext >> tools and pre-created .gmo files are missing. Previously, >> this caused the CMake build to fail. >> * Minor improvements to man pages. >> * Minor improvements to tests. > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/8737 > > Cheers, > > Richard > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#197107): https://lists.openembedded.org/g/openembedded-core/message/197107 > Mute This Topic: https://lists.openembedded.org/mt/104900983/3616948 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [mark.hatle@kernel.crashing.org] > -=-=-=-=-=-=-=-=-=-=-=- >
Absolutely confirm. DO NOT UPDATE Marta On Sat, 30 Mar 2024, 02:04 Mark Hatle, <mark.hatle@kernel.crashing.org> wrote: > I know this request is a week or so old.. > > But do NOT upgrade to 'xz' 5.6.0 or 5.6.1. It has been compromised: > > https://www.openwall.com/lists/oss-security/2024/03/29/4 > > --Mark > > On 3/14/24 8:40 AM, Richard Purdie wrote: > > On Wed, 2024-03-13 at 15:08 +0800, wangmy via lists.openembedded.org > > wrote: > >> From: Wang Mingyu <wangmy@fujitsu.com> > >> > >> License-Update: > >> ================ > >> *COPYING: > >> Add the license for the XZ logo. > >> Change most public domain parts to 0BSD. > >> Update COPYING about the man pages of the scripts. > >> *getopt.c > >> MSVC: Don't #include <unistd.h>. > >> lib/getopt*.c: Include <config.h> only HAVE_CONFIG_H is defined. > >> lib: Update getopt.c from Gnulib with modifications. > >> lib: Silence -Wsign-conversion in getopt.c. > >> Add SPDX license identifiers to GPL, LGPL, and FSFULLR files. > >> > >> Changelog: > >> ============= > >> * liblzma: Fixed two bugs relating to GNU indirect function (IFUNC) > >> with GCC. > >> * xz: Changed the messages for thread reduction due to memory > >> constraints to only appear under the highest verbosity level. > >> * Build: > >> - Fixed a build issue when the header file <linux/landlock.h> > >> was present on the system but the Landlock system calls were > >> not defined in <sys/syscall.h>. > >> - The CMake build now warns and disables NLS if both gettext > >> tools and pre-created .gmo files are missing. Previously, > >> this caused the CMake build to fail. > >> * Minor improvements to man pages. > >> * Minor improvements to tests. > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/8737 > > > > Cheers, > > > > Richard > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#197643): > https://lists.openembedded.org/g/openembedded-core/message/197643 > Mute This Topic: https://lists.openembedded.org/mt/105226831/5827677 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > rybczynska@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
On Sat, 2024-03-30 at 13:08 +0100, Marta Rybczynska wrote: > Absolutely confirm. DO NOT UPDATE > > Marta > > On Sat, 30 Mar 2024, 02:04 Mark Hatle, > <mark.hatle@kernel.crashing.org> wrote: > > I know this request is a week or so old.. > > > > But do NOT upgrade to 'xz' 5.6.0 or 5.6.1. It has been > > compromised: > > > > https://www.openwall.com/lists/oss-security/2024/03/29/4 > > > > --Mark We're not going to. The upgrade was already dropped after it failed build testing. I do wonder why it failed. https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/8737 I've ensured the sources were removed from our mirrors too. Cheers, Richard
I’m slightly worried. Does this compromise build systems (given that back door was injected into autoconf scripts) or only systems where xz binaries are installed? Ale On Sat 30. Mar 2024 at 13.26, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > On Sat, 2024-03-30 at 13:08 +0100, Marta Rybczynska wrote: > > Absolutely confirm. DO NOT UPDATE > > > > Marta > > > > On Sat, 30 Mar 2024, 02:04 Mark Hatle, > > <mark.hatle@kernel.crashing.org> wrote: > > > I know this request is a week or so old.. > > > > > > But do NOT upgrade to 'xz' 5.6.0 or 5.6.1. It has been > > > compromised: > > > > > > https://www.openwall.com/lists/oss-security/2024/03/29/4 > > > > > > --Mark > > We're not going to. The upgrade was already dropped after it failed > build testing. I do wonder why it failed. > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/8737 > > I've ensured the sources were removed from our mirrors too. > > Cheers, > > Richard > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#197649): > https://lists.openembedded.org/g/openembedded-core/message/197649 > Mute This Topic: https://lists.openembedded.org/mt/105226831/1686489 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [ > alex.kanavin@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- > >
From what is publicly known it injected malicious code (through m4 macro using payload hidden in obfuscated compressed test file) into built liblzma.so.5 which then hijacks RSA_public_decrypt call e.g. in sshd (when sshd is built with patch adding systemd notifications which brings liblzma dependency to sshd e.g. on debian and ubuntu based systems). The build systems which just built this xz version shouldn't be affected (as it won't be using the liblzma.so from the OE build on the host). This publicly known part should be OK for OE, but it's right to be worried about the other things which aren't known (not only from these guys or from xz project). Regards, On Sat, Mar 30, 2024 at 1:52 PM Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > I’m slightly worried. Does this compromise build systems (given that back door was injected into autoconf scripts) or only systems where xz binaries are installed? > > Ale > > On Sat 30. Mar 2024 at 13.26, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: >> >> On Sat, 2024-03-30 at 13:08 +0100, Marta Rybczynska wrote: >> > Absolutely confirm. DO NOT UPDATE >> > >> > Marta >> > >> > On Sat, 30 Mar 2024, 02:04 Mark Hatle, >> > <mark.hatle@kernel.crashing.org> wrote: >> > > I know this request is a week or so old.. >> > > >> > > But do NOT upgrade to 'xz' 5.6.0 or 5.6.1. It has been >> > > compromised: >> > > >> > > https://www.openwall.com/lists/oss-security/2024/03/29/4 >> > > >> > > --Mark >> >> We're not going to. The upgrade was already dropped after it failed >> build testing. I do wonder why it failed. >> >> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/8737 >> >> I've ensured the sources were removed from our mirrors too. >> >> Cheers, >> >> Richard >> >> >> > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#197650): https://lists.openembedded.org/g/openembedded-core/message/197650 > Mute This Topic: https://lists.openembedded.org/mt/105226831/3617156 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [martin.jansa@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Sat, 2024-03-30 at 14:06 +0100, Martin Jansa wrote: > From what is publicly known it injected malicious code (through m4 > macro using payload hidden in obfuscated compressed test file) into > built liblzma.so.5 which then hijacks RSA_public_decrypt call e.g. in > sshd (when sshd is built with patch adding systemd notifications > which brings liblzma dependency to sshd e.g. on debian and ubuntu > based systems). > > The build systems which just built this xz version shouldn't be > affected (as it won't be using the liblzma.so from the OE build on > the host). > > This publicly known part should be OK for OE, but it's right to be > worried about the other things which aren't known (not only from > these guys or from xz project). I concur. It is worrying but I've kind of been expecting something like this for a while unfortunately. We need to watch what is going on and act accordingly if/as anything else becomes known. Cheers, Richard
On Sat, 30 Mar 2024 at 17:18, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Sat, 2024-03-30 at 14:06 +0100, Martin Jansa wrote: > > From what is publicly known it injected malicious code (through m4 > > macro using payload hidden in obfuscated compressed test file) into > > built liblzma.so.5 which then hijacks RSA_public_decrypt call e.g. in > > sshd (when sshd is built with patch adding systemd notifications > > which brings liblzma dependency to sshd e.g. on debian and ubuntu > > based systems). > > > > The build systems which just built this xz version shouldn't be > > affected (as it won't be using the liblzma.so from the OE build on > > the host). > > > > This publicly known part should be OK for OE, but it's right to be > > worried about the other things which aren't known (not only from > > these guys or from xz project). > > I concur. > > It is worrying but I've kind of been expecting something like this for > a while unfortunately. > > We need to watch what is going on and act accordingly if/as anything > else becomes known. https://nvd.nist.gov/vuln/detail/CVE-2024-3094 Distros have downgraded to older releases, still trying to figure out which version to use. > Cheers, > > Richard
On Mon, Apr 01, 2024 at 11:42:51AM +0200, Fathi Boudra wrote: > On Sat, 30 Mar 2024 at 17:18, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > > > On Sat, 2024-03-30 at 14:06 +0100, Martin Jansa wrote: > > > From what is publicly known it injected malicious code (through m4 > > > macro using payload hidden in obfuscated compressed test file) into > > > built liblzma.so.5 which then hijacks RSA_public_decrypt call e.g. in > > > sshd (when sshd is built with patch adding systemd notifications > > > which brings liblzma dependency to sshd e.g. on debian and ubuntu > > > based systems). > > > > > > The build systems which just built this xz version shouldn't be > > > affected (as it won't be using the liblzma.so from the OE build on > > > the host). > > > > > > This publicly known part should be OK for OE, but it's right to be > > > worried about the other things which aren't known (not only from > > > these guys or from xz project). > > > > I concur. > > > > It is worrying but I've kind of been expecting something like this for > > a while unfortunately. > > > > We need to watch what is going on and act accordingly if/as anything > > else becomes known. > > https://nvd.nist.gov/vuln/detail/CVE-2024-3094 > > Distros have downgraded to older releases, still trying to figure out > which version to use. While 5.4.6 version we've upgraded to in February was not yet compromised, it was already being taken over by Jia Tan, moving releases to controlled subdomain of xz.tukaani.org hosted off of GitHub directly, preparing for the malicious release of 5.6.0 and 5.6.1. So, we've pointed to GitHub location accordingly: https://git.openembedded.org/openembedded-core/commit/?id=9cc6c809c154019afe3bf6e6d617eab640faa4d0 https://git.openembedded.org/openembedded-core/commit/?id=5be69fc3ff6296411c736e5c7c9522d99c0be2c6 But GitHub has suspended the project and associated developer accounts. The original maintainer has posted some details on this matter here: https://tukaani.org/xz-backdoor/ Again, 5.4.6 tarball wasn't compromised, but it is no longer accessible from GitHub - should we revert back to 5.4.5 that was hosted on the original site? Though it should be mirrored...
On Mon, Apr 1, 2024 at 9:02 PM Denys Dmytriyenko <denis@denix.org> wrote: > > On Mon, Apr 01, 2024 at 11:42:51AM +0200, Fathi Boudra wrote: > > On Sat, 30 Mar 2024 at 17:18, Richard Purdie > > <richard.purdie@linuxfoundation.org> wrote: > > > > > > On Sat, 2024-03-30 at 14:06 +0100, Martin Jansa wrote: > > > > From what is publicly known it injected malicious code (through m4 > > > > macro using payload hidden in obfuscated compressed test file) into > > > > built liblzma.so.5 which then hijacks RSA_public_decrypt call e.g. in > > > > sshd (when sshd is built with patch adding systemd notifications > > > > which brings liblzma dependency to sshd e.g. on debian and ubuntu > > > > based systems). > > > > > > > > The build systems which just built this xz version shouldn't be > > > > affected (as it won't be using the liblzma.so from the OE build on > > > > the host). > > > > > > > > This publicly known part should be OK for OE, but it's right to be > > > > worried about the other things which aren't known (not only from > > > > these guys or from xz project). > > > > > > I concur. > > > > > > It is worrying but I've kind of been expecting something like this for > > > a while unfortunately. > > > > > > We need to watch what is going on and act accordingly if/as anything > > > else becomes known. > > > > https://nvd.nist.gov/vuln/detail/CVE-2024-3094 > > > > Distros have downgraded to older releases, still trying to figure out > > which version to use. > > While 5.4.6 version we've upgraded to in February was not yet compromised, > it was already being taken over by Jia Tan, moving releases to controlled > subdomain of xz.tukaani.org hosted off of GitHub directly, preparing for the > malicious release of 5.6.0 and 5.6.1. So, we've pointed to GitHub location > accordingly: > > https://git.openembedded.org/openembedded-core/commit/?id=9cc6c809c154019afe3bf6e6d617eab640faa4d0 > https://git.openembedded.org/openembedded-core/commit/?id=5be69fc3ff6296411c736e5c7c9522d99c0be2c6 > > But GitHub has suspended the project and associated developer accounts. The > original maintainer has posted some details on this matter here: > > https://tukaani.org/xz-backdoor/ > > Again, 5.4.6 tarball wasn't compromised, but it is no longer accessible from > GitHub - should we revert back to 5.4.5 that was hosted on the original site? > Though it should be mirrored... > The repository is disabled by GitHub, and the recipe does not work from this end. We need to switch to the older mirror and to the last version that was present. There are other parts of the attack coming out each day, so we should know to which version we need to revert quite soon. Regards, Marta
On Sat, Mar 30, 2024 at 1:26 PM Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > > On Sat, 2024-03-30 at 13:08 +0100, Marta Rybczynska wrote: > > Absolutely confirm. DO NOT UPDATE > > > > Marta > > > > On Sat, 30 Mar 2024, 02:04 Mark Hatle, > > <mark.hatle@kernel.crashing.org> wrote: > > > I know this request is a week or so old.. > > > > > > But do NOT upgrade to 'xz' 5.6.0 or 5.6.1. It has been > > > compromised: > > > > > > https://www.openwall.com/lists/oss-security/2024/03/29/4 > > > > > > --Mark > > We're not going to. The upgrade was already dropped after it failed > build testing. I do wonder why it failed. > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/8737 > > I've ensured the sources were removed from our mirrors too. It looks to me that the Autobuilder has actually seen a side-effect of the backdoor... Marta
diff --git a/meta/recipes-extended/xz/xz_5.4.6.bb b/meta/recipes-extended/xz/xz_5.6.1.bb similarity index 79% rename from meta/recipes-extended/xz/xz_5.4.6.bb rename to meta/recipes-extended/xz/xz_5.6.1.bb index da3b75a10b..dd6388e7dd 100644 --- a/meta/recipes-extended/xz/xz_5.4.6.bb +++ b/meta/recipes-extended/xz/xz_5.6.1.bb @@ -8,26 +8,27 @@ SECTION = "base" # packages, and the LGPL bits are under lib/, which appears to be used for # libgnu, which appears to be used for DOS builds. So we're left with # GPL-2.0-or-later and PD. -LICENSE = "GPL-2.0-or-later & GPL-3.0-with-autoconf-exception & LGPL-2.1-or-later & PD" -LICENSE:${PN} = "GPL-2.0-or-later" -LICENSE:${PN}-dev = "GPL-2.0-or-later" -LICENSE:${PN}-staticdev = "GPL-2.0-or-later" -LICENSE:${PN}-doc = "GPL-2.0-or-later" -LICENSE:${PN}-dbg = "GPL-2.0-or-later" -LICENSE:${PN}-locale = "GPL-2.0-or-later" +LICENSE = "GPL-2.0-or-later & GPL-3.0-with-autoconf-exception & LGPL-2.1-or-later & PD & 0BSD" +LICENSE:${PN} = "GPL-2.0-or-later & 0BSD" +LICENSE:${PN}-dev = "GPL-2.0-or-later & 0BSD" +LICENSE:${PN}-staticdev = "GPL-2.0-or-later & 0BSD" +LICENSE:${PN}-doc = "GPL-2.0-or-later & 0BSD" +LICENSE:${PN}-dbg = "GPL-2.0-or-later & 0BSD" +LICENSE:${PN}-locale = "GPL-2.0-or-later & 0BSD" LICENSE:liblzma = "PD" -LIC_FILES_CHKSUM = "file://COPYING;md5=d4378ea9d5d1fc9ab0ae10d7948827d9 \ +LIC_FILES_CHKSUM = "file://COPYING;md5=3ef4de063517b8d33e97bbb87a3339ee \ file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ file://COPYING.GPLv3;md5=1ebbd3e34237af26da5dc08a4e440464 \ file://COPYING.LGPLv2.1;md5=4fbd65380cdd255951079008b364516c \ - file://lib/getopt.c;endline=23;md5=2069b0ee710572c03bb3114e4532cd84 \ + file://lib/getopt.c;endline=23;md5=3f33e207287bf72834f3ae8c247dfb6a \ + file://COPYING.0BSD;md5=0672c210ce80c83444339b9aa31fee2f \ " SRC_URI = "https://github.com/tukaani-project/xz/releases/download/v${PV}/xz-${PV}.tar.gz \ file://run-ptest \ " -SRC_URI[sha256sum] = "aeba3e03bf8140ddedf62a0a367158340520f6b384f75ca6045ccc6c0d43fd5c" +SRC_URI[sha256sum] = "2398f4a8e53345325f44bdd9f0cc7401bd9025d736c6d43b372f4dea77bf75b8" UPSTREAM_CHECK_REGEX = "releases/tag/v(?P<pver>\d+(\.\d+)+)" UPSTREAM_CHECK_URI = "https://github.com/tukaani-project/xz/releases/"