Bug#1068024: revert to version that does not contain changes by bad actor
Christoph Anton Mitterer dixit: >So Thorsten, in case you or someone else is aware of any [intermediate] >results from these task forces ([9[) it would be nice to hear about >them or better even in form of some "official" statement from Debian. JFTR I’m not involved in those myself. bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#1068024: revert to version that does not contain changes by bad actor
Hey. On Sun, 2024-03-31 at 01:46 +, Thorsten Glaser wrote: > Yes, a multi-team task force is working on it and will inform users > once it is known how to proceed, inclusing how much to throw away > and rebuild. Kindly wanted to ask whether anything has come out meanwhile of that? I've tried to follow quite extensively what the various reverse engineering efforts (e.g. [0], [1], [2], [3]) found out or what's revealed on index pages like [4] or [5]. It feels as if there are still many discussions about how to prevent such things in the future, but less so about the concrete fallout of the particular backdoor, where it seems most people were lead to conclude from media reports, that an attack was only possible if sshd was actually running an reachable. This may of course be true, which would mean that most people are actually safe and we had quite some luck this time: - servers, because they run stable distros that haven't had the backdoor - workstations/laptops, because they typically don't run a publicly listending sshd But there are still new findings about the backdoor every now and then, like that it may read/write on IPC sockets (contained in [2]) and I've read similar[6] without the restriction on IPC. Also I've seen some vague statements[7] that it might "install" public keys (didn't really grasp what was meant there - something like "in authorized_keys"). And one report[8] talked about it collecting usernames and IPs and passing the on to some function with unknown purpose. It also seems like these effort focus mostly on the 5.6.1 version and while it's said that the 5.6.0 version is quite similar, who knows the exact details!? In any case and (too) long story short: It would be nice to know whether there's still work done about finding out whether people who had the malicious code on their systems (in any version of the backdoor), but - had sshd not running at all and/or - it was not reachable from the internet can feel safe. Or whether it may be possible that: - the backdoor did call home (loaded commands from there, leaked private keys or so from the system) - used completely different vectors not involving sshd - or somehow else infested the system Right now people might still have backups to torch their possibly compromised systems and start over from a safe sate. So Thorsten, in case you or someone else is aware of any [intermediate] results from these task forces ([9[) it would be nice to hear about them or better even in form of some "official" statement from Debian. Thanks, Chris. [0] https://discord.gg/u6MzmQm5 [1] https://github.com/smx-smx/xzre [2] https://github.com/binarly-io/binary-risk-intelligence/tree/master/xz-backdoor [3] https://securelist.com/xz-backdoor-story-part-1/112354/ [4] https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 [5] https://github.com/przemoc/xz-backdoor-links https://przemoc.github.io/xz-backdoor-links/ (rendering of that) [6] https://discord.com/channels/1223666474091020432/1223666474972090430/1230974749522530304 [7] https://discord.com/channels/1223666474091020432/1223666474972090430/1230173131746840606 [8] https://isc.sans.edu/diary/30802 [9] E.g. on d-d https://lists.debian.org/debian-devel/2024/03/msg00338.html Moritz Mühlenhoff has mentioned that some company was working on it and results were expected in some time.
Bug#1068024: revert to version that does not contain changes by bad actor
On Fri, 29 Mar 2024 22:32:23 +0100 Aurelien Jarno wrote: > On 2024-03-29 16:25, Joey Hess wrote: > > I'd suggest reverting to 5.3.1. Bearing in mind that there were security > > fixes after that point for ZDI-CAN-16587 that would need to be reapplied. > > Note that reverted to such an old version will break packages that use > new symbols introduced since then. From a quick look, this is at least: > - dpkg > - erofs-utils > - kmod > > Having dpkg in that list means that such downgrade has to be planned > carefully. > > Regards > Aurelien > > -- > Aurelien Jarno GPG: 4096R/1DDD8C9B > aurel...@aurel32.net http://aurel32.net mobile
Bug#1068024: revert to version that does not contain changes by bad actor
On 2024-04-02 14:34:20 [+0200], Guillem Jover wrote: > (Please do not take this mail as endorsing any specific action, just > wanted to clarify/correct the above.) Right, same here. The 5.4.x series has threaded decompression which I would like to keep. The 5.6.x series has branchless decompressor which improves decompressing performance. The 5.3.x series is alpha and should not be used in production but only for testing. I'm not sure what happens with the XZ_5.3..alpha symbols, I hope they get ignored. I'm going to poke upstream if there is an audit and or future plans. But I want to stay on an official upstream release which is also used by other distros. > Thanks, > Guillem Sebastian
Bug#1068024: revert to version that does not contain changes by bad actor
Joey Hess dixit: >--- orig/dpkg-1.22.6/debian/control2024-03-02 21:30:15.0 -0400 >+++ dpkg-1.22.6/debian/control 2024-03-30 13:14:37.746223895 -0400 > # Version needed for multi-threaded decompressor support. >- liblzma-dev (>= 5.4.0), >+ liblzmaunscathed-dev, The comment probably needs adjusting as well. > # Version needed for multi-threaded decompressor support. >- xz-utils (>= 5.4.0) , >+ xz-utils , dito > # Version needed for multi-threaded decompressor support. >- liblzma-dev (>= 5.4.0), >+ liblzmaunscathed-dev, idem > # Version needed for multi-threaded decompressor support. >- xz-utils (>= 5.4.0), >+ xz-utils, el mismo > # Version needed for multi-threaded decompressor support. >- xz-utils (>= 5.4.0), >+ xz-utils, the same >--- orig/dpkg-1.22.6/debian/libdpkg-dev.install2024-02-04 >22:31:16.0 -0400 >+++ dpkg-1.22.6/debian/libdpkg-dev.install 2024-03-30 13:25:27.043840706 >-0400 >@@ -1,4 +1,5 @@ > usr/include/dpkg/*.h >-usr/lib/*/pkgconfig/libdpkg.pc >-usr/lib/*/libdpkg.a >+usr/lib/pkgconfig/libdpkg.pc >+usr/lib/libdpkg.a Why, exactly, does the library move out of the M-A directory here? (Probably a question for guillem though.) >+usr/lib/libdpkg.la IIRC we were not shipping libtool files, were we? Or am I confusing this with some BSD ports/packages now? bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs
Bug#1068024: revert to version that does not contain changes by bad actor
Guillem Jover wrote:
> dpkg should be able to use an old liblzma w/o multi-threaded compressor
> or decompressor support
Ah you're right. configure did find the library, but I'd missed updating
some ifdefs. Attached updated dpkg patch which does build with the
shared library and works.
--
see shy jo
diff -ur orig/dpkg-1.22.6/Makefile.in dpkg-1.22.6/Makefile.in
--- orig/dpkg-1.22.6/Makefile.in 2024-03-10 15:21:24.0 -0400
+++ dpkg-1.22.6/Makefile.in 2024-04-03 02:46:40.893211227 -0400
@@ -344,7 +344,7 @@
LTLIBINTL = @LTLIBINTL@
LTLIBOBJS = @LTLIBOBJS@
LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@
-LZMA_LIBS = @LZMA_LIBS@
+LZMAUNSCATHED_LIBS = @LZMAUNSCATHED_LIBS@
MAKEINFO = @MAKEINFO@
MANIFEST_TOOL = @MANIFEST_TOOL@
MD_LIBS = @MD_LIBS@
diff -ur orig/dpkg-1.22.6/config.h.in dpkg-1.22.6/config.h.in
--- orig/dpkg-1.22.6/config.h.in 2024-03-10 15:21:24.0 -0400
+++ dpkg-1.22.6/config.h.in 2024-04-03 02:46:40.585213979 -0400
@@ -511,8 +511,8 @@
/* Define to 1 to use bz2 library rather than console tool */
#undef WITH_LIBBZ2
-/* Define to 1 to use lzma library rather than console tool */
-#undef WITH_LIBLZMA
+/* Define to 1 to use lzmaunscathed library rather than console tool */
+#undef WITH_LIBLZMAUNSCATHED
/* Define to 1 to compile in SELinux support */
#undef WITH_LIBSELINUX
diff -ur orig/dpkg-1.22.6/configure.ac dpkg-1.22.6/configure.ac
--- orig/dpkg-1.22.6/configure.ac 2024-03-02 21:30:15.0 -0400
+++ dpkg-1.22.6/configure.ac 2024-03-30 13:15:26.981883607 -0400
@@ -113,7 +113,7 @@
DPKG_LIB_MD
DPKG_LIB_Z
DPKG_LIB_BZ2
-DPKG_LIB_LZMA
+DPKG_LIB_LZMAUNSCATHED
DPKG_LIB_ZSTD
DPKG_LIB_SELINUX
AS_IF([test "x$build_dselect" = "xyes"], [
@@ -336,7 +336,7 @@
libselinux . . . . . . . . . : $have_libselinux
libmd . . . . . . . . . . . . : $have_libmd
libz . . . . . . . . . . . . : $have_libz_impl
-liblzma . . . . . . . . . . . : $have_liblzma
+liblzmaunscathed . . . . . . .: $have_liblzmaunscathed
libzstd . . . . . . . . . . . : $have_libzstd
libbz2 . . . . . . . . . . . : $have_libbz2
libcurses . . . . . . . . . . : ${have_libcurses:-no}
diff -ur orig/dpkg-1.22.6/debian/control dpkg-1.22.6/debian/control
--- orig/dpkg-1.22.6/debian/control 2024-03-02 21:30:15.0 -0400
+++ dpkg-1.22.6/debian/control 2024-03-30 13:14:37.746223895 -0400
@@ -20,7 +20,7 @@
zlib1g-dev,
libbz2-dev,
# Version needed for multi-threaded decompressor support.
- liblzma-dev (>= 5.4.0),
+ liblzmaunscathed-dev,
# Version needed for the new streaming API.
libzstd-dev (>= 1.4.0),
libselinux1-dev [linux-any],
@@ -28,7 +28,7 @@
# Needed for the functional test.
bzip2 ,
# Version needed for multi-threaded decompressor support.
- xz-utils (>= 5.4.0) ,
+ xz-utils ,
# Needed for the functional test.
zstd ,
# Needed for the author release process.
@@ -89,7 +89,7 @@
libmd-dev,
zlib1g-dev,
# Version needed for multi-threaded decompressor support.
- liblzma-dev (>= 5.4.0),
+ liblzmaunscathed-dev,
# Version needed for the new streaming API.
libzstd-dev (>= 1.4.0),
libbz2-dev,
@@ -113,7 +113,7 @@
tar (>= 1.28-1),
bzip2,
# Version needed for multi-threaded decompressor support.
- xz-utils (>= 5.4.0),
+ xz-utils,
# Version needed for git-style diff support.
patch (>= 2.7),
make,
@@ -165,7 +165,7 @@
liblocale-gettext-perl,
bzip2,
# Version needed for multi-threaded decompressor support.
- xz-utils (>= 5.4.0),
+ xz-utils,
Suggests:
debian-keyring,
gnupg | sq | sqop | pgpainless-cli | sequoia-chameleon-gnupg,
diff -ur orig/dpkg-1.22.6/debian/libdpkg-dev.install dpkg-1.22.6/debian/libdpkg-dev.install
--- orig/dpkg-1.22.6/debian/libdpkg-dev.install 2024-02-04 22:31:16.0 -0400
+++ dpkg-1.22.6/debian/libdpkg-dev.install 2024-03-30 13:25:27.043840706 -0400
@@ -1,4 +1,5 @@
usr/include/dpkg/*.h
-usr/lib/*/pkgconfig/libdpkg.pc
-usr/lib/*/libdpkg.a
+usr/lib/pkgconfig/libdpkg.pc
+usr/lib/libdpkg.a
usr/share/aclocal/dpkg-*.m4
+usr/lib/libdpkg.la
diff -ur orig/dpkg-1.22.6/debian/rules dpkg-1.22.6/debian/rules
--- orig/dpkg-1.22.6/debian/rules 2024-03-02 21:30:15.0 -0400
+++ dpkg-1.22.6/debian/rules 2024-03-30 13:22:38.316130018 -0400
@@ -67,7 +67,8 @@
$(D)/usr/share/lintian/profiles/dpkg/main.profile
override_dh_auto_test:
- dh_auto_test -- $(testflags)
+ echo tests disabled for now
+ #dh_auto_test -- $(testflags)
override_dh_installsystemd:
dh_installsystemd -a --name=dpkg-db-backup \
diff -ur orig/dpkg-1.22.6/dselect/Makefile.in dpkg-1.22.6/dselect/Makefile.in
--- orig/dpkg-1.22.6/dselect/Makefile.in 2024-03-10 15:21:24.0 -0400
+++ dpkg-1.22.6/dselect/Makefile.in 2024-04-03 02:46:40.917211013 -0400
@@ -366,7 +366,7 @@
LTLIBINTL = @LTLIBINTL@
LTLIBOBJS = @LTLIBOBJS@
LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@
-LZMA_LIBS = @LZMA_LIBS@
+LZMAUNSCATHED_LIBS = @LZMAUNSCATHED_LIBS@
MAKEINFO = @MAKEINFO@
MANIFEST_TOOL = @MANIFEST_TOOL@
MD_LIBS = @MD_LIBS@
diff -ur
Bug#1068024: revert to version that does not contain changes by bad actor
Hi! On Sat, 2024-03-30 at 14:16:52 -0400, Joey Hess wrote: > My git repository is here (note all my commits are gpg signed): > https://git.joeyh.name/index.cgi/xz-unscathed/ > My build of dpkg ended up not being linked to a lzma library at all, > because liblzmaunscathed is too old to support concurrent decompression, > which the configure script detects. So dpkg-deb instead uses xz-utils > to decompress debs. I replaced xz-utils.deb with the one built from my > fork, and dpkg seems to work fine using it. dpkg should be able to use an old liblzma w/o multi-threaded compressor or decompressor support (both are intended to be optionally used if available). I think the problem might be that you seem to have missed renaming the .pc.in file, and that does not get included in the -dev package perhaps, or not picked up then by dpkg with your attached patch to it? I only checked the renaming commit, didn't check the packaging nor tried to build it. (Please do not take this mail as endorsing any specific action, just wanted to clarify/correct the above.) Thanks, Guillem
Bug#1068024: revert to version that does not contain changes by bad actor
> The situation is being analysed by a cross-team taskforce, > please let them do the already-stressing job ☻ Sorry, didn't see that before sending my previous message. I'll leave it to you guys. -- see shy jo signature.asc Description: PGP signature
Bug#1068024: revert to version that does not contain changes by bad actor
Since there's been some discussion about versions, the version in my xz-unscathed git repository is the same as xz 5.3.2alpha, with the addition of a fix for CVE-2022-1271 that did not make it into that version. (It was fixed in 5.2.6, but 5.3.2alpha was diverged from 5.2.5. Jia Tan was involved in 5.2.6.) 5.2.5 might be a more stable version to revert to; it also predates Jia Tan's involvement. The CVE-2022-1271 fix would need to be included. Note that erofs-utils apparently had a reason to need the 5.3.2alpha release, so reverting to 5.2.5 would probably cause difficulty with that package. That dependency versioning information is not included in the debian sources for erofs-utils BTW. I have not checked compatability with other packages except for dpkg. -- see shy jo signature.asc Description: PGP signature
Bug#1068024: revert to version that does not contain changes by bad actor
Christoph Anton Mitterer dixit: >Is anyone on the Debian side trying to figure out how far we've been >practically affected? Yes, a multi-team task force is working on it and will inform users once it is known how to proceed, inclusing how much to throw away and rebuild. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Bug#1068024: revert to version that does not contain changes by bad actor
Pierre Ynard dixit: >version into the Debian archive, as seen in #1067708. To quote Thorsten >from that thread: > >> Very much *not* a fan of NMUs doing large changes such as >> new upstream versions. > >I can't say why exactly he would not be a fan, but with hindsight that >was an interesting call. It turned out to indeed be related, although I cannot blame Sebastian for not spotting it, as well as it was hidden. I actually wrote about that earlier on Fedi: (Markdown formatting lost here though) | I was considering replying to this comment on the “please update xz | package” bugreport earlier with that the discussion is not irrelevant | and that it’s the maintainer’s responsibility on new upgrades to check | for new legal issues and “other hidden gems”. | | I didn’t because I didn’t want to bother going in with an annoyed | self-righteous “user”. | | Now it turns out all three of the involved ones were “string + number | @ freemailer” #JiaT75 sockpuppets, so it’s probably okay I didn’t | bother. | | Not that I blame Sebastian — it was very well hidden, and even my | usual diffing between old and new version would not have found it. | | I do take away from this to also check the diff between VCS repo at | the time of the release and release tarball. Perhaps also between | branch and tag if they, like Apache Tomcat, introduce extra commits | there. >Is xz-utils going to be maintained? Will we want to keep in the archive >an unmaintained low-level library - low-level as in, susceptible of >getting pulled as a dependency in lots of places - and rely on it for >components such as dpkg? That scenario you describing here would actually be much less of a problem. The problem comes when the library in that state then does get updates that probably are not even necessary but shiny enough people demand them. bye, //mirabilos (also a Debian Developer, despite the From) -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#1068024: revert to version that does not contain changes by bad actor
Christoph Anton Mitterer dixit: >Can we be confidently sure that going back to 5.4.5 is enough? No. >The last one, still from Lasse Collin seems to be 5.4.1: In this bugreport, we’re discussing going back to before any contributions by the adversary. To see whether it’s an option at all (and it sounds like a sensible step right now) which joeyh confirmed (thanks). bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1068024: revert to version that does not contain changes by bad actor
One more thing: Is anyone on the Debian side trying to figure out how far we've been practically affected? I mean let's assume we're "lucky", and the backdoor is only in 5.6.0/5.6.1... and that none of the adversary's earlier commits introduced any serious holes[0] which wouldn't be known yet. Then many servers running Debian (which is then typically Debian stable), would be sill safe. However, many people (and I'd guess that includes DDs/DMs) run their workstations/laptops with testing/unstable. So IMO it's not enough to know that Debian stable is likely not affected - I'd be rather relieved if I'd knew that there's a good chance that the personal computers of most DDs/DMs (who push uploads, etc. pp.) were (at least practically) safe. Some guy decrypted[1] the strings from the maleware's binary payload: https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01#file-hashes-txt-L115 where only /usr/sbin/sshd would be named. Should(!) it turn out, that the actual binary payload actually only affects sshd and especially does not on it's own pull in evil code, it might at least be that all people who hadn't sshd running (or not directly accessible because a router/firewall/etc. was in front of it), would effectively still be safe. No idea whether or not this is really the case - but if so, it might at least mean that many workstations/laptops are safe, because they're not usually directly accessible from the internet. But even then, it would probably need to be checked whether all the versions that Debian ever used/shipped in testing/unstable(/experimental) were actually fully identical to the versions that are now analysed by forensic folks. Is the security team doing anything like that? Cheers, Chris. PS: if someone from the security team reads along, https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27 which is from Sam James of Gentoo, seems to collect good information on what is known so far. Might be worth to add to the links in the security tracker. [0] There are reports about an added '.' in the CMakeLists.txt disabling some sandboxing, but AFAICS at least the current version uses autotools for building?! [1] He also provided the code he used to do so. https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01?permalink_comment_id=5006546#gistcomment-5006546
Bug#1068024: revert to version that does not contain changes by bad actor
On Sun, Mar 31, 2024 at 01:16:07AM +0100, Christoph Anton Mitterer wrote: > The last one, still from Lasse Collin seems to be 5.4.1: > https://git.tukaani.org/?p=xz.git;a=tag;h=f52502e78bf84f516a739e8d8a1357f27eeea75f There are commits from Jia before that, and some that are authored by Lasse but thank Jia for the contribution (the oldest one is 20e7a33e). The most recent release that does not contain any of that seems to be v5.3.2alpha. Berto
Bug#1068024: revert to version that does not contain changes by bad actor
Hey. Can we be confidently sure that going back to 5.4.5 is enough? At least the git tag for that seems to be still signed by the adversary: https://git.tukaani.org/?p=xz.git;a=tag;h=9e4835399118b98954f110f76af2a0d504d2f531 The last one, still from Lasse Collin seems to be 5.4.1: https://git.tukaani.org/?p=xz.git;a=tag;h=f52502e78bf84f516a739e8d8a1357f27eeea75f Cheers, Chris.
Bug#1068024: revert to version that does not contain changes by bad actor
I have prepared a git repository that is a fork of xz from the point I
identified before the attacker(s) did anything to it. In my fork, I have
renamed liblzma to liblzmaunscathed. That allows it to be installed
alongside current dpkg without breaking dpkg with an old version of
liblzma.
My git repository is here (note all my commits are gpg signed):
https://git.joeyh.name/index.cgi/xz-unscathed/
It also has a debian branch which contains a debian directory. I've
built packages of that, as well as building dpkg-1.22.6 against it.
I've attached the patch I used to build dpkg.
My build of dpkg ended up not being linked to a lzma library at all,
because liblzmaunscathed is too old to support concurrent decompression,
which the configure script detects. So dpkg-deb instead uses xz-utils
to decompress debs. I replaced xz-utils.deb with the one built from my
fork, and dpkg seems to work fine using it.
If Debian decided to go this route, you could add xz-utils-unscathed
to unstable, and at the same time update xz-utils to not build
xz-utils.deb. Then build dpkg against it. Then look into forward porting
or re-implementing concurrent decompression if that is really important
to have.
I only plan to maintain this fork minimally, eg backporting security
fixes. The goal is not to take over from xz upstream, but to get the
possibly backdoored code off of production systems ASAP. Presumably xz
upstream will come up with their own solution long-term.
--
see shy jo
diff -ur orig/dpkg-1.22.6/Makefile.in dpkg-1.22.6/Makefile.in
--- orig/dpkg-1.22.6/Makefile.in 2024-03-10 15:21:24.0 -0400
+++ dpkg-1.22.6/Makefile.in 2024-03-30 13:28:12.823685407 -0400
@@ -344,7 +344,7 @@
LTLIBINTL = @LTLIBINTL@
LTLIBOBJS = @LTLIBOBJS@
LT_SYS_LIBRARY_PATH = @LT_SYS_LIBRARY_PATH@
-LZMA_LIBS = @LZMA_LIBS@
+LZMAUNSCATHED_LIBS = @LZMAUNSCATHED_LIBS@
MAKEINFO = @MAKEINFO@
MANIFEST_TOOL = @MANIFEST_TOOL@
MD_LIBS = @MD_LIBS@
diff -ur orig/dpkg-1.22.6/config.h.in dpkg-1.22.6/config.h.in
--- orig/dpkg-1.22.6/config.h.in 2024-03-10 15:21:24.0 -0400
+++ dpkg-1.22.6/config.h.in 2024-03-30 13:28:12.563685572 -0400
@@ -511,8 +511,8 @@
/* Define to 1 to use bz2 library rather than console tool */
#undef WITH_LIBBZ2
-/* Define to 1 to use lzma library rather than console tool */
-#undef WITH_LIBLZMA
+/* Define to 1 to use lzmaunscathed library rather than console tool */
+#undef WITH_LIBLZMAUNSCATHED
/* Define to 1 to compile in SELinux support */
#undef WITH_LIBSELINUX
diff -ur orig/dpkg-1.22.6/configure.ac dpkg-1.22.6/configure.ac
--- orig/dpkg-1.22.6/configure.ac 2024-03-02 21:30:15.0 -0400
+++ dpkg-1.22.6/configure.ac 2024-03-30 13:15:26.981883607 -0400
@@ -113,7 +113,7 @@
DPKG_LIB_MD
DPKG_LIB_Z
DPKG_LIB_BZ2
-DPKG_LIB_LZMA
+DPKG_LIB_LZMAUNSCATHED
DPKG_LIB_ZSTD
DPKG_LIB_SELINUX
AS_IF([test "x$build_dselect" = "xyes"], [
@@ -336,7 +336,7 @@
libselinux . . . . . . . . . : $have_libselinux
libmd . . . . . . . . . . . . : $have_libmd
libz . . . . . . . . . . . . : $have_libz_impl
-liblzma . . . . . . . . . . . : $have_liblzma
+liblzmaunscathed . . . . . . .: $have_liblzmaunscathed
libzstd . . . . . . . . . . . : $have_libzstd
libbz2 . . . . . . . . . . . : $have_libbz2
libcurses . . . . . . . . . . : ${have_libcurses:-no}
diff -ur orig/dpkg-1.22.6/debian/control dpkg-1.22.6/debian/control
--- orig/dpkg-1.22.6/debian/control 2024-03-02 21:30:15.0 -0400
+++ dpkg-1.22.6/debian/control 2024-03-30 13:14:37.746223895 -0400
@@ -20,7 +20,7 @@
zlib1g-dev,
libbz2-dev,
# Version needed for multi-threaded decompressor support.
- liblzma-dev (>= 5.4.0),
+ liblzmaunscathed-dev,
# Version needed for the new streaming API.
libzstd-dev (>= 1.4.0),
libselinux1-dev [linux-any],
@@ -28,7 +28,7 @@
# Needed for the functional test.
bzip2 ,
# Version needed for multi-threaded decompressor support.
- xz-utils (>= 5.4.0) ,
+ xz-utils ,
# Needed for the functional test.
zstd ,
# Needed for the author release process.
@@ -89,7 +89,7 @@
libmd-dev,
zlib1g-dev,
# Version needed for multi-threaded decompressor support.
- liblzma-dev (>= 5.4.0),
+ liblzmaunscathed-dev,
# Version needed for the new streaming API.
libzstd-dev (>= 1.4.0),
libbz2-dev,
@@ -113,7 +113,7 @@
tar (>= 1.28-1),
bzip2,
# Version needed for multi-threaded decompressor support.
- xz-utils (>= 5.4.0),
+ xz-utils,
# Version needed for git-style diff support.
patch (>= 2.7),
make,
@@ -165,7 +165,7 @@
liblocale-gettext-perl,
bzip2,
# Version needed for multi-threaded decompressor support.
- xz-utils (>= 5.4.0),
+ xz-utils,
Suggests:
debian-keyring,
gnupg | sq | sqop | pgpainless-cli | sequoia-chameleon-gnupg,
diff -ur orig/dpkg-1.22.6/debian/libdpkg-dev.install dpkg-1.22.6/debian/libdpkg-dev.install
--- orig/dpkg-1.22.6/debian/libdpkg-dev.install 2024-02-04 22:31:16.0 -0400
+++ dpkg-1.22.6/debian/libdpkg-dev.install 2024-03-30 13:25:27.043840706 -0400
@@ -1,4 +1,5 @@
Bug#1068024: revert to version that does not contain changes by bad actor
> On 2024-03-30, Guillem Jover wrote: > On Sat, 2024-03-30 at 00:48:34 +, Stephan Verbücheln wrote: >> Subject: Re: Bug#1068024: Or remove xz altogether? >> Maybe the people who criticized xz back in the day for being an amateur >> project implementing a defective file format were right all along? >> https://www.nongnu.org/lzip/xz_inadequate.html > *Sigh*, the current situation is bad enough, and has nothing to do > with the xz format or design, or the FUD and propaganda from that > link. Please drop it… While I wouldn’t have brought it up myself, nor the arguably provocative Subject: change (reverted), as it’s indeed only tangentially related to the issue at hand (which apparently have resulted from the absense of good faith developers volunteering to maintain this project – and in a word of defense, the design quality of a software project /does/ influence both the amount of maintenance work and, other things being equal, the desire to get involved), the comment above got me curious: which parts of the document linked are ‘FUD and propaganda’? Because I’ve just glanced it over and I don’t find any obvious examples. Granted, I’m not an expert in the field of compression and coding, per se, and can’t readily speak on the validity of most of the arguments given there, those at least appear plausible. Some arguments I find obvious, such as, e. g.: ADD> A well-known property of CRCs is their ability to detect burst ADD> errors up to the size of the CRC itself. Using a CRC larger ADD> than the dataword is an error because a CRC just as large as ADD> the dataword equally detects all errors while it produces ADD> a lower number of false positives. If there’s a reasonable rebuttal to the points raised in that document, I believe that a pointer to it would be appropriate for this discussion. Other than that, I’m not going to go on this tangent any further here. I’ll be monitoring a handful of Internet fora for that, though (news:alt.os.linux.debian, news:comp.misc, irc://irc.efnet.org/%23coders, etc.) -- FSF associate member #7257 np. Moonsong — Shane Jackman
Bug#1068024: revert to version that does not contain changes by bad actor
Aurelien Jarno wrote: > Note that reverted to such an old version will break packages that use > new symbols introduced since then. From a quick look, this is at least: > - dpkg > - erofs-utils > - kmod > > Having dpkg in that list means that such downgrade has to be planned > carefully. I agree this would be a challanging downgrade. I've tried it myself experimentally and once a downgraded liblzma5 is unpacked, dpkg-deb is broken with missing symbol 'XZ_5.4'. Renaming liblzma5 to something else (liblzma6?) and making dpkg-deb depend on that seems like one way to go that would avoid messy situations. FWIW, I rebuilt xz-utils 5.2.5-2.1~deb11u1 (from bullseye) on sid and then got dpkg to build against that successfully after a few minor changes to dpkg's packaging: --- debian/libdpkg-dev.install.orig 2024-03-30 07:31:46.635365816 -0400 +++ debian/libdpkg-dev.install 2024-03-30 07:34:48.667477725 -0400 @@ -1,4 +1,5 @@ usr/include/dpkg/*.h -usr/lib/*/pkgconfig/libdpkg.pc -usr/lib/*/libdpkg.a +usr/lib/pkgconfig/libdpkg.pc +usr/lib/libdpkg.a usr/share/aclocal/dpkg-*.m4 +usr/lib/libdpkg.la (And after disabling the test suite since changes in xz message output caused a test failure.) -- see shy jo signature.asc Description: PGP signature
Bug#1068024: revert to version that does not contain changes by bad actor
> Might be easier overall to spend that effort on a hard switch to zstd > instead. Good point. Another question that we'll probably have to ask anyway is, what is the future of xz-utils going to be now? Regarding its maintainership as well, both upstream and in Debian? >From what I understand, this package has been NMU'd in Debian for more than 10 years now - thanks to Sebastian for his work - and that might have been a point of weakness which was exploited to push a compromised version into the Debian archive, as seen in #1067708. To quote Thorsten from that thread: > Very much *not* a fan of NMUs doing large changes such as > new upstream versions. I can't say why exactly he would not be a fan, but with hindsight that was an interesting call. Perhaps more importantly, it is said that the whole situation started with the lack of resources from the upstream maintainer to maintain the project: https://www.mail-archive.com/xz-devel@tukaani.org/msg00567.html which again, we can suspect at this point, was exploited with the same modus operandi to get a compromise vector coopted in, in the form of a new maintainer. And now if what we suspect is true, that relief maintainer has turned out to be a bad actor, which leaves upstream back to square one on the maintainance issue. I understand that Lasse Collin hasn't been able to weigh in on the situation yet. Is xz-utils going to be maintained? Will we want to keep in the archive an unmaintained low-level library - low-level as in, susceptible of getting pulled as a dependency in lots of places - and rely on it for components such as dpkg? I'm not presuming the answers - it's still early and there is probably more to figure out yet - but back to the original point, we might want to consider this when sketching longer-term plans. -- Pierre Ynard
Bug#1068024: revert to version that does not contain changes by bad actor
On Fri, 29 Mar 2024 22:32:23 +0100 Aurelien Jarno wrote: > Having dpkg in that list means that such downgrade has to be planned > carefully. Might be easier overall to spend that effort on a hard switch to zstd instead. mfG mow
Bug#1068024: revert to version that does not contain changes by bad actor
Aurelien Jarno dixit: >Having dpkg in that list means that such downgrade has to be planned >carefully. Right. Not an argument against, though. Instead, this is a very good idea. What symbols are new? Can we somehow stub them, or at least where those are used? Or change the soname, so that the old and new-older versions are coïnstallable for during the upgrade? bye, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Bug#1068024: revert to version that does not contain changes by bad actor
On 2024-03-29 16:25, Joey Hess wrote: > I'd suggest reverting to 5.3.1. Bearing in mind that there were security > fixes after that point for ZDI-CAN-16587 that would need to be reapplied. Note that reverted to such an old version will break packages that use new symbols introduced since then. From a quick look, this is at least: - dpkg - erofs-utils - kmod Having dpkg in that list means that such downgrade has to be planned carefully. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Bug#1068024: revert to version that does not contain changes by bad actor
Package: xz-utils Version: 5.6.1+really5.4.5-1 Severity: important Tags: security I count a minimum of 750 commits or contributions to xz by Jia Tan, who backdoored it. This includes all 700 commits made after they merged a pull request in Jan 7 2023, at which point they appear to have already had direct push access, which would have also let them push commits with forged authors. Probably a number of other commits before that point as well. Reverting the backdoored version to a previous version is not sufficient to know that Jia Tan has not hidden other backdoors in it. Version 5.4.5 still contains the majority of those commits. Commits by them such as 18d7facd3802b55c287581405c4d49c98708c136 and ae5c07b22a6b3766b84f409f1b6b5c100469068a show that they were deep into analyzing the security of xz. They were well placed to insert a buffer overflow that could allow eg, a targeted xz file to cause arbitrary code execution. The impact of such a security hole could be much more stealthy and bad than the known backdoor since it would allow chaining xz with other unrelated software releases on an ongoing basis. The package should be reverted to a version before their involvement, which started with commit 6468f7e41a8e9c611e4ba8d34e2175c5dacdbeb4. Or their early commits vetted and revert to a later point, but any arbitrary commit by a known bad and malicious actor almost certainly has less value than the risk that a subtle change go unnoticed. I'd suggest reverting to 5.3.1. Bearing in mind that there were security fixes after that point for ZDI-CAN-16587 that would need to be reapplied. -- see shy jo signature.asc Description: PGP signature
