Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
No argument from me. That JiaTan dude had other projects forked he was looking at. And none of them are good news. zstd. lz4. libarchive. squashfs-tools. But still, I think its good news if people already figured how to turn it off in a few days. On 4/1/2024 1:36 AM, Michael Orlitzky wrote: On Mon, 2024-04-01 at 01:32 +0300, Alexandru N. Barloiu wrote: https://piaille.fr/@zeno/112185928685603910 There's an ENV var you can set that is a kill switch for the whole thing :) For the part that we found :) The author of the backdoor had commit access to the upstream repository for a long time: https://git.tukaani.org/?p=xz.git;a=search;s=Jia+Tan;st=author Personally I would be skeptical of running any version of any package that he has touched.
Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On Mon, 2024-04-01 at 01:32 +0300, Alexandru N. Barloiu wrote: > https://piaille.fr/@zeno/112185928685603910 > > There's an ENV var you can set that is a kill switch for the whole thing :) > For the part that we found :) The author of the backdoor had commit access to the upstream repository for a long time: https://git.tukaani.org/?p=xz.git;a=search;s=Jia+Tan;st=author Personally I would be skeptical of running any version of any package that he has touched.
Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
https://piaille.fr/@zeno/112185928685603910 There's an ENV var you can set that is a kill switch for the whole thing :) On 4/1/2024 1:29 AM, Michael Orlitzky wrote: On Sun, 2024-03-31 at 18:19 -0400, Michael Orlitzky wrote: The old version will show up as liblzma.so.5.6.1. Restart anything that uses it. Or liblzma.so.5.6.0
Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On Sun, 2024-03-31 at 18:19 -0400, Michael Orlitzky wrote: > > The old version will show up as liblzma.so.5.6.1. Restart anything that > uses it. Or liblzma.so.5.6.0
Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On Sun, 2024-03-31 at 12:04 -0400, Rich Freeman wrote: > > It is not necessary to rebuild anything, unless you're doing something > so unusual that you'd already know the answer to the question. > You should probably reboot afterwards though. For a more fine-grained approach, you can check for running processes that still use the old library with something like, root # grep liblzma /proc/*/maps The old version will show up as liblzma.so.5.6.1. Restart anything that uses it.
Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On Sun, Mar 31, 2024 at 5:36 PM Wol wrote: > > On 31/03/2024 20:38, Håkon Alstadheim wrote: > > For commercial entities, the government could just contact the company > > and apply pressure, no need to sneak the backdoor in. Cf. RSA . > > Serving a "secret compliance" notice on a third party is always fraught > with danger. Okay, I probably can't trust my own government to protect > me, but if the US Government served a compliance notice on me I'd treat > it with the respect it deserved - probably use it as loo paper! I imagine most large companies would just comply with their local government, but there are some major limitations all the same: 1. It isn't necessarily the local government who wants to plant the back door. The FBI can't just call up Huawei and get the same results they would with Google. 2. Even if the company complies, there are going to be more people who are aware of the back door. Some of those could be foreign agents. If you infiltrate the company and obfuscate your code, then only your own agents are aware there is an intrusion. 3. The methods employed in your attack might also be sensitive, and so that's another reason to not want to disclose them. If you have some way of subtly compromising some encryption scheme, you might not want any employees of the company to even know the cryptosystem weakness even exists, let alone the fact that you're exploiting it. When the methods are secret in this way it is that much easier to obfuscate a clandestine attack as well. When you look at engineer salaries against national defense budgets, it wouldn't surprise me if a LOT of FOSS (and other) contributors are being paid to add back doors. On the positive side, that probably also means that they're getting paid to fix a lot of bugs and add features just to give them cover. To bomb a power plant might take the combined efforts of 1-2 dozen military aircraft in various roles, at $100M+ each (granted, that's acquisition cost and not operational cost). Installing a trojan that would cause the plant to blow itself up on command might just require paying a few developers for a few years, for probably less than $1M total, and it isn't even that obvious that you were involved if it gets discovered, or even after the plant blows up. -- Rich
Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 31/03/2024 20:38, Håkon Alstadheim wrote: For commercial entities, the government could just contact the company and apply pressure, no need to sneak the backdoor in. Cf. RSA . Apply pressure to who? At the end of the day, the only people the government can trust are their own agents. Serving a "secret compliance" notice on a third party is always fraught with danger. Okay, I probably can't trust my own government to protect me, but if the US Government served a compliance notice on me I'd treat it with the respect it deserved - probably use it as loo paper! Nobody should trust anybody else more than they have need to - and especially governments should not trust 3rd-party nationals! It's not worth it. Cheers, Wol
Re: [gentoo-user] Re: silencing distcc with systemd
I think in the past, the service file had a -v. Somewhere near the present, they reverted to a non -v service file. So if you keep upgrading distcc, prolly the service file still has a -v from past installations. If you uninstall it, and install it again, then prolly you got the new service file which is without -v. That prolly explains why some machines still have it, and some don't. On 4/1/2024 12:03 AM, Daniel Frey wrote: On 3/31/24 13:59, Alexandru N. Barloiu wrote: think the distcc.service file has an extra -v (--verbose). if you remove that, it will behave as expected. I checked all the units on one of the machines still showing the problem and an extra '-v' is not present in any of the files. That's a good thought though. I wouldn't have even thought about that when I was looking at the unit files initially. Dan
Re: [gentoo-user] Re: silencing distcc with systemd
/etc/systemd/system/distccd.service.d/00gentoo.conf or the service file. has to be. there cant be anything else. that's how distcc behaves when started with -v. do a ps axw. figure out where the -v is coming from. maybe a systemctl daemon-reload && systemctl restart distccd. cant be anything else but a -v On 4/1/2024 12:03 AM, Daniel Frey wrote: On 3/31/24 13:59, Alexandru N. Barloiu wrote: think the distcc.service file has an extra -v (--verbose). if you remove that, it will behave as expected. I checked all the units on one of the machines still showing the problem and an extra '-v' is not present in any of the files. That's a good thought though. I wouldn't have even thought about that when I was looking at the unit files initially. Dan
Re: [gentoo-user] Re: silencing distcc with systemd
On 3/31/24 13:59, Alexandru N. Barloiu wrote: think the distcc.service file has an extra -v (--verbose). if you remove that, it will behave as expected. I checked all the units on one of the machines still showing the problem and an extra '-v' is not present in any of the files. That's a good thought though. I wouldn't have even thought about that when I was looking at the unit files initially. Dan
Re: [gentoo-user] Re: silencing distcc with systemd
think the distcc.service file has an extra -v (--verbose). if you remove that, it will behave as expected. On 3/31/2024 11:57 PM, Daniel Frey wrote: On 3/29/24 22:38, Daniel Frey wrote: Hi all, I've moved a couple of machines from openrc to systemd. I have discovered this odd problem. On openrc, distcc was quiet during building packages. It would obey environment variable set in /etc/env.d: DISTCC_DIR=/var/distcc DISTCC_ENABLE_DISCREPANCY_EMAIL= DISTCC_FALLBACK=1 DISTCC_SAVE_TEMPS=0 DISTCC_SSH= DISTCC_TCP_CORK= DISTCC_VERBOSE=0 This currently shows up in the enviroment (checked with `set`.) * snipped the rest * Just an update. I have figured out it isn't systemd causing this issue. I did upgrade several machines. 1. Upgraded the system profile. 2. Converted from split-usr to merged-usr. 3. Converted to systemd. It turns out step 2 caused the problem. I don't know why, but it does - I tested this by converting an openrc machine that I hadn't upgraded yet from split-usr to merged-usr and the problem presented itself (no system on that machine yet.) I did notice the machine I completely reinstalled from scratch (using systemd from the start) did not show signs of this issue. I reinstalled the other distcc host using systemd from the start, installed and configured distcc and it all works as expected. Now to reinstall the slower Celeron devices... come to think of it, I initially installed them in 2011. They haven't ever been reinstalled. Just repurposed. Dan
[gentoo-user] Re: silencing distcc with systemd
On 3/29/24 22:38, Daniel Frey wrote: Hi all, I've moved a couple of machines from openrc to systemd. I have discovered this odd problem. On openrc, distcc was quiet during building packages. It would obey environment variable set in /etc/env.d: DISTCC_DIR=/var/distcc DISTCC_ENABLE_DISCREPANCY_EMAIL= DISTCC_FALLBACK=1 DISTCC_SAVE_TEMPS=0 DISTCC_SSH= DISTCC_TCP_CORK= DISTCC_VERBOSE=0 This currently shows up in the enviroment (checked with `set`.) * snipped the rest * Just an update. I have figured out it isn't systemd causing this issue. I did upgrade several machines. 1. Upgraded the system profile. 2. Converted from split-usr to merged-usr. 3. Converted to systemd. It turns out step 2 caused the problem. I don't know why, but it does - I tested this by converting an openrc machine that I hadn't upgraded yet from split-usr to merged-usr and the problem presented itself (no system on that machine yet.) I did notice the machine I completely reinstalled from scratch (using systemd from the start) did not show signs of this issue. I reinstalled the other distcc host using systemd from the start, installed and configured distcc and it all works as expected. Now to reinstall the slower Celeron devices... come to think of it, I initially installed them in 2011. They haven't ever been reinstalled. Just repurposed. Dan
Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
Den 31.03.2024 14:33, skrev Rich Freeman: (moving this to gentoo-user as this is really getting off-topic for -dev) It might also happen with commercial software, but the challenge there is HR as you can't just pay 1 person to masquerade as 10 when they all need to deal with payroll taxes. For commercial entities, the government could just contact the company and apply pressure, no need to sneak the backdoor in. Cf. RSA .
Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On Sun, Mar 31, 2024 at 10:59 AM Michael wrote: > > On Sunday, 31 March 2024 13:33:20 BST Rich Freeman wrote: > > (moving this to gentoo-user as this is really getting off-topic for -dev) > > Thanks for bringing this to our attention Rich. > > Is downgrading to app-arch/xz-utils-5.4.2 all that is needed for now, or are > we meant to rebuilding any other/all packages, especially if we rebuilt our > @world only a week ago as part of the move to profile 23.0? It is not necessary to rebuild anything, unless you're doing something so unusual that you'd already know the answer to the question. -- Rich
Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On 3/31/24 07:59, Michael wrote: On Sunday, 31 March 2024 13:33:20 BST Rich Freeman wrote: (moving this to gentoo-user as this is really getting off-topic for -dev) Thanks for bringing this to our attention Rich. Is downgrading to app-arch/xz-utils-5.4.2 all that is needed for now, or are we meant to rebuilding any other/all packages, especially if we rebuilt our @world only a week ago as part of the move to profile 23.0? I just ran `glsa-check -l affected` and it came up blank for me. I ran `emerge --sync` and checked again and it indeed says my machine is affected. I then ran `emerge -auDN world` and it automatically downgraded. So, all we need to do sync and update world. It will downgrade xz-utils automatically. If you want to make sure, run `glsa-check -l affected` after the emerge world, if it comes up blank you are not affected. Or run `glsa-check -l 202403-02` and it will tell you if you are affected: $ glsa-check -l 202403-04 [A] means this GLSA was marked as applied (injected), [U] means the system is not affected and [N] indicates that the system might be affected. 202403-04 [U] XZ utils: Backdoor in release tarballs ( app-arch/xz-utils ) Dan
Re: [gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
On Sunday, 31 March 2024 13:33:20 BST Rich Freeman wrote: > (moving this to gentoo-user as this is really getting off-topic for -dev) Thanks for bringing this to our attention Rich. Is downgrading to app-arch/xz-utils-5.4.2 all that is needed for now, or are we meant to rebuilding any other/all packages, especially if we rebuilt our @world only a week ago as part of the move to profile 23.0? signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: [gentoo-dev] Current unavoidable use of xz utils in Gentoo
(moving this to gentoo-user as this is really getting off-topic for -dev) On Sun, Mar 31, 2024 at 7:32 AM stefan1 wrote: > > Had I seen someone say that a bad actor would spend years gaining the > trust of FOSS > project maintainers in order to gain commit access and introduce such > sophisticated > back doors, I would have told them to take their meds. > This is insane. It makes quite a bit of sense though. For a low-activity FOSS project, how much manpower does it take to gain a majority share of the governance? In this case it is one person, but even for a big project (such as Gentoo) I suspect that 3-4 people working full time could probably hit upwards of 50% of the commit volume. That doesn't have to be 3-4 "Gentoo developers." It could be 3-4 human beings with 1 admin assistant who manages 50 email addresses that the commits get spread across, and they sign up as 50 Gentoo developers and get 50 votes for the Council (and probably half the positions there if they want them), the opportunity to peer review "each other's" contributions, and so on. I just use Gentoo as an example as we're all familiar with it and probably assume it couldn't happen here. As you go on, the actual targets are likely to be other projects... > If this happened to something like firefox, I don't think anyone would > have found out. > No one bats an eye if a website loads 0.5s longer. It seems likely that something like this has ALREADY happened to firefox. It might also happen with commercial software, but the challenge there is HR as you can't just pay 1 person to masquerade as 10 when they all need to deal with payroll taxes. We're going on almost 20 years since the Snowden revelations, and back then the NSA was basically doing intrusion on an industrial scale. You'd have dev teams building zero days and rootkits, sysadmin teams who just administrate those back doors to make sure there are always 2-3 ways in just in case one gets closed, SMEs who actually make sense of the stolen data, rooms full of engineers who receive intercepted shipments of hardware and install backdoors on them, and so on. We're looking at what probably only one person can do if they can dedicate full time to something like this. Imagine what a cube farm full of supervised developers with a $50M budget could do, and that is pocket change to most state actors. The US government probably spends more than that in a year on printer paper. -- Rich
