Backdoor in upstream xz/liblzma leading to SSH server compromise(openwall.com)
openwall.com
Backdoor in upstream xz/liblzma leading to SSH server compromise
https://www.openwall.com/lists/oss-security/2024/03/29/4
1,920 评论
Saw this on nix, which was using a compromised version in the unstable channel, I hope not too many systems are affected.
Safety through obscurity and weirdness! If you disable ifunc, like any sensible person, this backdoor disables itself.
I'm curious now. What is ifunc? (Had difficulty finding it through a search)
ifunc is a GNU method of interposing function calls with platform-optimized versions of the function. It is used to detect CPU features at runtime and insert, for example, AVX2-optimized versions of memcmp. It is seen in crypto a lot, because CPUs have many crypto-specific instructions.
However, I don't like it much and I think software should be compiled for the target machine in the first place. My 1 hardened system that is reachable from the public network is based on musl, built mostly with llvm, and with ifunc disabled.
However, I don't like it much and I think software should be compiled for the target machine in the first place. My 1 hardened system that is reachable from the public network is based on musl, built mostly with llvm, and with ifunc disabled.
> However, I don't like it much and I think software should be compiled for the target machine in the first place.
That means you either have to compile software locally on each machine, or you have a combinatorial explosion of possible features.
Compiling locally has several drawbacks. It needs the full compilation environment installed on every machine, which uses a lot of disk space, and some security people dislike it (because then attackers can also compile software locally on that machine); compiling needs a lot of memory and disk space, and uses a lot of processor time and electric power. It also means that signature schemes which only allow signed code cannot be used (or you need to have the signing key available on the target machine, making it somewhat pointless).
The combinatorial explosion of features has been somewhat tamed lately, by bundling sets of feature into feature levels (x86_64-v1, etc), but that still quadruples the amount of compiled code to be distributed, and newer features still have to be selected at runtime.
That means you either have to compile software locally on each machine, or you have a combinatorial explosion of possible features.
Compiling locally has several drawbacks. It needs the full compilation environment installed on every machine, which uses a lot of disk space, and some security people dislike it (because then attackers can also compile software locally on that machine); compiling needs a lot of memory and disk space, and uses a lot of processor time and electric power. It also means that signature schemes which only allow signed code cannot be used (or you need to have the signing key available on the target machine, making it somewhat pointless).
The combinatorial explosion of features has been somewhat tamed lately, by bundling sets of feature into feature levels (x86_64-v1, etc), but that still quadruples the amount of compiled code to be distributed, and newer features still have to be selected at runtime.
I don't think you can really say it is "combinatorial" because there's not a mainstream machine with AES-NI but not, say, SSSE3. In any case if there were such a machine you don't need to support it. The one guy with that box can do scratch builds.
Compiled _on_ and compiled _for_ are not the same. There must be a way to go to the target machine, get some complete dump of CPU features, copy that to the compile-box, do the build, and copy the resulting binaries back.
> That means you either have to compile software locally on each machine, or you have a combinatorial explosion of possible features.
Or you just have to buy a lot of the exact same hardware. Secure installations tend to do that.
Or you just have to buy a lot of the exact same hardware. Secure installations tend to do that.
I have no issues compiling everything on my Gentoo box.
Obviously compiling for the target architecture is best, but for most software (things like crypto libraries excluded) 95% of the benefit of AVX2 is going to come from things like vectorized memcpy/memcmp. Building glibc using ifuncs to provide optimized implementations of these routines gives most users most of the benefit of AVX2 (or whatever other ISA extension) while still distributing binaries that work on older CPU microarchitectures.
ifunc memcpy also makes short copies suck ass on those platforms, since the dispatch cost dominates regardless of the vectorization. It's an open question whether ifunc helps or harms the performance of general use cases.
By "open question" I meant that there is compelling research indicating that GNU memcpy/memcmp is counterproductive, but the general Linux-using public did not get the memo.
https://storage.googleapis.com/gweb-research2023-media/pubto...
"AsmDB: Understanding and Mitigating Front-End Stalls in Warehouse-Scale Computers" Section 4.4 "Memcmp and the perils of micro-optimization"
By "open question" I meant that there is compelling research indicating that GNU memcpy/memcmp is counterproductive, but the general Linux-using public did not get the memo.
https://storage.googleapis.com/gweb-research2023-media/pubto...
"AsmDB: Understanding and Mitigating Front-End Stalls in Warehouse-Scale Computers" Section 4.4 "Memcmp and the perils of micro-optimization"
On the other hand, it also means that your distro can supply a microarchitecture-specific libc and every program automatically gets the memcpy improvements. (Well, except for the golang/rust people.)
Wasn't this the point of Gentoo, back in the day? It was more about instruction scheduling and register allocation differences, but your system would be built with everything optimized for your uarch.
Wasn't this the point of Gentoo, back in the day? It was more about instruction scheduling and register allocation differences, but your system would be built with everything optimized for your uarch.
Is there a way to easily/reliably disable ifunc globally on a system (e.g. ubuntu/debian) without breaking a bunch of things?
FYI this looks for pkgs with liblzma:
> dpkg -l |grep liblzma
Versions >= 5.6 are compromised
FYI this looks for pkgs with liblzma:
> dpkg -l |grep liblzma
Versions >= 5.6 are compromised
https://github.com/google/oss-fuzz/pull/10667
有趣的是，我使用 https://ossinsight.io/analyze/JiaT75 来识别后门作者使用的帐户的贡献。看起来该帐户对其他项目做出了其他可能有问题的贡献。
在针对 Google oss-fuzz 项目的 PR 中禁用 ifunc 可能是他们试图防止该特定后门被该工具标记的一种方式？ https://github.com/google/oss-fuzz/pull/10667
在针对 Google oss-fuzz 项目的 PR 中禁用 ifunc 可能是他们试图防止该特定后门被该工具标记的一种方式？ https://github.com/google/oss-fuzz/pull/10667
有趣的是：https://github.com/tukaani-project/xz/issues/62#issuecomment...
> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.
It looks to be limited to Linux systems that are running certain patches. macOS and BSD seem unaffected?
It looks to be limited to Linux systems that are running certain patches. macOS and BSD seem unaffected?
FreeBSD is not affected as the payloads in question were stripped out, however we are looking into improvements to our workflow to further improve the import process.
[deleted]
> One portion of the backdoor is solely in the distributed tarballs. For
easier reference, here's a link to debian's import of the tarball, but it is
also present in the tarballs for 5.6.0 and 5.6.1:
Ubuntu 22.04 version:
dpkg -l |grep liblzma ii liblzma5:amd64 5.2.5-2ubuntu1 amd64 XZ-format compression library
Whew!
Ubuntu 22.04 version:
dpkg -l |grep liblzma ii liblzma5:amd64 5.2.5-2ubuntu1 amd64 XZ-format compression library
Whew!
Very strange behavior from the upstream developers. Possible government involvement? I have a feeling LANG is checked to target servers from particular countries
[deleted]
One thing to note is that the person that added the commits only started contributing around late 2022 and appears to have a Chinese name. Might be required by law to plant the backdoor.
That would be quite scary considering they have contributed to a wide variety of projects including C++ https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp...
That would be quite scary considering they have contributed to a wide variety of projects including C++ https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp...
我认为您不必担心 C++ 的贡献： https://github.com/MicrosoftDocs/cpp-docs/commit/9a96311122a...
This does make me wonder how much they made a deliberate effort to build an open source portfolio so they’d look more legitimate when time came to mount an attack. It seems expensive but it’s probably not really much at the scale of an intelligence agency.
If I were doing it, I'd have a number of these "burner committers" ready to go when needed.
If I were doing it AND amoral, I'd also be willing to find and compromise committers in various ways.
If I were doing it AND amoral, I'd also be willing to find and compromise committers in various ways.
What's the salary for a software engineer in urban China? 60-80k/yr USD? Two years of that salary is cheaper than a good single shoulder fired missile. Seems like a pretty cheap attack vector to me. A Javelin is a quarter million per pop and they can only hit one target.
Yeah, exactly - when your army is measured in the millions, picking n hundred with technical aptitude is basically a rounding error.
They are paid much less than that. However, American weapons are also far overpriced due to high labor costs, among other things. The Chinese probably have cheaper weapons.
Unless the payment is performed by foreign entity (which means a US employer is hiring a Chinese hacker), it's not a wise choice to do currency exchange when measuring salary, because it would erase other facts affecting salary, like CPI or housing price.
Apart from (both visible and invisible) taxes, I expect a senior programmer would earn ~500-700k CNY per year. Game programmers may reach up to 200k. For a team able to perform such attack, 1M/yr avg. might be reasonable.
But if this is not a state-sponsored attack, I can't find enough interest. And, if this is state-backed...contractor or some dishonest officials would a huge part, so the real cost might be >2M/yr. Considering you can get nothing during 2 year's lurking I doubt if it's feasible enough.
Apart from (both visible and invisible) taxes, I expect a senior programmer would earn ~500-700k CNY per year. Game programmers may reach up to 200k. For a team able to perform such attack, 1M/yr avg. might be reasonable.
But if this is not a state-sponsored attack, I can't find enough interest. And, if this is state-backed...contractor or some dishonest officials would a huge part, so the real cost might be >2M/yr. Considering you can get nothing during 2 year's lurking I doubt if it's feasible enough.
直到您发现 URL 中存在非常微妙的 unicode 更改，这些更改在 GitHub 上没有差异。 :)
[deleted]
No one is being “required by law” to add vulnerabilities, it’s more likely they are foreign agents to begin with.
Depends on the law and where you are. Publicly we have https://www.eff.org/issues/national-security-letters/faq and it's likely that other requests have occurred from time to time, even in the USA.
> No one is being “required by law” to add vulnerabilities
This is absolutely not the case in many parts of the world.
This is absolutely not the case in many parts of the world.
> appears to have a Chinese name
Given the complexity of the attack, I'd assume the name is fake.
Given the complexity of the attack, I'd assume the name is fake.
I would think a Chinese state hacker would not assume a Chinese name, just in case he was discovered like now.
But your reaction being a common one would make a Chinese name the best pick for a Chines agent wanting to hide their country affiliation.
LANG only needs to have some value, the concrete value does not seem to matter.
I am *not* a security researcher, nor a reverse engineer. There's lots of
stuff I have not analyzed and most of what I observed is purely from
observation rather than exhaustively analyzing the backdoor code.FWIW, it felt intimidating as hell. And I'm fairly established professionally. Not sure what I'd have done earlier in my career (although I'd probably not have found it in the first place).
> Not sure what I'd have done earlier in my career
To anybody in this sorta situation, you should absolutely share whatever you have. It doesn’t need to be perfect, good, or 100% accurate, but if there’s a risk you could help a lot of people
To anybody in this sorta situation, you should absolutely share whatever you have. It doesn’t need to be perfect, good, or 100% accurate, but if there’s a risk you could help a lot of people
I hope you've hired a PR person for all the interviews :)
This story is an incredible testament to how open-source software can self-regulate against threats, and more broadly, it reminds us that we all stand on the shoulders of contributors like you. Thank you!
This is one threat that was discovered, only because the implementer was sloppy.
Think about what various corps and state-level actors have been putting in there.
Think about what various corps and state-level actors have been putting in there.
For what it's worth the author is a PostgreSQL committer, he's not a security researcher but he's a pretty damn good engineer!
Honestly, you only get this kind of humility when you're working with absolute wizards on a consistent basis. That's how I read that whole analysis. Absolutely fascinating.
> openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.
The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded into their address space (even if you don't use systemd as PID 1), increasing the risks of supply chain attacks. Thanks, systemd.
The systemd notification protocol could have been as simple as just writing a newline to a pipe, but instead you have to link to the libsystemd C library, so now security-critical daemons like openssh have additional dependencies like liblzma loaded into their address space (even if you don't use systemd as PID 1), increasing the risks of supply chain attacks. Thanks, systemd.
FWIW, I did a quick check on a Devuan system.
The sshd in Devuan does link to a libsystemd stub - this is to cut down on their maintenance of upstream packages.
However that stub does not link to lzma.
On an MX Linux (non-systemd Debian-derived distro) box I ran ldd on /sbin/ssh and also ran:
[EDIT: this string gives cleaner results:]
[EDIT: this string gives cleaner results:]
lsof -w -P -T -p $(pgrep sshd)|grep mem
Huh. That's rather surprising. Do you know how MX Linux handles systemd? Devuan does that shimming of upstream. Do they perhaps just try to leave out certain packages?
Anyway. I did not see lzma in the results on Devuan running a process check (just in case). I did see it on a Debian.
Anyway. I did not see lzma in the results on Devuan running a process check (just in case). I did see it on a Debian.
结果发现 MX 使用了一个名为 systemd-shim 的软件包，它似乎是 Debian 的软件包：
$aptitude 显示 systemd-shim
软件包：systemd-shim
版本：10-6
状态：已安装
自动安装：否
优先级：额外
部分： 管理
维护者：Debian QA Group <[email protected]>
架构：amd64
未压缩大小：82.9 k
取决于：libc6 (>= 2.34)、libglib2.0-0 (>= 2.39.4)、cgmanager (>= 0.32)
建议：pm-utils
冲突：systemd-shim：i386
中断：systemd (< 209)、systemd:i386 (< 209)
描述：systemd 的垫片
该软件包模拟了运行 systemd 帮助程序所需的 systemd 函数，而无需使用 init 服务
$aptitude 显示 systemd-shim
软件包：systemd-shim
版本：10-6
状态：已安装
自动安装：否
优先级：额外
部分： 管理
维护者：Debian QA Group <[email protected]>
架构：amd64
未压缩大小：82.9 k
取决于：libc6 (>= 2.34)、libglib2.0-0 (>= 2.39.4)、cgmanager (>= 0.32)
建议：pm-utils
冲突：systemd-shim：i386
中断：systemd (< 209)、systemd:i386 (< 209)
描述：systemd 的垫片
该软件包模拟了运行 systemd 帮助程序所需的 systemd 函数，而无需使用 init 服务
> The systemd notification protocol could have been as simple as just writing a newline to a pipe
It basically is. libsystemd links to liblzma for other features not related to notifications.
(The protocol is that systemd passes the path to a unix socket in the `NOTIFY_SOCKET` env variable, and the daemon writes "READY=1" into it.)
It basically is. libsystemd links to liblzma for other features not related to notifications.
(The protocol is that systemd passes the path to a unix socket in the `NOTIFY_SOCKET` env variable, and the daemon writes "READY=1" into it.)
Is that protocol documented/stable? For whatever reason, daemons are choosing to link to libsystemd instead of implementing it themselves.
It doesn't matter that libsystemd links to liblzma for other reasons. It's still in the address space of any daemon that is using libsystemd for the notification protocol.
It doesn't matter that libsystemd links to liblzma for other reasons. It's still in the address space of any daemon that is using libsystemd for the notification protocol.
I know Golang has their own implementation of sd_notify().
For Slurm, I looked at what a PITA pulling libsystemd into our autoconf tooling would be, stumbled on the Golang implementation, and realized it's trivial to implement directly.
For Slurm, I looked at what a PITA pulling libsystemd into our autoconf tooling would be, stumbled on the Golang implementation, and realized it's trivial to implement directly.
的确;在任何语言中它都应该是微不足道的。这是Python：https://github.com/9001/copyparty/blob/a080759a03ef5c0a6b06c...
It should be trivial in any language which has AF_UNIX. Last time I looked, Java didn't have it, so the only way was to call into non-Java code.
Then I suggest you have another look =) https://inside.java/2021/02/03/jep380-unix-domain-sockets-ch...
At first I thought that this surely could not be true as of today, but it looks like it is.
There is AF_UNIX support, but only for streams and not datagrams: https://bugs.openjdk.org/browse/JDK-8297837
What an odd decision. I suppose that you could execute systemd-notify but that's a solution that I would not like.
There is AF_UNIX support, but only for streams and not datagrams: https://bugs.openjdk.org/browse/JDK-8297837
What an odd decision. I suppose that you could execute systemd-notify but that's a solution that I would not like.
> I suppose that you could execute systemd-notify but that's a solution that I would not like.
What I did was to use JNA to call sd_notify() in libsystemd.so.0 (when that library exists), which works but obviously does not avoid using libsystemd. I suppose I could have done all the socket calls into glibc by hand, but doing that single call into libsystemd directly was simpler (and it can be expected to exist whenever systemd is being used).
What I did was to use JNA to call sd_notify() in libsystemd.so.0 (when that library exists), which works but obviously does not avoid using libsystemd. I suppose I could have done all the socket calls into glibc by hand, but doing that single call into libsystemd directly was simpler (and it can be expected to exist whenever systemd is being used).
It looks like the FFI (Project Panama) finally landed in Java 22, released a few days ago: https://openjdk.org/jeps/454
Unless that feature also has some weird limitation, you could probably use that to call the socket API in libc.
Unless that feature also has some weird limitation, you could probably use that to call the socket API in libc.
Can me point me to the Golang implementation? Is it a standard package?
最有可能的是 https://github.com/coreos/go-systemd
Caveat is that golang is not a good enough actor to be a reliable indicator of whether this interface is supported, though. They’ll go to the metal because they can, not because it’s stable.
Strange protocol. Why not pass a path to a file that should be `touch`d and/or written to, I wonder? Would avoid the complexity of sockets.
Services may be in a different mount namespace from systemd for sandboxing or other reasons (also means you have to worry about filesystem permissions I suppose). Passing an fd from the parent (systemd) is a nice direct channel between the processes
> libsystemd links to liblzma for other features not related to notifications
Which is pretty emblematic of systemd's primary architectural fault!
Which is pretty emblematic of systemd's primary architectural fault!
systemd getting its tentacles everywhere they can squeeze is a feature, not a bug
The funny thing is that libsystemd _used_ to be split into several different libraries. I certainly remember libsystemd-journal (which is presumably the part of libsystemd that pulls in liblzma) being separate to libsystemd-daemon (which is the part that implements sd_notify, as used by OpenSSH [after patching by distros]).
If that split had never happened, then liblzma wouldn't have ended up being linked into sshd...
If that split had never happened, then liblzma wouldn't have ended up being linked into sshd...
Also thanks to Debian for modifying openssh.
You're not wrong. Had Debian not patched it in this way, OP might have never found it, leaving all other distros who do the same vulnerable.
Note that OP found this in Debian sid as well, which means it's highly unlikely this issue will find its way into any Debian stable systems.
Note that OP found this in Debian sid as well, which means it's highly unlikely this issue will find its way into any Debian stable systems.
是的，systemd通知框架非常简单，我已经在我的项目中使用了它。 我什至不知道 libsystemd 提供了实现。
我的 Arch 系统不易受到攻击，因为 openssh 未链接到 xz。
在我看来，JiaT75 的每一次提交都应该接受审查，甚至可能回滚，因为他们已经抹去了他们的信任。
编辑：
https://github.com/google/oss-fuzz/pull/10667
即使这也可能是邪恶的。
我的 Arch 系统不易受到攻击，因为 openssh 未链接到 xz。
在我看来，JiaT75 的每一次提交都应该接受审查，甚至可能回滚，因为他们已经抹去了他们的信任。
编辑：
https://github.com/google/oss-fuzz/pull/10667
即使这也可能是邪恶的。
> the systemd notification framework is very simple and I've used it in my projects
Have you come across an outline or graph of systemd that you really like, or maybe a good example of a minimal setup?
Have you come across an outline or graph of systemd that you really like, or maybe a good example of a minimal setup?
If they hadn't been modifying SSH their users would never have been hit by this backdoor. Of course if it is actually intended to target SSH on Debian systems, the attacker would likely have picked a different dependency. But adding dependencies like Debian did here means that those dependencies aren't getting reviewed by the original authors. For security-critical software like OpenSSH such unaudited dependencies are prime targets for attacks like this.
It takes a village.
My point was, this is not "Debian did a thing". Lots of other distros do the same thing. In this particular case, it was in fact fortunate for users of all these other distros that Debian did it, lest this vulnerability might have never been found!
Also, only users on sid (unstable) and maybe testing seem to have been affected. I doubt there are many Debian servers out there running sid.
Debian stable (bookworm) has xz-utils version 5.4.1: https://packages.debian.org/bookworm/xz-utils
Also, only users on sid (unstable) and maybe testing seem to have been affected. I doubt there are many Debian servers out there running sid.
Debian stable (bookworm) has xz-utils version 5.4.1: https://packages.debian.org/bookworm/xz-utils
> Debian stable (bookworm) has xz-utils version 5.4.1: https://packages.debian.org/bookworm/xz-utils
Guess who released 5.4.1? JiaT75!
Guess who released 5.4.1? JiaT75!
5.4.1 doesn't even have the `m4/build-to-host.m4` script that pulls the backdoor's tarball.
https://salsa.debian.org/debian/xz-utils/-/tree/v5.4.1/m4
https://salsa.debian.org/debian/xz-utils/-/tree/v5.4.1/m4
Neither does https://salsa.debian.org/debian/xz-utils/-/tree/v5.6.0/m4
The script was not present in the git tree, only in the released archives.
I'm also suggesting that there could be more than one exploit present. All of their commits should be rolled back, none of it can be trusted.
The script was not present in the git tree, only in the released archives.
I'm also suggesting that there could be more than one exploit present. All of their commits should be rolled back, none of it can be trusted.
Not just commits, but all tarballs released with his key.
> 该脚本不存在于 git 树中，仅存在于已发布的档案中。
我承认我不太清楚该仓库的分支和标记策略。非常奇怪的东西。该脚本似乎是 Sebastian Andrzej Siewior 在 5.6.0 版本发布之前添加的。它肯定存在于 Debian git 树中，并且可能存在于许多其他发行版中，因为其他发行版似乎受到了影响。
将脚本添加到 Debian 的提交被标记为“upstream/v5.6.0”，尽管脚本本身不存在于该标记上游：https://github.com/tukaani-project/xz/tree/v5.6.0/m4
> 我还建议可能存在不止一种漏洞利用。他们的所有提交都应该回滚，没有一个是可信的。
我同意。
我承认我不太清楚该仓库的分支和标记策略。非常奇怪的东西。该脚本似乎是 Sebastian Andrzej Siewior 在 5.6.0 版本发布之前添加的。它肯定存在于 Debian git 树中，并且可能存在于许多其他发行版中，因为其他发行版似乎受到了影响。
将脚本添加到 Debian 的提交被标记为“upstream/v5.6.0”，尽管脚本本身不存在于该标记上游：https://github.com/tukaani-project/xz/tree/v5.6.0/m4
> 我还建议可能存在不止一种漏洞利用。他们的所有提交都应该回滚，没有一个是可信的。
我同意。
> I confess I couldn't quite figure out the branching and tagging strategy on that repo.
It's just a regular Debian packaging repository, which includes imports of upstream tarballs - nothing out of ordinary there. Debian packaging is based on tarballs, not on git repos (although in absence of upstream tarballs, Debian maintainer may create a tarball out of VCS repo themselves).
The linked repo just happens to include some tags from upstream repo, but those tags are irrelevant to the packaging. Only "debian/*" and "upstream/*" tags are relevant. Upstream VCS history is only imported for the convenience of the packager, it doesn't have to be there.
Debian's git repositories don't have any forced layout (they don't even have to exist or be up-to-date, the Debian Archive is the only source of truth - note how this repo doesn't contain the latest version of the package), but in practice most of them follow the conventions of DEP-14 implemented by gbp (in this particular case, it looks like `gbp import-orig --upstream-vcs-tag`: https://wiki.debian.org/PackagingWithGit#Upstream_import_met...).
It's just a regular Debian packaging repository, which includes imports of upstream tarballs - nothing out of ordinary there. Debian packaging is based on tarballs, not on git repos (although in absence of upstream tarballs, Debian maintainer may create a tarball out of VCS repo themselves).
The linked repo just happens to include some tags from upstream repo, but those tags are irrelevant to the packaging. Only "debian/*" and "upstream/*" tags are relevant. Upstream VCS history is only imported for the convenience of the packager, it doesn't have to be there.
Debian's git repositories don't have any forced layout (they don't even have to exist or be up-to-date, the Debian Archive is the only source of truth - note how this repo doesn't contain the latest version of the package), but in practice most of them follow the conventions of DEP-14 implemented by gbp (in this particular case, it looks like `gbp import-orig --upstream-vcs-tag`: https://wiki.debian.org/PackagingWithGit#Upstream_import_met...).
Thanks for the explanation, very helpful!
I would phrase it as "It's good we have a heterogenous open-source community".
Monocrops are more vulnerable to disease because the same (biological) exploit works on the entire population. In our Linux biosphere where there are dozens of major, varied configurations sharing parts but not all of their code (and hundreds or thousands of minor variations), a given exploit is likely to fail somewhere, and that failure is likely to create a bug that someone can notice.
It's not foolproof, but it helps keep the ecosystem healthy.
Monocrops are more vulnerable to disease because the same (biological) exploit works on the entire population. In our Linux biosphere where there are dozens of major, varied configurations sharing parts but not all of their code (and hundreds or thousands of minor variations), a given exploit is likely to fail somewhere, and that failure is likely to create a bug that someone can notice.
It's not foolproof, but it helps keep the ecosystem healthy.
[deleted]
[deleted]
That is all the protocol is. From https://www.freedesktop.org/software/systemd/man/latest/sd_n...:
> These functions send a single datagram with the state string as payload to the socket referenced in the $NOTIFY_SOCKET environment variable.
The simplest implementation (pseudocode, no error handling, not guaranteed to compile), is something like:
> These functions send a single datagram with the state string as payload to the socket referenced in the $NOTIFY_SOCKET environment variable.
The simplest implementation (pseudocode, no error handling, not guaranteed to compile), is something like:
const char *addrstr = getenv("NOTIFY_SOCKET");
if (addrstr) {
int fd = socket(AF_UNIX, SOCK_DGRAM, 0);
struct sockaddr_un addr = { .sun_family = AF_UNIX };
strncpy(addr.sun_path, sizeof(addr.sun_path), addrstr);
connect(fd, (struct sockaddr*) &addr);
write(fd, "READY=1");
close(fd);
}goddamnit leftpad got us too :)
This is what I did for a daemon I'm maintaining. Type=notify support was requested but I'm really allergic to adding new libs to a project until they really do some heavy lifting and add enough value. I was pleasantly surprised the protocol was that simple and implemented it myself. I think systemd should just provide a simple standalone reference implementation and encourage people to copy it into their project directly. (But maybe they already do, I did that almost a decade ago IIRC when the feature was relatively new.)
[deleted]
[deleted]
Whoops, you forgot `vsock:`, `@`, `SO_PASSCRED` (I think)... oh and where is that example provided? But yep that's all the protocol is for sure (and forever)!
One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of complexity.
Yes, there are things delivered with that complexity. However, as an example, sysvinit is maybe, oh, 20k lines of code including binaries, heck including all core init scripts.
What's systemd? 2M lines? It was >1M lines 4+ years ago.
For an init system, a thing that is to be the core of stability, security, and most importantly glacial, stable change -- that is absurdly complex. It's exceedingly over engineered.
And so you get cases like this. And cases like that, and that over there, and that case over there too. All which could not exist, if systemd didn't try to overengineer, over complicate everything.
Ah well. I'm still waiting for someone to basically fork systemd, remove all the fluff (udev, ntp, dns, timers, restart code, specialized logging, on and on and on), and just end up with systemd compatible service files.
But not yet. So... well, oh well.
Yes, there are things delivered with that complexity. However, as an example, sysvinit is maybe, oh, 20k lines of code including binaries, heck including all core init scripts.
What's systemd? 2M lines? It was >1M lines 4+ years ago.
For an init system, a thing that is to be the core of stability, security, and most importantly glacial, stable change -- that is absurdly complex. It's exceedingly over engineered.
And so you get cases like this. And cases like that, and that over there, and that case over there too. All which could not exist, if systemd didn't try to overengineer, over complicate everything.
Ah well. I'm still waiting for someone to basically fork systemd, remove all the fluff (udev, ntp, dns, timers, restart code, specialized logging, on and on and on), and just end up with systemd compatible service files.
But not yet. So... well, oh well.
I have a design in the works to do just this.
The problem? It's on the backburner because I don't think I could find a business model to make money from it.
I don't think offering support for a price would work, for example.
The problem? It's on the backburner because I don't think I could find a business model to make money from it.
I don't think offering support for a price would work, for example.
What about sponsors? Actually, now I have the idea of a platform similar to Kickstarter but for software development, and with just sponsors. It wouldn't work, sure... Except in some cases. Like when things like this happen...
Sponsors are fickle, unfortunately, and they tend to remove "donations" when money gets tight.
If I am considered a full vendor, though, and a vendor for a critical piece of software, they might keep me around.
If I am considered a full vendor, though, and a vendor for a critical piece of software, they might keep me around.
What's the point of your implementation? systemd is totally modular, you can use just the init system without networkd, timesyncd, resolved, nspawn, whatever else I forgot about.
If you want you can just use systemd as PID1 for service management and enjoy a sane way to define and manage services – and do everything in archaic ways like 20 years ago.
If you want you can just use systemd as PID1 for service management and enjoy a sane way to define and manage services – and do everything in archaic ways like 20 years ago.
There are two points to the implementation:
* Choice. If I have a separate implementation, my users do not have to be subject to systemd's choices. And I do not either.
* The same implementation will have the same bugs, so in the same way that redundant software has multiple independent implementations, having an independent implementation will avoid the same bugs. It may have different bugs, sure, but my goal would be to test like SQLite and achieve DO-178C certification. Or as close as I could, anyway.
* Choice. If I have a separate implementation, my users do not have to be subject to systemd's choices. And I do not either.
* The same implementation will have the same bugs, so in the same way that redundant software has multiple independent implementations, having an independent implementation will avoid the same bugs. It may have different bugs, sure, but my goal would be to test like SQLite and achieve DO-178C certification. Or as close as I could, anyway.
I'd assume chances of monetizing this are incredibly low. There already is an init system that understands systemd unit files, the name escapes my mind unfortunately. DO-178C might be a selling point literally, but whether there's enough potential customers for ROI is questionable.
I unfortunately agree with you. Hence why it's on the backburner.
No, you can't. Systemd might be somewhat modular; the things distros ship which depend on it are not.
Well some distros might force more components upon you but thas hardly systemd's fault. Same if some software decides to make use of another component of systemd - then that's their choice, but also there are alternatives. The only thing that comes to mind right now would be something like GNOME which requires logind, but all other "typical" software only wants systemd-the-init-system if anything. You can run Debian just fine with just systemd as an init system and nothing else.
> Ah well. I'm still waiting for someone to basically fork systemd, remove all the fluff (udev, ntp, dns, timers, restart code, specialized logging, on and on and on)
Most of the things you named there are modular and can be easily disabled.
Furthermore, udev precedes systemd and systemd has in fact its own replacement for it (though the name escapes me).
Kind of a classic, people loving harping on systemd without properly understanding it.
Most of the things you named there are modular and can be easily disabled.
Furthermore, udev precedes systemd and systemd has in fact its own replacement for it (though the name escapes me).
Kind of a classic, people loving harping on systemd without properly understanding it.
Systemd is actually pretty damn good and it's GPL licensed free software.
I understand that people don't like the way it seems to work itself into the rest of Linux user space as a dependency but that's actually our own fault for not investing the man power that Red Hat invests. We have better things to do than make our own Linux user space and so they have occupied that niche. It's free software though, we always have the freedom to do whatever we want.
By the way, all the stuff you mentioned is not really part of the actual init system, namely PID 1. There's an actual service manager for example and it's entirely separate from init. It manages services really well too, it's measurably better than all that "portable" nonsense just by virtue of using cgroups to manage processes which means it can actually supervise poorly written double forking daemons.
I understand that people don't like the way it seems to work itself into the rest of Linux user space as a dependency but that's actually our own fault for not investing the man power that Red Hat invests. We have better things to do than make our own Linux user space and so they have occupied that niche. It's free software though, we always have the freedom to do whatever we want.
By the way, all the stuff you mentioned is not really part of the actual init system, namely PID 1. There's an actual service manager for example and it's entirely separate from init. It manages services really well too, it's measurably better than all that "portable" nonsense just by virtue of using cgroups to manage processes which means it can actually supervise poorly written double forking daemons.
People are complaining that it's too big, labyrinthine, and arcane to audit, not that it doesn't work. They would prefer other things that work, but don't share those characteristics.
Also, the more extensive the remit (of this init), the more complexly interconnected the interactions between the components; the fewer people understand the architecture, the fewer people understand the code, the fewer people read the code. This creates a situation where the codebase is getting larger and larger at a rate faster than the growth of the number of man-hours being put into reading it.
This has to make it easier for people who are systemd specialists to put in (intentionally or unintentionally) backdoors and exploitable bugs that will last for years.
People keep defending systemd by talking about its UI and its features, but that completely misses the point. If systemd were replaced by something comprehensible and less internally codependent, even if the systemd UI and features were preserved, most systemd complainers would be over the moon with happiness. Red Hat invests too much into completely replacing linux subsystems, they should take a break. Maybe fix the bugs in MATE.
Also, the more extensive the remit (of this init), the more complexly interconnected the interactions between the components; the fewer people understand the architecture, the fewer people understand the code, the fewer people read the code. This creates a situation where the codebase is getting larger and larger at a rate faster than the growth of the number of man-hours being put into reading it.
This has to make it easier for people who are systemd specialists to put in (intentionally or unintentionally) backdoors and exploitable bugs that will last for years.
People keep defending systemd by talking about its UI and its features, but that completely misses the point. If systemd were replaced by something comprehensible and less internally codependent, even if the systemd UI and features were preserved, most systemd complainers would be over the moon with happiness. Red Hat invests too much into completely replacing linux subsystems, they should take a break. Maybe fix the bugs in MATE.
>the more complexly interconnected the interactions between the components
This is a bit of a rich criticism of systemd, given the init scripts it replaced.
> Red Hat invests too much into completely replacing linux subsystems, they should take a break. Maybe fix the bugs in MATE.
MATE isn't a Red Hat project. And nobody complains about Pipewire.
This is a bit of a rich criticism of systemd, given the init scripts it replaced.
> Red Hat invests too much into completely replacing linux subsystems, they should take a break. Maybe fix the bugs in MATE.
MATE isn't a Red Hat project. And nobody complains about Pipewire.
A shell script with a few defined arguments is not a complexly interconnected set of components. It's literally the simplest, most core, least-strongly-dependent interconnection that exists in a nix system.
Tell us you never bothered to understand how init worked before drawing a conclusion on it without telling us.
Tell us you never bothered to understand how init worked before drawing a conclusion on it without telling us.
Have you ever seen the init scripts of a reasonably-complex service that required other services to be online?
Yep.
depend(){
need net localmount
after bootmisc
}Let’s not get started on how large the kernel is. Large code bases increase attack surface, period. The only sensible solution is to micro service out the pieces and only install the bare essentials. Why does the an x86 server come with Bluetooth drivers baked in?
The kernel devs are wasting time writing one offs for every vendor known to man, and it ships to desktops too.
The kernel devs are wasting time writing one offs for every vendor known to man, and it ships to desktops too.
> Red Hat invests too much into completely replacing linux subsystems, they should take a break.
They should do whatever they feel is best for them, as should we. They're releasing free as in freedom GPL Linux software, high quality software at that. Thus I have no moral objections to their activities.
You have to realize that this is really a symptom of others not putting in the required time and effort to produce a better alternative. I know because I reinvent things regularly just because I enjoy it. People underestimate by many orders of magnitude the effort required to make something like this.
So I'm really thankful that I got systemd, despite many valid criticisms. It's a pretty good system, and it's not proprietary nonsense. I've learned to appreciate it.
They should do whatever they feel is best for them, as should we. They're releasing free as in freedom GPL Linux software, high quality software at that. Thus I have no moral objections to their activities.
You have to realize that this is really a symptom of others not putting in the required time and effort to produce a better alternative. I know because I reinvent things regularly just because I enjoy it. People underestimate by many orders of magnitude the effort required to make something like this.
So I'm really thankful that I got systemd, despite many valid criticisms. It's a pretty good system, and it's not proprietary nonsense. I've learned to appreciate it.
How is the service manager different from PID1/init?
They are completely different things.
Init just a more or less normal program that Linux starts by default and by convention. You can make it boot straight into bash if you want. I created a little programming language with the ultimate goal of booting Linux directly into it and bringing up the entire system from inside it.
It's just a normal process really. Two special cases that I can think of: no default signal handling, and it can't ever exit. Init will not get interrupted by signals unless it explicitly configures the signal dispositions, even SIGKILL will not kill it. Linux will panic if PID 1 ever exits so it can't do that.
Traditionally, it's also the orphaned child process reaper. Process descriptors and their IDs hang around in memory until something calls wait on them. Parent processes are supposed to do that but if they don't it's up to init to do it. Well, that's the way it works traditionally on Unix. On Linux though that's customizable with prctl and PR_SET_CHILD_SUBREAPER so you actually can factor that out to a separate process. As far as I know, systemd does just that, making it more modular and straight up better than traditional Unix, simply because this separate process won't make Linux panic if it ever crashes.
As for the service manager, this page explains process and service management extremely well:
https://mywiki.wooledge.org/ProcessManagement
Systemd does it right. It does everything that's described in there, does it correctly, uses powerful Linux features like cgroups for even better process management and also solves the double forking problem described in there. It's essentially a solved problem with systemd. Even the people who hate it love the unit files it uses and for good reason.
Init just a more or less normal program that Linux starts by default and by convention. You can make it boot straight into bash if you want. I created a little programming language with the ultimate goal of booting Linux directly into it and bringing up the entire system from inside it.
It's just a normal process really. Two special cases that I can think of: no default signal handling, and it can't ever exit. Init will not get interrupted by signals unless it explicitly configures the signal dispositions, even SIGKILL will not kill it. Linux will panic if PID 1 ever exits so it can't do that.
Traditionally, it's also the orphaned child process reaper. Process descriptors and their IDs hang around in memory until something calls wait on them. Parent processes are supposed to do that but if they don't it's up to init to do it. Well, that's the way it works traditionally on Unix. On Linux though that's customizable with prctl and PR_SET_CHILD_SUBREAPER so you actually can factor that out to a separate process. As far as I know, systemd does just that, making it more modular and straight up better than traditional Unix, simply because this separate process won't make Linux panic if it ever crashes.
As for the service manager, this page explains process and service management extremely well:
https://mywiki.wooledge.org/ProcessManagement
Systemd does it right. It does everything that's described in there, does it correctly, uses powerful Linux features like cgroups for even better process management and also solves the double forking problem described in there. It's essentially a solved problem with systemd. Even the people who hate it love the unit files it uses and for good reason.
我知道它们在概念上的差异。
人们通常抱怨的事情是 systemd 强制将其进程管理器设置为 pid=1。 IE。 https://github.com/systemd/systemd/issues/12843 中“讨论”的事情
还有一个辅助功能可以运行每用户管理器，但我不确定它是否在没有 systemd PID1 的情况下运行。虽然它可能只依赖于登录。
人们通常抱怨的事情是 systemd 强制将其进程管理器设置为 pid=1。 IE。 https://github.com/systemd/systemd/issues/12843 中“讨论”的事情
还有一个辅助功能可以运行每用户管理器，但我不确定它是否在没有 systemd PID1 的情况下运行。虽然它可能只依赖于登录。
Wow, I remember reading that PID != 1 line years ago. Had no idea they changed it. I stand corrected then. Given the existence of user service managers as well as flags like --system and --user, I inferred that they were all entirely separate processes.
Makes no sense to me why the service manager part would require running as PID 1. The maintainer just says this:
> PID 1 is very different from other processes, and we rely on that.
He doesn't really elaborate on the matter though.
Every time this topic comes up I end up searching for those so called PID 1 differences. I come up short every time aside from the two things I mentioned above. Is this information buried deep somewhere?
Just asked ChatGPT about PID 1 differences. It gave me the aforementioned two differences, completely dismissed Linux's prctl child subreaper feature "because PID 1 often assumes this role in practice" as well as some total bullshit about process group leaders and regular processes not being special enough to interact with the kernel which is just absolute nonsense.
So I really have no idea what it is about PID 1 that systemd is supposedly relying on that makes it impossible to split off the service manager from it. Everything I have read up until now suggests that it is not required, especially on Linux where you have even more control and it's not like systemd is shy about using Linux exclusive features.
Makes no sense to me why the service manager part would require running as PID 1. The maintainer just says this:
> PID 1 is very different from other processes, and we rely on that.
He doesn't really elaborate on the matter though.
Every time this topic comes up I end up searching for those so called PID 1 differences. I come up short every time aside from the two things I mentioned above. Is this information buried deep somewhere?
Just asked ChatGPT about PID 1 differences. It gave me the aforementioned two differences, completely dismissed Linux's prctl child subreaper feature "because PID 1 often assumes this role in practice" as well as some total bullshit about process group leaders and regular processes not being special enough to interact with the kernel which is just absolute nonsense.
So I really have no idea what it is about PID 1 that systemd is supposedly relying on that makes it impossible to split off the service manager from it. Everything I have read up until now suggests that it is not required, especially on Linux where you have even more control and it's not like systemd is shy about using Linux exclusive features.
> By the way, all the stuff you mentioned is not really part of the actual init system, namely PID 1
Except it literally is. I once had a systemd system suddenly refuse to boot (kernel panic because PID1 crashed or so) after a Debian upgrade, which I was able to resolve by... wait for it... making /etc/localtime not be a symlink.
Why does a failure doing something with the timezone make you unable to boot your system? What is it even doing with the timezone? What is failing about it? Who knows, good luck strace'ing PID1!
Except it literally is. I once had a systemd system suddenly refuse to boot (kernel panic because PID1 crashed or so) after a Debian upgrade, which I was able to resolve by... wait for it... making /etc/localtime not be a symlink.
Why does a failure doing something with the timezone make you unable to boot your system? What is it even doing with the timezone? What is failing about it? Who knows, good luck strace'ing PID1!
Turns out you're right and my knowledge was outdated. I seriously believed the systemd service manager was separate from its PID 1 but at some point they even changed the manuals to say that's not supported.
I was also corrected further down in the thread, with citations from the maintainers even:
https://news.ycombinator.com/item?id=39871735
As it stands I really have no idea why the service manager has not been split off from PID 1. Maintainer said that PID 1 was "different" but didn't really elaborate. Can't find much reliable information about said differences either. Do you know?
I was also corrected further down in the thread, with citations from the maintainers even:
https://news.ycombinator.com/item?id=39871735
As it stands I really have no idea why the service manager has not been split off from PID 1. Maintainer said that PID 1 was "different" but didn't really elaborate. Can't find much reliable information about said differences either. Do you know?
I have no idea, lol. Maybe the signal handling behavior? You can't signal PID1 (unless the process has installed its own signal handler for that signal). Even SIGKILL won't usually work.
That's my entire problem with systemd though: despite the averred modularity, it combines far too many concerns for anyone to understand how or why it works the way it does.
That's my entire problem with systemd though: despite the averred modularity, it combines far too many concerns for anyone to understand how or why it works the way it does.
是的，信号处理确实如此，PID 1 是唯一可以处理或屏蔽 SIGKILL 甚至 SIGSTOP 的进程。 systemd 手册记录了它对大量信号的处理，但其中没有任何关于这些不可屏蔽信号的内容。所以我真的不明白 systemd 是如何“依赖”任何东西的。它不处理 SIGKILL，是吗？
另一个区别是 PID 1 无法退出，因为如果退出，Linux 就会出现恐慌。这实际上是把功能移出 PID 1 的一个论点。
还有其他服务管理器在 PID 1 之外工作。Systemd 本身实际上会生成其自身的非 PID 1 实例来处理用户服务。我想只有维护者才能告诉我们为什么他们这样做。
也许他们依赖的是 PID 1 传统上收获僵尸这一事实，尽管 Linux 有一个 pctl ：
https://www.man7.org/linux/man-pages/man2/prctl.2.html
PR_SET_CHILD_SUBREAPER
如果问题只是没有人愿意编写代码来将僵尸进程收割到一个单独的进程怎么办？在这种情况下他们会接受补丁吗？
可笑的是，该手册页直接说 systemd 使用此系统调用将自己设置为僵尸进程的收割者：
> 一些 init(1) 框架（例如 systemd(1)）采用 subreaper 进程
如果这是真的，那么我真的不知道他们所依赖的 PID 1 到底是什么。
编辑：刚刚检查了源代码，确实如此。
https://github.com/systemd/systemd/blob/main/src/core/main.c...
https://github.com/systemd/systemd/blob/main/src/basic/proce...
https://github.com/systemd/systemd/blob/main/src/basic/proce...
因此，它们不依赖于特殊的信号处理，甚至对非 PID 1 子子收割机有特殊支持。对我来说毫无意义。为什么他们不能放弃那些 PID == 1 检查并制作一个更简单的 PID 1 程序来生成真正的 systemd 服务管理器？
编辑：他们的代码库中已经有一个简单的 PID 1！
https://github.com/systemd/systemd/blob/main/src/nspawn/nspa...
但它仅在名称空间内使用！为什么？不知道。
另一个区别是 PID 1 无法退出，因为如果退出，Linux 就会出现恐慌。这实际上是把功能移出 PID 1 的一个论点。
还有其他服务管理器在 PID 1 之外工作。Systemd 本身实际上会生成其自身的非 PID 1 实例来处理用户服务。我想只有维护者才能告诉我们为什么他们这样做。
也许他们依赖的是 PID 1 传统上收获僵尸这一事实，尽管 Linux 有一个 pctl ：
https://www.man7.org/linux/man-pages/man2/prctl.2.html
PR_SET_CHILD_SUBREAPER
如果问题只是没有人愿意编写代码来将僵尸进程收割到一个单独的进程怎么办？在这种情况下他们会接受补丁吗？
可笑的是，该手册页直接说 systemd 使用此系统调用将自己设置为僵尸进程的收割者：
> 一些 init(1) 框架（例如 systemd(1)）采用 subreaper 进程
如果这是真的，那么我真的不知道他们所依赖的 PID 1 到底是什么。
编辑：刚刚检查了源代码，确实如此。
https://github.com/systemd/systemd/blob/main/src/core/main.c...
https://github.com/systemd/systemd/blob/main/src/basic/proce...
https://github.com/systemd/systemd/blob/main/src/basic/proce...
因此，它们不依赖于特殊的信号处理，甚至对非 PID 1 子子收割机有特殊支持。对我来说毫无意义。为什么他们不能放弃那些 PID == 1 检查并制作一个更简单的 PID 1 程序来生成真正的 systemd 服务管理器？
编辑：他们的代码库中已经有一个简单的 PID 1！
https://github.com/systemd/systemd/blob/main/src/nspawn/nspa...
但它仅在名称空间内使用！为什么？不知道。
> The other difference is PID 1 can't exit because Linux panics if it does. That's actually an argument for moving functionality out of PID 1.
I actually kinda think that can be an advantage for a service manager. If your service manager crashes an automatic reboot is nice, in a way. I doubt that's why they did it though.
I actually kinda think that can be an advantage for a service manager. If your service manager crashes an automatic reboot is nice, in a way. I doubt that's why they did it though.
> If your service manager crashes an automatic reboot is nice, in a way.
I don't think it's gonna do that! I saw it in the source code: when it's running as PID 1, systemd installs a crash handler that freezes itself in a desperate attempt to avoid the kernel panic! It's pretty amazing. They could have written it so that PID 1 watches over the service manager and just restarts it if it ever crashes. I mean, systemd already supports soft-rebooting the entire user space which is pretty much exactly what would happen if PID 1 restarted a separate service manager.
Know what else I found in the source code? Various references to /proc/1. I'm starting to think that's the true reason why they want to be PID 1...
I don't think it's gonna do that! I saw it in the source code: when it's running as PID 1, systemd installs a crash handler that freezes itself in a desperate attempt to avoid the kernel panic! It's pretty amazing. They could have written it so that PID 1 watches over the service manager and just restarts it if it ever crashes. I mean, systemd already supports soft-rebooting the entire user space which is pretty much exactly what would happen if PID 1 restarted a separate service manager.
Know what else I found in the source code? Various references to /proc/1. I'm starting to think that's the true reason why they want to be PID 1...
This is a bit like complaining that the Linux kernel has 30 million lines of code, while ignoring that 3/4 of that is in hardware support (drivers) or filesystems that nobody is actually required to use at any given time.
systemd is a collection of tools, one of which is an init system. Nobody accused GNU yes of being bloated just because it's in a repository alongside 50 other tools.
systemd is a collection of tools, one of which is an init system. Nobody accused GNU yes of being bloated just because it's in a repository alongside 50 other tools.
Gnu 是的，实际上相当臃肿。对于如此微不足道的事情，只有 130 行代码 [1]！ ;)
[1] https://github.com/coreutils/coreutils/blob/master/src/yes.c
[1] https://github.com/coreutils/coreutils/blob/master/src/yes.c
yes(1) is the standard unix way of generating repeated data.
It's good to do this as quickly as possible.
I really don't understand why so many get annoyed with this code.
130 lines isn't that complicated in the scheme of things.
> that nobody is actually required to use at any given time
But that's the very problem with systemd! As time goes on you're required, whether by systemd itself or by the ecosystem around it, to use more and more of it, until it's doing not only service management but also timezones, RTC, DNS resolution, providing getpwent/getgrent, inetd, VMs and containers, bootloader, udev (without adding literally any benefit over the existing implementations), ... oh and you also have to add significant complexity in other things (like the kernel!) to use it, like namespaces (which have been a frequent source of vulnerabilities)...
But that's the very problem with systemd! As time goes on you're required, whether by systemd itself or by the ecosystem around it, to use more and more of it, until it's doing not only service management but also timezones, RTC, DNS resolution, providing getpwent/getgrent, inetd, VMs and containers, bootloader, udev (without adding literally any benefit over the existing implementations), ... oh and you also have to add significant complexity in other things (like the kernel!) to use it, like namespaces (which have been a frequent source of vulnerabilities)...
> timezones, RTC, DNS resolution, providing getpwent/getgrent, inetd, VMs and containers, bootloader
How many of those are you actually required to use systemd for? At least for DNS, inetd, containers and bootloader I'm pretty sure I run a few different alternatives across my systems. I think major distros (running systemd) still ship with different dns and inetd, for containers its a lot more common to use a docker-like (probably docker or podman) than it is to use systemd-nspawn.
> oh and you also have to add significant complexity in other things (like the kernel!) to use it, like namespaces (which have been a frequent source of vulnerabilities)
Namespaces were implemented before systemd, have been used before systemd in widely used systems (for example LXC and many others). Namespaces and similar kernel features are not tied to systemd.
How many of those are you actually required to use systemd for? At least for DNS, inetd, containers and bootloader I'm pretty sure I run a few different alternatives across my systems. I think major distros (running systemd) still ship with different dns and inetd, for containers its a lot more common to use a docker-like (probably docker or podman) than it is to use systemd-nspawn.
> oh and you also have to add significant complexity in other things (like the kernel!) to use it, like namespaces (which have been a frequent source of vulnerabilities)
Namespaces were implemented before systemd, have been used before systemd in widely used systems (for example LXC and many others). Namespaces and similar kernel features are not tied to systemd.
> How many of those are you actually required to use systemd for?
That depends on what other software you want to run, because systemd's design heavily encourages other things (distros, libraries, applications) to take dependencies on various bits. See also: every mainstream distro.
> Namespaces were implemented before systemd, have been used before systemd in widely used systems (for example LXC and many others). Namespaces and similar kernel features are not tied to systemd.
Didn't say they were. But I don't have to use LXC or many others in order to use the most popular distros and applications.
I do have to use systemd for that, though.
Which means I have to have namespaces enabled.
That depends on what other software you want to run, because systemd's design heavily encourages other things (distros, libraries, applications) to take dependencies on various bits. See also: every mainstream distro.
> Namespaces were implemented before systemd, have been used before systemd in widely used systems (for example LXC and many others). Namespaces and similar kernel features are not tied to systemd.
Didn't say they were. But I don't have to use LXC or many others in order to use the most popular distros and applications.
I do have to use systemd for that, though.
Which means I have to have namespaces enabled.
>namespaces (which have been a frequent source of vulnerabilities)...
Unprivileged user namespaces sure, but I don't think that applies to namespaces in general (which without unprivileged user namespaces can only be created by root, and LPE is the concern with unprivileged userns due to increased attack surface). systemd doesn't need unprivileged userns to run.
Unprivileged user namespaces sure, but I don't think that applies to namespaces in general (which without unprivileged user namespaces can only be created by root, and LPE is the concern with unprivileged userns due to increased attack surface). systemd doesn't need unprivileged userns to run.
> 许多人不理解的反对意见之一是 systemd 增加了复杂性。不必要的复杂性。船满了，负载满了，山充满了复杂性。
这是而且一直都是如此愚蠢的想法。
如果您想实现一个没有“不必要的复杂性”并且仍然提供人们当前想要的所有功能的 init （和朋友）系统，那么就去做并向我们展示？ 否则，它只是抱怨事情不再像过去可怕的 init 那样，是一堆有缺陷和花哨的 shell 脚本。
这是而且一直都是如此愚蠢的想法。
如果您想实现一个没有“不必要的复杂性”并且仍然提供人们当前想要的所有功能的 init （和朋友）系统，那么就去做并向我们展示？ 否则，它只是抱怨事情不再像过去可怕的 init 那样，是一堆有缺陷和花哨的 shell 脚本。
> about things not being like the terrible old days of init being a mass of buggy and racey shell scripts.
Zero of the major distros used System V init by default. Probably only distros like Slackware or Linux From Scratch even suggested it.
It's unfortunate that so many folks uncritically swallowed the Systemd Cabal's claims about how they were the first to do this, that, or the other.
(It's also darkly amusing to note that every service that has nontrivial pre-start or post-start configuration and/or verification requirements ends up using systemd to run at least one shell script... which is what would have often been inlined into their init script in other init systems.)
Zero of the major distros used System V init by default. Probably only distros like Slackware or Linux From Scratch even suggested it.
It's unfortunate that so many folks uncritically swallowed the Systemd Cabal's claims about how they were the first to do this, that, or the other.
(It's also darkly amusing to note that every service that has nontrivial pre-start or post-start configuration and/or verification requirements ends up using systemd to run at least one shell script... which is what would have often been inlined into their init script in other init systems.)
> Zero of the major distros used System V init by default. Probably only distros like Slackware or Linux From Scratch even suggested it.
I have absolutely no idea what you're trying to claim.
Are you suggesting that Debian's "sysvinit" package wasn't a System V init system? That the years I spent editing shell scripts in /etc/init.d/ wasn't System V init?
or are you making some pointless distinction about it not actually being pre-lawsuit AT&T files so it doesn't count or something?
or did you not use Linux before 2010?
if you have some important point to make, please make it more clearly.
> It's unfortunate that so many folks uncritically swallowed the Systemd Cabal's claims about how they were the first to do this, that, or the other.
I feel like you have very strong emotions about init systems that have nothing to do with the comment you're replying to.
I have absolutely no idea what you're trying to claim.
Are you suggesting that Debian's "sysvinit" package wasn't a System V init system? That the years I spent editing shell scripts in /etc/init.d/ wasn't System V init?
or are you making some pointless distinction about it not actually being pre-lawsuit AT&T files so it doesn't count or something?
or did you not use Linux before 2010?
if you have some important point to make, please make it more clearly.
> It's unfortunate that so many folks uncritically swallowed the Systemd Cabal's claims about how they were the first to do this, that, or the other.
I feel like you have very strong emotions about init systems that have nothing to do with the comment you're replying to.
> or did you not use Linux before 2010?
I've been using Linux regularly since 2002. I've never regularly used a Linux that used sysvinit.
In other words, over the past ~22 years (goddamn, where did the time go?) every Linux I've regularly used has had an init system that allows you to specify service dependencies to determine their start order.
> ...Debian...
Ah. That explains it. Debian's fine to build on top of but a bad distro to actually use. (Unless you really like using five-to-ten (and in some cases 25->35) year old software that's been superseded by much-improved versions.)
You should also consider that packages named "sysvinit" sometimes aren't actually what people think of when they hear "sysvinit": <https://wiki.gentoo.org/wiki/Sysvinit>
I've been using Linux regularly since 2002. I've never regularly used a Linux that used sysvinit.
In other words, over the past ~22 years (goddamn, where did the time go?) every Linux I've regularly used has had an init system that allows you to specify service dependencies to determine their start order.
> ...Debian...
Ah. That explains it. Debian's fine to build on top of but a bad distro to actually use. (Unless you really like using five-to-ten (and in some cases 25->35) year old software that's been superseded by much-improved versions.)
You should also consider that packages named "sysvinit" sometimes aren't actually what people think of when they hear "sysvinit": <https://wiki.gentoo.org/wiki/Sysvinit>
There were plenty of those that existed even before systemd. Systemd's adoption was not a result of providing the functionality that people want but rather was a result of providing functionality that a few important people wanted and promptly took hard dependencies on.
As long as Gnome requires bug-compatibility with systemd, nobody will rewrite it.
> One of the objections that many people do not understand, is that systemd adds complexity. Unnecessary complexity. Boats full, loads full, mountains full of complexity.
Complexity that would otherwise be distributed to a sea of ad-hoc shell scripts? systemd is a win
Complexity that would otherwise be distributed to a sea of ad-hoc shell scripts? systemd is a win
The init-scripts that predated systemd were actually pretty damn simple. So was init itself.
We removed tens of thousands of lines of code for fixes for those "simple" init scripts when migrating to systemd.
They are never "simple", there is always some fucking edge case, like for example we had Java apps writing its own PID few seconds after start. So any app that did start and immediately after status (like Pacemaker) threw errors.
Or how once in blue moon MySQL didn't start after reboot because it so happened that:
* the PID file from previous boot wasn't cleared * some other app ran with same PID as it was in file * Script did not care, script saw pid file existing and didn't start MySQL.
Both examples from pre-systemd CentOS
They are never "simple", there is always some fucking edge case, like for example we had Java apps writing its own PID few seconds after start. So any app that did start and immediately after status (like Pacemaker) threw errors.
Or how once in blue moon MySQL didn't start after reboot because it so happened that:
* the PID file from previous boot wasn't cleared * some other app ran with same PID as it was in file * Script did not care, script saw pid file existing and didn't start MySQL.
Both examples from pre-systemd CentOS
> so now security-critical daemons like openssh have additional dependencies like liblzma
Systemd itself seems security-critical to me. Would removing other dependencies on libsystemd really make a secure system where systemd was compromised through its library?
Systemd itself seems security-critical to me. Would removing other dependencies on libsystemd really make a secure system where systemd was compromised through its library?
1. systemd (at least the PID 1 part) does not talk to the network, so a remotely-accessible backdoor would need to be more complex (and thus more likely to be detected) than a backdoor that can be loaded into a listening daemon like openssh.
2. You can run Debian systems without systemd as PID 1, but you're still stuck with libsystemd because so many daemons now link with it.
2. You can run Debian systems without systemd as PID 1, but you're still stuck with libsystemd because so many daemons now link with it.
.. well, you can use a shim package as devuan did.
> systemd... does not talk to the network...
Socket activation and the NFS automounter appear to.
If I run "netstat -ap" I see pid 1 listening on enabled units.
Edit: tinysshd is specifically launched this way.
Edit2: there is also substantial criticism of xz on technical grounds.
https://www.nongnu.org/lzip/xz_inadequate.html
Socket activation and the NFS automounter appear to.
If I run "netstat -ap" I see pid 1 listening on enabled units.
Edit: tinysshd is specifically launched this way.
Edit2: there is also substantial criticism of xz on technical grounds.
https://www.nongnu.org/lzip/xz_inadequate.html
Uh. systemd documents the protocol at various places and the protocol is trivial: a single text datagram sent to am AF_UNIX socket whose path you get via the NOTIFY_SOCKET. That's trivial to implement for any one with some basic unix programming knowledge. And i tell pretty much anyone who wants to listen that they should just implement the proto on their own if thats rhe only reason for a libsystemd dep otherwise. In particular non-C environments really should do their own native impl and not botjer wrapping libsystemd just for this.
But let me stress two other things:
Libselinux pulls in liblzma too and gets linked into tons more programs than libsystemd. And will end up in sshd too (at the very least via libpam/pam_selinux). And most of the really big distros tend do support selinux at least to some level. Hence systemd or not, sshd remains vulnerable by this specific attack.
With that in mind libsystemd git dropped the dep on liblzma actually, all compressors are now dlopen deps and thus only pulled in when needed.
But let me stress two other things:
Libselinux pulls in liblzma too and gets linked into tons more programs than libsystemd. And will end up in sshd too (at the very least via libpam/pam_selinux). And most of the really big distros tend do support selinux at least to some level. Hence systemd or not, sshd remains vulnerable by this specific attack.
With that in mind libsystemd git dropped the dep on liblzma actually, all compressors are now dlopen deps and thus only pulled in when needed.
推迟库的加载往往只会增加分析难度，而不一定更安全。我想许多引用 `ldd` 的评论都错误地忘记了 `dlopen`。
(我真希望能有一种链接方式，使库并未被实际加载，但仍能显示在元数据中，这样你就能获得更少工作量带来的性能优势，但仍能轻松分析依赖 DAG）。
(我真希望能有一种链接方式，使库并未被实际加载，但仍能显示在元数据中，这样你就能获得更少工作量带来的性能优势，但仍能轻松分析依赖 DAG）。
It would make things more secure in this specific backdooring case, since sshd only calls a single function of libsystemd (sd_notify) and that one would not trigger the dlopen of liblzma, hence the specific path chosen by the backdoor would not work (unless libselinux fucks it up fter all, see other comments)
Dlopen has drawbacks but also major benefits. We decided the benefits relatively clearly outweigh the drawbacks, but of course people may disagree.
I have proposed a mechanism before, that would expose the list of libs we potentially load via dlopen into an ELF section or ELF note. This could be consumed by things such as packagae managers (for auto-dep generation) and ldd. However there was no interest in getting this landed from anyone else, so I dropped it.
Note that there are various cases where people use dlopen not on hardcoded lib names, but dynamically configured ones, where this would not help. I.e. things like glibc nss or pam or anything else plugin based. But in particular pam kinda matters since that tends to be loaded into almost any kind of security relavant software, including sshd.
Dlopen has drawbacks but also major benefits. We decided the benefits relatively clearly outweigh the drawbacks, but of course people may disagree.
I have proposed a mechanism before, that would expose the list of libs we potentially load via dlopen into an ELF section or ELF note. This could be consumed by things such as packagae managers (for auto-dep generation) and ldd. However there was no interest in getting this landed from anyone else, so I dropped it.
Note that there are various cases where people use dlopen not on hardcoded lib names, but dynamically configured ones, where this would not help. I.e. things like glibc nss or pam or anything else plugin based. But in particular pam kinda matters since that tends to be loaded into almost any kind of security relavant software, including sshd.
The plugin-based case can covered by the notion of multiple "entry points": every library that is intended to be `dlopen`ed is tagged with the name of the interface it provides, and every library that does such `dlopen`ing mentions the names of such interfaces rather than the names of libraries directly. Of course your `ldd` tool has to scan all the libraries on the system to know what might be loaded, but `ldconfig` already does that for libraries not in a private directory.
This might sound like a lot of work for a package-manager-less-language ecosystem at first, but if you consider "tag" as "exports symbol with name", it is in fact already how most C plugin systems work (a few use an incompatible per-library computed name though, or rely entirely on global constructors). So really only the loading programs need to be modified, just like the fixed-name `dlopen`.
This might sound like a lot of work for a package-manager-less-language ecosystem at first, but if you consider "tag" as "exports symbol with name", it is in fact already how most C plugin systems work (a few use an incompatible per-library computed name though, or rely entirely on global constructors). So really only the loading programs need to be modified, just like the fixed-name `dlopen`.
I note that Solaris had runtime-optional but compile-time linked shared libraries, I always wondered why Linux/glibc never adopted them.
> And i tell pretty much anyone who wants to listen that they should just implement the proto on their own if thats rhe only reason for a libsystemd dep otherwise.
That's what I think too. Do the relevant docs point this out too? Ages ago they didn't. I think we should try to avoid that people just google "implement systemd notify daemon" and end up on a page that says "link to libsystemd and call sd_notify()".
That's what I think too. Do the relevant docs point this out too? Ages ago they didn't. I think we should try to avoid that people just google "implement systemd notify daemon" and end up on a page that says "link to libsystemd and call sd_notify()".
> And i tell pretty much anyone who wants to listen that they should just implement the proto on their own if thats rhe only reason for a libsystemd dep otherwise
Could you point out where the man page (https://www.freedesktop.org/software/systemd/man/latest/sd_n...) says this?
Could you point out where the man page (https://www.freedesktop.org/software/systemd/man/latest/sd_n...) says this?
If you are talking about the stability of that interface: https://systemd.io/PORTABILITY_AND_STABILITY/
That site states "using libsystemd is a good choice"
:-D
:-D
The notes section has a brief description of the protocol and the different kinds of sockets involved.
And will end up in sshd too (at the very least via libpam/pam_selinux).
Inaccurate.
It's not pulled in on any sysvinit Debian system I run. It is on stable, oldstable, and oldoldstable systems via systemd.
Not systemd:
# ldd $(which sshd) linux-vdso.so.1 (0x00007ffcb57f5000)
# ldd $(which sshd) linux-vdso.so.1 (0x00007ffc4d3eb000)
# ldd $(which sshd) | grep liblz
Inaccurate.
It's not pulled in on any sysvinit Debian system I run. It is on stable, oldstable, and oldoldstable systems via systemd.
Not systemd:
# ldd $(which sshd) linux-vdso.so.1 (0x00007ffcb57f5000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fbad13c9000)
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007fbad13bd000)
libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007fbad138c000)
libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007fbad137a000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007fbad12d5000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fbad12a5000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007fbad1253000)
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007fbad1179000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007fbad1173000)
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007fbad0c00000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fbad1154000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbad0a1f000)
libnsl.so.2 => /lib/x86_64-linux-gnu/libnsl.so.2 (0x00007fbad1137000)
libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007fbad112f000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007fbad1123000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbad156a000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fbad1089000)
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007fbad09f2000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007fbad09e4000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007fbad09dd000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fbad09cc000)
libtirpc.so.3 => /lib/x86_64-linux-gnu/libtirpc.so.3 (0x00007fbad099e000)
# ldd $(which sshd) linux-vdso.so.1 (0x00007ffc4d3eb000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007feb8aa35000)
libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007feb8aa29000)
libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007feb8a9f8000)
libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007feb8a9e6000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007feb8a916000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007feb8a8e6000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007feb8a894000)
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007feb8a7ba000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007feb8a7b4000)
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007feb8a200000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007feb8a795000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007feb8a01f000)
libnsl.so.2 => /lib/x86_64-linux-gnu/libnsl.so.2 (0x00007feb8a778000)
libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007feb8a770000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007feb8a764000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007feb89ed8000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007feb8a735000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007feb89e1c000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007feb8a70d000)
/lib64/ld-linux-x86-64.so.2 (0x00007feb8abb5000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007feb89d82000)
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007feb8a6e0000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007feb8a6d2000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007feb8a6c9000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007feb8a6b8000)
libtirpc.so.3 => /lib/x86_64-linux-gnu/libtirpc.so.3 (0x00007feb8a68a000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007feb89d5a000)
# ldd $(which sshd) | grep liblz
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fd1e647a000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fd1e6398000)You also need to have sshd enabled to use PAM and your sshd pam stack should include pam_selinux. Then it will be dynamically loaded only when sshd starts a PAM session.
The correct thing to do would be to put different unrelated APIs into their own library, instead of everything into libsystemd0. This has always been one of my biggest issues with it. It makes it hard to replace just one API from that library, because on a binary distribution, only one package can provide it. And as a nice side effect, surprises like this one could then be avoided.
systemd developers have already rejected that approach, so I guess we will end up with lots of reimplementations, both in individual projects and third-party libsystemd-notify style libraries.
I see that different clients implemented in different languages will need different client-libraries and maintaining all that is not something, a core project is going to do but if using the raw protocol instead of the convenience of libsystemd is a (commonly ignored) recommendation which makes a lot of sense in terms of segmentation, providing at least one reference implementation would point all systemd users into the right direction.
Recommending that each client should just implement the (trivial) protocol access itself does not make so much sense to me.
IIRC sshd loads libpam only if specifically configured for it. So while it's not wrong, it's also a more edge case for the backdoor to work.
What? I don't get it? Isn't it on Debian if they modified the package to do something like this? Why would you blame systemd for maintainers doing something that upstream has never required or recommended?
[deleted]
It's unfortunate that the anti-systemd party lost the war... years ago. But I don't blame systemd, Lennart Pottering or the fanboys (though it would have been so much better if the guy never worked in open source or wasn't such a prolific programmer). I blame Debian and its community for succumbing to this assault on Unix philosophy (again, years ago).
Sometimes things evolve in ways that make us feel a little obsolete.
I've been learning NixOS for a few years now, and it would have been impossible without systemd. It's one heck of a learning curve, but when you get to the other side, you know something of great power and value. Certain kinds of complexity adds 'land' (eg. systemd) that can become 'real estate' (eg. NixOS), which in turn hopes to become 'land' for the next innovation, and so forth.
Whether this happens or not (whether it's the right kind of complexity) is really hard to assess up-front, and probably impossible without knowing the complex new technology in question very well. (And by then you have the bias of depending, in part, yourself on the success of the new tech, as you've committed significant resources to mastering it, so good luck on convincing skeptical newcomers!)
It's almost like a sort of event horizon -- once you know a complex new technology well enough to see whether or not it's useful, the conflict-of-interest makes your opinion unreliable to outsiders!
Nevertheless, the assessment process itself, while difficult to get right, is worth getting better at.
It's easy for impatience and the sensation of what I've taken to calling 'daunt' -- that intrinsic recoil that the mind has from absorbing a large amounts of information whose use case is not immediately relevant -- to dissuade one from exploring. But then, one never discovers new 'land', and one never builds new real estate!
[ Aside: This is why I'm a little skeptical of the current rebellion against frontend frameworks. Certainly some of them, like tailwind, are clearly adding fetters to an otherwise powerful browser stack. But others, like Svelte, and to some extent, even React, bring significant benefits.
The rebellion has this vibe like, well, users _should_ prefer more simply-built interfaces, and if they don't, well, they just have bad taste. What would be more humble would be to let the marketplace (e.g. consumers) decide what is preferable, and then build that. ]
I've been learning NixOS for a few years now, and it would have been impossible without systemd. It's one heck of a learning curve, but when you get to the other side, you know something of great power and value. Certain kinds of complexity adds 'land' (eg. systemd) that can become 'real estate' (eg. NixOS), which in turn hopes to become 'land' for the next innovation, and so forth.
Whether this happens or not (whether it's the right kind of complexity) is really hard to assess up-front, and probably impossible without knowing the complex new technology in question very well. (And by then you have the bias of depending, in part, yourself on the success of the new tech, as you've committed significant resources to mastering it, so good luck on convincing skeptical newcomers!)
It's almost like a sort of event horizon -- once you know a complex new technology well enough to see whether or not it's useful, the conflict-of-interest makes your opinion unreliable to outsiders!
Nevertheless, the assessment process itself, while difficult to get right, is worth getting better at.
It's easy for impatience and the sensation of what I've taken to calling 'daunt' -- that intrinsic recoil that the mind has from absorbing a large amounts of information whose use case is not immediately relevant -- to dissuade one from exploring. But then, one never discovers new 'land', and one never builds new real estate!
[ Aside: This is why I'm a little skeptical of the current rebellion against frontend frameworks. Certainly some of them, like tailwind, are clearly adding fetters to an otherwise powerful browser stack. But others, like Svelte, and to some extent, even React, bring significant benefits.
The rebellion has this vibe like, well, users _should_ prefer more simply-built interfaces, and if they don't, well, they just have bad taste. What would be more humble would be to let the marketplace (e.g. consumers) decide what is preferable, and then build that. ]
The notify protocol isn't much more complicated than that. From memory you send a string to a unix socket. I have written both systemd notify and listenfd in a few languages for little experiments and it is hard to imagine how the protocols could be simpler.
Looking at most popular projects these days they are a mass of dependencies and I think very few of them can be properly audited and verified by the projects that use them. Rust and Go might be more memory safe than C but look at the number of cargo or go modules in most projects. I have mostly stopped using node/npm on my systems.
Looking at most popular projects these days they are a mass of dependencies and I think very few of them can be properly audited and verified by the projects that use them. Rust and Go might be more memory safe than C but look at the number of cargo or go modules in most projects. I have mostly stopped using node/npm on my systems.
Not a programmer, but couldn't the distribution's sshd patches for systemd (and all other distro patches for privileged daemons) use static includes? Wouldn't that have only pulled in the simple client-side communication API? Would that have defeated this vector? Would it be doable?
Homebrew is currently shipping 5.6.1 (and was shipping 5.6.0 as well). Hopefully not affected on mac?
The issue is caused by patches to add integration with systemd, so no, this won't affect SSH on a Mac.
Just because macs don't use systemd, doesn't mean the backdoor won't work. The oss-sec post talks about liblzma having backdoors in crc32_resolve() and crc64_resolve() and that it has not been fully reversed. This could perhaps affect more than just sshd on x86-64 linux?
> Just because macs don't use systemd, doesn't mean the backdoor won't work.
Practically speaking it can't - For one the script injected into the build process tests that you're running on x86-64 linux, for another, the injected code is elf code, which wouldn't link on a mac. It also needs to manipulate dynamic linker datastructures, which would also not work the same on a mac.
> This could perhaps affect more than just sshd on x86-64 linux?
This however is true - /usr/sbin/sshd was the only argv[0] value that I found to "work", but it's possible there are others. "/usr/sbin/sshd" isn't a string directly visible in the injected code, so it's hard to tell.
Practically speaking it can't - For one the script injected into the build process tests that you're running on x86-64 linux, for another, the injected code is elf code, which wouldn't link on a mac. It also needs to manipulate dynamic linker datastructures, which would also not work the same on a mac.
> This could perhaps affect more than just sshd on x86-64 linux?
This however is true - /usr/sbin/sshd was the only argv[0] value that I found to "work", but it's possible there are others. "/usr/sbin/sshd" isn't a string directly visible in the injected code, so it's hard to tell.
The article explains numerous concurrent conditions that have to be met for the backdoor to even be activated (at build time, not runtime), which combined make it extremely unlikely this will affect SSH on macOS:
- linux
- x86-64
- building with gcc & the GNU linker
- part of a .deb or .rpm build
Add to that, as the article explains: openssh does not directly use liblzma, the only reason SSH is affected at all, is because some Linux Distros patch openssh to link it against systemd, which does depend on liblzma.
Could it affect things other than SSH on a Mac? Unlikely. The compromise was introduced in 5.6.0, but macOS Sonoma has 5.4.4 (from August last year).
- linux
- x86-64
- building with gcc & the GNU linker
- part of a .deb or .rpm build
Add to that, as the article explains: openssh does not directly use liblzma, the only reason SSH is affected at all, is because some Linux Distros patch openssh to link it against systemd, which does depend on liblzma.
Could it affect things other than SSH on a Mac? Unlikely. The compromise was introduced in 5.6.0, but macOS Sonoma has 5.4.4 (from August last year).
一旦维护者意识到，Homebrew 就恢复到 5.4.6。目前的了解是 macOS 不受影响，但这还不确定。
[1]：https://github.com/Homebrew/homebrew-core/pull/167512
[1]：https://github.com/Homebrew/homebrew-core/pull/167512
That's completely crazy, the backdoor is introduced through a very cryptic addition to the configure script. Just looking at the diff, it doesn't look malicious at all, it looks like build script gibberish.
Yeah, now imagine they succeeded and it didn't cause any performance issues...
Can we even be sure no such successful attempt has already been made?
Can we even be sure no such successful attempt has already been made?
Thanks to autoconf, we're now used to build scripts looking like gibberish. A perfect place to hide a backdoor.
This is my main take-away from this. We must stop using upstream configure and other "binary" scripts. Delete them all and run "autoreconf -fi" to recreate them. (Debian already does something like this I think.)
> We must stop using upstream configure and other "binary" scripts. Delete them all and run "autoreconf -fi" to recreate them.
I would go further than that: all files which are in a distributed tarball, but not on the corresponding git repository, should be treated as suspect.
Distributing these generated autotools files is a relic of times when it could not be expected that the target machine would have all the necessary development environment pieces. Nowadays, we should be able to assume that whoever wants to compile the code can also run autoconf/automake/etc to generate the build scripts from their sources.
And other than the autotools output, and perhaps a couple of other tarball build artifacts (like cargo simplifying the Cargo.toml file), there should be no difference between what is distributed and what is on the repository. I recall reading about some project to find the corresponding commit for all Rust crates and compare it with the published crate, though I can't find it right now; I don't know whether there's something similar being done for other ecosystems.
I would go further than that: all files which are in a distributed tarball, but not on the corresponding git repository, should be treated as suspect.
Distributing these generated autotools files is a relic of times when it could not be expected that the target machine would have all the necessary development environment pieces. Nowadays, we should be able to assume that whoever wants to compile the code can also run autoconf/automake/etc to generate the build scripts from their sources.
And other than the autotools output, and perhaps a couple of other tarball build artifacts (like cargo simplifying the Cargo.toml file), there should be no difference between what is distributed and what is on the repository. I recall reading about some project to find the corresponding commit for all Rust crates and compare it with the published crate, though I can't find it right now; I don't know whether there's something similar being done for other ecosystems.
One small problem with this is that autoconf is not backwards-compatible. There are projects out there that need older autoconf than distributions ship with.
There are, and they need to be fixed.
The test code generated by older autoconf is not going to be work correctly with newer GCC releases due to the deprecation of implicit int and implicit function declarations (see https://fedoraproject.org/wiki/Changes/PortingToModernC), so these projects already have to be updated to work with newer autoconf.
Typing `./configure` wont work but something like `./configure CFLAGS="-Wno-error=implicit-function-declaration"` (or whatever flag) might work (IIRC it is possible to pass flags to the compiler invocations used for checking out the existence of features) without needing to recreate it.
Also chances are you can shove that flag in some old `configure.in` and have it work with an old autoconf for years before it having to update it :-P.
Also chances are you can shove that flag in some old `configure.in` and have it work with an old autoconf for years before it having to update it :-P.
Easily solved with Docker.
Yes, it sucks to add yet another wrapper but that’s what you get for choosing non backwards compatible tools in the first place. In combination with projects that don’t keep up to date on supporting later versions.
Yes, it sucks to add yet another wrapper but that’s what you get for choosing non backwards compatible tools in the first place. In combination with projects that don’t keep up to date on supporting later versions.
A yes, let's replace "binary" blobs in release archives with even bigger blobs of mistery goo.
Why do we distribute tarballs at all? A git hash should be all thats needed...
> Why do we distribute tarballs at all? A git hash should be all thats needed...
A git hash means nothing without the repository it came from, so you'd need to distribute both. A tarball is a self-contained artifact. If I store a tarball in a CD-ROM, and look at it twenty years later, it will still have the same complete code; if I store a git hash in a CD-ROM, without storing a copy of the repository together with it, twenty years later there's a good chance that the repository is no longer available.
We could distribute the git hash together with a shallow copy of the repository (we don't actually need the history as long as the commit with its trees and blobs is there), but that's just reinventing a tarball with more steps.
(Setting aside that currently git hashes use SHA-1, which is not considered strong enough.)
A git hash means nothing without the repository it came from, so you'd need to distribute both. A tarball is a self-contained artifact. If I store a tarball in a CD-ROM, and look at it twenty years later, it will still have the same complete code; if I store a git hash in a CD-ROM, without storing a copy of the repository together with it, twenty years later there's a good chance that the repository is no longer available.
We could distribute the git hash together with a shallow copy of the repository (we don't actually need the history as long as the commit with its trees and blobs is there), but that's just reinventing a tarball with more steps.
(Setting aside that currently git hashes use SHA-1, which is not considered strong enough.)
except it isn't reinventing the tarball, because the git hash forces verification that every single file in the repo matches that in the release.
And git even has support for "compressed git repo in a file" or "shallow git repo in a file" or even "diffs from the last release, compressed in a file". They're called "git bundle"'s.
They're literally perfect for software distribution and archiving.
And git even has support for "compressed git repo in a file" or "shallow git repo in a file" or even "diffs from the last release, compressed in a file". They're called "git bundle"'s.
They're literally perfect for software distribution and archiving.
People don't know how to use git hashes, and it's not been "done". Whereas downloading tarballs and verifying hashes of the tarball has been "good enough" because the real thing it's been detecting is communication faults, not supply chain attacks.
People also like version numbers like 2.5.1 but that's not a hash, and you can only indirectly make it a hash.
People also like version numbers like 2.5.1 but that's not a hash, and you can only indirectly make it a hash.
> I would go further than that: all files which are in a distributed tarball, but not on the corresponding git repository, should be treated as suspect.
This and the automated A/B / diff to check the tarball against the repo, flag if mismatched.
This and the automated A/B / diff to check the tarball against the repo, flag if mismatched.
The backdoor is in an .m4 file that gets parsed by autoconf to generate the configure script. Running autoconf yourself won't save you.
That's not entirely true. autoreconf will regenerate m4/build-to-host.m4 but only if you delete it first.
看起来这就是 archlinux 的解决方案，直接从 github 标签拉取并运行 autogen：https://gitlab.archlinux.org/archlinux/packaging/packages/xz...
it's shocking how many packages on distros are just one random tarball from the internet with lipstick
I don't think it would help much. I work on machine learning frameworks. A lot of them(and math libraries) rely on just in time compilation. None of us has the time or expertise to inspect JIT-ed assembly code. Not even mentioning that much of the code deliberately read/write out of bound, which is not an issue if you always add some extra bytes at the end of each buffer, which could make most memory sanitizer tools useless. When you run their unit tests, you run the JIT code, then a lot of things could happen. Maybe we should ask all packaging systems splitting their build into compile and test two stages, to ensure that a testing code would not impact the binaries that are going to be published.
I would rather to read and analysis the generated code instead of the code that generates it.
Maybe it's time to dramatically simplify autoconf?
How long do we need to (pretend to) keep compatibility with pre-ANSI C compilers, broken shells on exotic retro-unixes, and running scripts that check how many bits are in a byte?
How long do we need to (pretend to) keep compatibility with pre-ANSI C compilers, broken shells on exotic retro-unixes, and running scripts that check how many bits are in a byte?
Autoconf is m4 macros and Bourne shell. Most mainstream programming languages have a packaging system that lets you invoke a shell script. This attack is a reminder to keep your shell scripts clean. Don't treat them as an afterthought.
我想知道是否有没有办法添加一个自动标记系统，A/B / `diff` 根据存储库的文件检查 tarball 内容并警告是否存在不匹配？这将是在 GitHub 的末端，这样就会有这种自动完整性测试和随后的警告？只是一个想法，因为像这样的受污染的 tarball 可能完全是（并成为）威胁向量，无论存储库如何。
Not just autoconf. Build systems in general are a bad abstraction, which leads to lots and lots of code to try to make them do what you want. It's a sad reality of the mismatch between a prodecural task (compile files X, Y, and Z into binary A) and what we want (compile some random subset of files X, Y, and Z, doing an arbitrary number of other tasks first, into binary B).
For fun, you can read the responses to my musing that maybe build systems aren't needed: https://news.ycombinator.com/item?id=35474996 (People can't imagine programming without a build system - it's sad)
For fun, you can read the responses to my musing that maybe build systems aren't needed: https://news.ycombinator.com/item?id=35474996 (People can't imagine programming without a build system - it's sad)
It looks like an earlier commit with a binary blob "test data" contained the bulk of the backdoor, then the configure script enabled it, and then later commits patched up valgrind errors caused by the backdoor. See the commit links in the "Compromised Repository" section.
Also, seems like the same user who made these changes are still submitting changes to various repositories as of a few days ago. Maybe these projects need to temporarily stop accepting commits until further review is done?
Also, seems like the same user who made these changes are still submitting changes to various repositories as of a few days ago. Maybe these projects need to temporarily stop accepting commits until further review is done?
> "Given the activity over several weeks, the committer is either directly
involved or there was some quite severe compromise of their
system. Unfortunately the latter looks like the less likely explanation, given
they communicated on various lists about the "fixes" mentioned above."
Crazy indeed.
Crazy indeed.
问题的很大一部分是围绕 git 的所有工具（如默认的 github UI），它们隐藏了二进制文件（如这些伪“测试”文件）的差异。使它们成为隐藏漏洞数据的理想场所，因为相对较少的人会费心手动打开十六进制编辑器。
How many people read autoconf scripts, though? I think those filters are symptom of the larger problem that many popular C/C++ codebases have these gigantic build files which even experts try to avoid dealing with. I know why we have them but it does seem like something which might be worth reconsidering now that the tool chain is considerably more stable than it was in the 80s and 90s.
How many people read build.rs files of all the transitive dependencies of a moderately large Rust project?
Autoconf is bad in this respect but it's not like the alternatives are better (maybe Bazel).
Autoconf is bad in this respect but it's not like the alternatives are better (maybe Bazel).
Bazel has its problems but the readability is definitely better. And bazel BUILD files are quite constrained in what it can do.
The alternatives are _better_ but still not great. build.rs is much easier to read and audit, for example, but it’s definitely still the case that people probably skim past it. I know that the Rust community has been working on things like build sandboxing and I’d expect efforts to be a lot easier there than in a mess of m4/sh where everyone is afraid to break 4 decades of prior usage.
build.rs is easier to read, but it's the tip of the iceberg when it comes to auditing.
If I were to sneak in some underhanded code, I'd do it through either a dependency that is used by build.rs (not unlike what was done for xz) or a crate purporting to implement a very useful procedural macro...
If I were to sneak in some underhanded code, I'd do it through either a dependency that is used by build.rs (not unlike what was done for xz) or a crate purporting to implement a very useful procedural macro...
I mean, autoconf is basically a set of template programs for snffing out whether a system has X symbol available to the linker. Any replacement for it would end up morphing into it over time.
Some things are just that complex.
Some things are just that complex.
We have much better tools now and much simpler support matrices, though. When this stuff was created, you had more processor architectures, compilers, operating systems, etc. and they were all much worse in terms of features and compatibility. Any C codebase in the 90s was half #ifdef blocks with comments like “DGUX lies about supporting X” or “SCO implemented Y but without option Z so we use Q instead”.
That's the essence of programming in C though...
You figure out what the hardware designers actually did, and get the program written to accommodate it.
You figure out what the hardware designers actually did, and get the program written to accommodate it.
我不明白显示二进制差异有什么帮助。无论如何，99.99999% 的人都会直接滚动过去。
即使在二进制中你也可以看到模式。并不是说显示二进制差异是完美的（但它比什么都不显示要好），但我知道即使我缓慢的哺乳动物大脑也可以发现各种二进制编码格式中明显的人类可读字符。如果我连续看到一些没有意义的东西，我为什么不戳它呢？
What should I look for? The evil bit set?
当然，要查看的人就是点击“显示差异”的同一个人
This particular file was described as an archive file with corrupted data somewhere in the middle. Assuming you wanted to scroll that far through a hexdump of it, there could be pretty much any data in there without being suspicious.
testdata should not be on the same machine as the build is done. testdata (and tests generally) aren't as well audited, and therefore shouldn't be allowed to leak into the finished product.
Sure - you want to test stuff, but that can be done with a special "test build" in it's own VM.
Sure - you want to test stuff, but that can be done with a special "test build" in it's own VM.
That could easily double build cost. Most open-source package repositories are not exactly in a position to splurge on their build infra.
在 Bazel 构建系统中，您可以将测试数据 blob 标记为 testonly=1。然后构建系统保证该 blob 只能在测试中使用。
这一事件表明，早该消灭 autoconf goop 了。
这一事件表明，早该消灭 autoconf goop 了。
00011900: 0000 4883 f804 7416 b85f 5f5f 5f33 010f ..H...t..____3.. │
00011910: b651 0483 f25a 09c2 0f84 5903 0000 488d .Q...Z....Y...H. │
00011920: 7c24 40e8 5875 0000 488b 4c24 4848 3b4c |[email protected]$HH;L │
00011930: 2440 7516 4885 c074 114d 85ff 0f84 3202 [email protected]. │
00011940: 0000 498b 0ee9 2c02 0000 b9fe ffff ff45 ..I...,........E │
00011950: 31f6 4885 db74 0289 0b48 8bbc 2470 1300 1.H..t...H..$p.. │
00011960: 0048 85ff 0f85 c200 0000 0f57 c00f 2945 .H.........W..)E │
00011970: 0048 89ac 2470 1300 0048 8bbc 2410 0300 .H..$p...H..$... │
00011980: 0048 8d84 2428 0300 0048 39c7 7405 e8ad .H..$(...H9.t... │
00011990: e6ff ff48 8bbc 24d8 0200 0048 8d84 24f0 ...H..$....H..$. │
000119a0: 0200 0048 39c7 7405 e893 e6ff ff48 8bbc ...H9.t......H.. │
000119b0: 2480 0200 0048 8d84 2498 0200 0048 39c7 $....H..$....H9. │
000119c0: 7405 e879 e6ff ff48 8bbc 2468 0100 004c t..y...H..$h...L │
Please tell me what this code does, Sheldon
你是对的 - 这两个漏洞利用文件经过 lzma 压缩，然后使用“tr”故意损坏，因此十六进制转储不会立即向审阅者显示任何可疑内容。
我错了！
我错了！
Is this lzma compressed? Hard to tell because of the lack of formatting, but this looks like amd64 shellcode to me.
But that's not really important to the point - I'm not looking at a diff of every committed favicon.ico or ttf font or a binary test file to make sure it doesn't contain a shellcode.
But that's not really important to the point - I'm not looking at a diff of every committed favicon.ico or ttf font or a binary test file to make sure it doesn't contain a shellcode.
it's just an arbitrary section of libcxx-18.1.1/lib/libc++abi.so.1.0
in this case the backdoor was hidden in a nesting doll of compressed data manipulated with head/tail and tr, even replacing byte ranges inbetween. Would've been impossible to find if you were just looking at the test fixtures.
The use of "eval" stands out, or at least it should stand out – but there are two more instances of it in the same script, which presumably are not used maliciously.
A while back there was a discussion[0] of an arbitrary code execution vulnerability in exiftool which was also the result of "eval".
Avoiding casual use of this overpowered footgun might make it easier to spot malicious backdoors. Usually there is a better way to do it in almost all cases where people feel the need to reach for "eval", unless the feature you're implementing really is "take a piece of arbitrary code from the user and execute it".
[0] https://news.ycombinator.com/item?id=39154825
A while back there was a discussion[0] of an arbitrary code execution vulnerability in exiftool which was also the result of "eval".
Avoiding casual use of this overpowered footgun might make it easier to spot malicious backdoors. Usually there is a better way to do it in almost all cases where people feel the need to reach for "eval", unless the feature you're implementing really is "take a piece of arbitrary code from the user and execute it".
[0] https://news.ycombinator.com/item?id=39154825
Unfortunately eval in a shell script has an effect on the semantics but is not necessary to do some kind of parsing of the contents of a variable, unlike Python or Perl or JavaScript. A
$goo
eval "$goo"
eval in autoconf macros is nothing unusual.
In (pre-backdoor) xz 5.4.5:
In (pre-backdoor) xz 5.4.5:
$ grep -wl eval m4/*
m4/gettext.m4
m4/lib-link.m4
m4/lib-prefix.m4
m4/libtool.m4> Usually there is a better way to do it in almost all cases where people feel the need to reach for "eval"
unfortunately thats just standard in configure scripts, for example from python:
``` grep eval Python-3.12.2/configure | wc -l 165 ```
and its 32,958 lines of code, plenty of binary fixtures as well in the tarball to hide stuff.
who knows, but I have feeling us finding the backdoor in this case was more of a happy accident.
unfortunately thats just standard in configure scripts, for example from python:
``` grep eval Python-3.12.2/configure | wc -l 165 ```
and its 32,958 lines of code, plenty of binary fixtures as well in the tarball to hide stuff.
who knows, but I have feeling us finding the backdoor in this case was more of a happy accident.
Summary: "The upstream xz repository and the xz tarballs have been backdoored."
It is known to be in version 5.6.0 and 5.6.1, and the obfuscated code is found in the test directory.
It is known to be in version 5.6.0 and 5.6.1, and the obfuscated code is found in the test directory.
This potentially could be a full automated rootkit type breach right? Great - is any system with 5.6.1 possibly vulnerable?
Also super weird a contributor thought they could slip this in and not have it be noticed at some point. It may point to burning that person (aka, they go to jail) for whatever they achieved with this. (And whoever they are…)
Also super weird a contributor thought they could slip this in and not have it be noticed at some point. It may point to burning that person (aka, they go to jail) for whatever they achieved with this. (And whoever they are…)
NixOS/Pkgs 23.11 unaffected, unstable contains backdoored implementations (5.6.0, 5.6.1) but their OpenSSH sshd does not seem to link against systemd/liblzma, and the backdoor doesn't get configured in (only happens on .deb/.rpm systems).
It may not have really mattered much for NixOS:
> b) argv[0] needs to be /usr/sbin/sshd
For once, the lack of FHS interoperability is a benefit, if only on accident.
> b) argv[0] needs to be /usr/sbin/sshd
For once, the lack of FHS interoperability is a benefit, if only on accident.
Right, but in this case it's not even compiled it, which is arguably better than compiled in but assumed dormant :) (at least until someone actually does a full analysis of the payload).
Note that NixOS has a unique advantage in that `dlopen` is easier to analyze, but you do have to check for it. A lot of people are looking only at `ldd` and missing that they can be vulnerable at runtime.
That's one of the advantages of NixOS - viruses and mass hacks have lesser chance to function due to how different this OS is. Until it gets more popular, of course.
That's just security by obscurity, not something I'd consider a good security measure.
Not affected by the latest CVE, but the author had unrestricted access to xz for 2 years, so I would say it is affected until the other contributions are proven safe (never gonna happen) or it reverts to pre-adversarial actor version.
> Red Hat assigned this issue CVE-2024-3094.
Does that mean this affects RHEL and Fedora?
Does that mean this affects RHEL and Fedora?
RHEL no, Fedora 41 and Rawhide yes.
https://www.redhat.com/en/blog/urgent-security-alert-fedora-...
https://lists.debian.org/debian-security-announce/2024/msg00...
https://www.redhat.com/en/blog/urgent-security-alert-fedora-...
https://lists.debian.org/debian-security-announce/2024/msg00...
Note that Fedora 40 isn't even released yet, it's in beta, Fedora 41 / rawhide is basically a development branch used only by a small number of people.
A small number of people with likely professional involvement in the Fedora project and possibly RHEL.
A supply chain attack serve as the basis for another supply chain attack.
A supply chain attack serve as the basis for another supply chain attack.
RHEL won't get this bug for 2 years =)
i knew there was an advantage to being 8-10 years out of date at all times...
and when they do port finally backport this bug in 2026, they will probably implement the systemd integration with openssl (pbthththt...) via 600 patch files in some nonstandard divergent manner that thwarts the payload anyhow. see? i knew they were super duper secure.
and when they do port finally backport this bug in 2026, they will probably implement the systemd integration with openssl (pbthththt...) via 600 patch files in some nonstandard divergent manner that thwarts the payload anyhow. see? i knew they were super duper secure.
Red Hat helps to do the job of making sure OSS has CVEs so there's common vernacular for the problem.
So many security companies publishing daily generic blog posts about "serious supply chain compromises" in various distros on packages with 0 downloads, and yet it takes a developer debugging performance issues to find an actual compromise.
I worked in the software supply chain field and cannot resist feeling the entire point of that industry is to make companies pay for a security certificate so you can shift the blame onto someone else when things go wrong.
I worked in the software supply chain field and cannot resist feeling the entire point of that industry is to make companies pay for a security certificate so you can shift the blame onto someone else when things go wrong.
> cannot resist feeling the entire point of that industry is to make companies pay for a security certificate so you can shift the blame onto someone else when things go wrong.
That's the entire point. You did everything you could by getting someone else look at it and saying it's fine.
That's the entire point. You did everything you could by getting someone else look at it and saying it's fine.
This needs a Rust joke. You know, the problem with the whole certification charade is it slows down jobs and prevents __actual_problems getting evaluated. But is it safe?
> the entire point of that industry is to make companies pay for a security certificate so you can shift the blame onto someone else when things go wrong.
That is actually a major point of a lot of corporate security measures (shifting risk)
That is actually a major point of a lot of corporate security measures (shifting risk)
And that's a good thing.
If you installed xz on macOS using brew, then you have
xz (XZ Utils) 5.6.1
liblzma 5.6.1
brew upgrade xzIt's been reverted now: https://github.com/Homebrew/homebrew-core/blob/9a0603b474804...
Yeah it was when I posted the comment too. That's why you could type brew upgrade xz and it went back to 5.4.6 I guess? But it might have been around that time, cutting it fine, not out for everybody. I don't know. Comment race condition haha! :)
同样，如果您使用 MacPorts，请确保同步并升级 xz（如果已安装）。
5.6.1 可用了几天，大约 20 分钟前刚刚回滚：https://github.com/macports/macports-ports/commit/a1388aee09...
5.6.1 可用了几天，大约 20 分钟前刚刚回滚：https://github.com/macports/macports-ports/commit/a1388aee09...
Thank you for this tip. `brew upgrade xz` worked.
I was going to uninstall but it's used by so many things…
I was going to uninstall but it's used by so many things…
brew uninstall xz
Error: Refusing to uninstall /opt/homebrew/Cellar/xz/5.6.1
because it is required by aom, composer, curl, ffmpeg, gcc, gd, ghostscript, glib, google-cloud-sdk, grc, harfbuzz, httpie, img2pdf, jbig2enc, jpeg-xl, leptonica, libarchive, libavif, libheif, libraw, libtiff, libzip, little-cms2, numpy, ocrmypdf, openblas, openjpeg, openvino, php, pillow, pipx, pngquant, poppler, [email protected], [email protected], rsync, tesseract, tesseract-lang, unpaper, webp, wp-cli, yt-dlp and zstd, which are currently installed.You're welcome!
Thats basically the whole point actually... A company pays for insurance for the business. The insurance company says sure we will insure you, but you need to go through audits A B and C, and you need certifications X and Y to be insured by us. Those audits are often industry dependent, mostly for topics like HIPAA, PCI, SOC, etc.
Insurance company hears about supply chain attacks. Declares that insured must have supply chain validation. Company goes and gets a shiny cert.
Now when things go wrong, the company can point to the cert and go "it wasnt us, see we have the cert you told us to get and its up to date". And the company gets to wash their hands of liability (most of the time).
Insurance company hears about supply chain attacks. Declares that insured must have supply chain validation. Company goes and gets a shiny cert.
Now when things go wrong, the company can point to the cert and go "it wasnt us, see we have the cert you told us to get and its up to date". And the company gets to wash their hands of liability (most of the time).
> And the company gets to wash their hands of liability (most of the time).
Certification theater.
It's completely performative.
Certification theater.
It's completely performative.
What you describe is a normal process in order to minimise damage from attacks. The damage of hacking is ultimately property damage. The procedures you've described allow you to minimise it.
And that's a good thing.
And that's a good thing.
[deleted]
That's the entire point of certification, and any certification at all. Certification does not guarantee performance. Actually, I would always cast a suspect glance to anyone who is FOCUSED on getting certification after certification without any side project.
Looks like Arch Linux shipped both compromised versions - and 5.6.1-2 is out to hopefully resolve it.
I upgraded Arch Linux on my server a few hours ago. Arch Linux does not fetch one of the compromised tarballs but builds from source and sshd does not link against liblzma on Arch.
[root@archlinux ~]# pacman -Qi xz | head -n2
Name : xz
Version : 5.6.1-2
[root@archlinux ~]# pacman -Qi openssh | head -n2
Name : openssh
Version : 9.7p1-1
[root@archlinux ~]# ldd $(which sshd) | grep liblzma
[root@archlinux ~]#
5.6.1-1 was built from what I understand to be one of the affected tarballs. This was patched in 5.6.1-2: https://gitlab.archlinux.org/archlinux/packaging/packages/xz...
I agree on the sshd linking part.
I agree on the sshd linking part.
Interesting, they just switched from tarballs to source 19 hours ago. It seems to me that Frederik Schwan had prior knowledge of the security issue, or it is just a rare coincidence.
Distributions were notified under embargo.
On arch, `ldd $(which sshd)` doesn't list lzma or xz, so I think it's unaffected? Obviously still not great to be shipping malicious code that just happens to not trigger.
My Arch setup is the same, they must not patch openssh.
Deleted per below
This is what the `detect_sh.bin` attached to the email does. I can only assume that the pesron who reported the vulnerability checked that this succeeds in detecting it.
Note that I'm not looking for the vulnerable symbols, I'm looking for the library that does the patching in the first place.
Note that I'm not looking for the vulnerable symbols, I'm looking for the library that does the patching in the first place.
Deleted, thanks.
5.6.1-2 is not an attempted fix, it's just some tweaks to Arch's own build script to improve reproducibility. Arch's build script ultimately delegates to the compromised build script unfortunately, but it also appears the payload itself is specifically targeting deb/RPM based distros, so a narrow miss for Arch here.
(EDIT: as others have pointed out, part of the exploit is in the artifact from libxz, which Arch is now avoiding by switching to building from a git checkout)
(EDIT: as others have pointed out, part of the exploit is in the artifact from libxz, which Arch is now avoiding by switching to building from a git checkout)
Are you sure about that? The diff moves away from using the compromised tarballs to the not-compromised (by this) git source. The comment message says it's about reproducibility, but especially combined with the timing it looks to me like that was just to avoid breaking an embargo.
So, you suggest that Frederik Schwan had prior knowledge of the security issues but hid the real purpose of the commit under "improve reproducibility"?
Yes.
I've never had to do it myself but I believe that's common practice with embargos on security vulnerabilities.
I've never had to do it myself but I believe that's common practice with embargos on security vulnerabilities.
It can lead to amusing cases where the intentional vuln comes in "to improve x" and the quiet fix comes in "to improve x".
And, If you break the embargo too many times then you just find out with the rest of us and that's not a great way to run a distro. I believe openbsd is or was in that position around the time of the intel speculative execution bugs.
xz was masked in the Gentoo repositories earlier today with the stated reason of "Investigating serious bug". No mention of security. It's pretty likely.
5.6.1 is masked specifically.
Also, https://mastodon.social/@[email protected]/1121802382... from a Gentoo dev mentions that Gentoo doesn't use the patch that results in sshd getting linked against liblzma.
As far as I know this is not an official communication channel so don't take it as such.
Also, https://mastodon.social/@[email protected]/1121802382... from a Gentoo dev mentions that Gentoo doesn't use the patch that results in sshd getting linked against liblzma.
As far as I know this is not an official communication channel so don't take it as such.
This is very likely the case. Arch maintainers do get early information on CVEs just like any other major distro.
But with pacman/makepkg 6.1 (which recently released) git sources can also now be check summed IIRC which is a funny coincidence.
But with pacman/makepkg 6.1 (which recently released) git sources can also now be check summed IIRC which is a funny coincidence.
The writeup indicates that the backdoor only gets applied when building for rpm or deb, so Arch probably would have been okay either way? Same with Nix, Homebrew, etc.
The project has made an official post on the subject
https://archlinux.org/news/the-xz-package-has-been-backdoore...
https://archlinux.org/news/the-xz-package-has-been-backdoore...
The terrifying part is that this was primarily found because the backdoor was poorly made and causing performance problems.
Makes you wonder what more competent actors can do.
Makes you wonder what more competent actors can do.
I've analysed the backdoor myself and it's very sophisticated, not poorly made at all. The performance problem is surprising in this context, but I think next time they won't make that mistake.
Do you have a writeup or any details as to what it does? The logical thing based on this post is that it hooks the SSH key verification mechanism to silently allow some attacker-controlled keys but I wonder if there's more to it?
I was starting one, but the openwall message linked here is far more detailed and gets much further than I did. It's fiendishly difficult to follow the exploit.
sshd 以 root 权限启动，然后继续，总而言之：[1]
1. 解析命令行参数
2. 设置日志记录
3.加载配置文件
4. 将密钥/证书加载到内存中（特别是包括私钥）
5. 监听套接字/端口上的传入连接
6. 生成一个权限较低的子进程（在 Linux 上，使用 seccomp 过滤器 [2]）来响应每个传入的连接请求
该后门在调用 sshd 的主函数之前以 0 号执行，用受损的函数覆盖内部 sshd 函数。关于后门可以实现的一些想法：
1. 与用户（包括未经身份验证的用户）握手时泄露服务器私钥，导致密钥被被动窃取
2. 接受后门密钥作为合法凭证
3. 破坏随机数生成以禁用完美前向保密
4. 在启动时使用 sshd 可用的“root”权限在主机（由恶意用户远程提供）上执行代码。在大多数 Linux 发行版上，systemd-analyze security sshd.service 的得分为 9.6/10（10 是最差的）。[3]基本上没有使用沙箱，因为假设您希望使用 sshd 以 root 身份登录（或 sudo/su 登录到 root），因此不希望限制远程 shell 可以调用的文件系统路径和系统调用。
同一攻击者还在 Linux 内核构建脚本中添加了代码，导致在 Linux 内核构建过程中执行 xz（此时 xz 已编译后门），其中 xz 压缩用于生成的映像。使用这种方法，攻击者可以有选择地选择修改某些（或全部）Linux 内核版本来执行一些非常讨厌的事情：
1. 泄露 Wireguard 密钥，使其被被动拦截。
2. 损害随机数生成，这意味着可以以最小的熵生成密钥（参见几年前的 Debian 证书问题）。
3. 将 LUKS 主密钥（dm-crypt 用于实际解密磁盘的密钥）以可检索格式写入磁盘。
4、将远程根代码执行漏洞引入基本网络功能，例如 TCP/IP 代码路径。
[1]“主要”功能：https://anongit.mindrot.org/openssh.git/tree/sshd.c
[2] https://anongit.mindrot.org/openssh.git/tree/sandbox-seccomp...
[3] https://github.com/gentoo/gentoo/blob/HEAD/net-misc/openssh/...
1. 解析命令行参数
2. 设置日志记录
3.加载配置文件
4. 将密钥/证书加载到内存中（特别是包括私钥）
5. 监听套接字/端口上的传入连接
6. 生成一个权限较低的子进程（在 Linux 上，使用 seccomp 过滤器 [2]）来响应每个传入的连接请求
该后门在调用 sshd 的主函数之前以 0 号执行，用受损的函数覆盖内部 sshd 函数。关于后门可以实现的一些想法：
1. 与用户（包括未经身份验证的用户）握手时泄露服务器私钥，导致密钥被被动窃取
2. 接受后门密钥作为合法凭证
3. 破坏随机数生成以禁用完美前向保密
4. 在启动时使用 sshd 可用的“root”权限在主机（由恶意用户远程提供）上执行代码。在大多数 Linux 发行版上，systemd-analyze security sshd.service 的得分为 9.6/10（10 是最差的）。[3]基本上没有使用沙箱，因为假设您希望使用 sshd 以 root 身份登录（或 sudo/su 登录到 root），因此不希望限制远程 shell 可以调用的文件系统路径和系统调用。
同一攻击者还在 Linux 内核构建脚本中添加了代码，导致在 Linux 内核构建过程中执行 xz（此时 xz 已编译后门），其中 xz 压缩用于生成的映像。使用这种方法，攻击者可以有选择地选择修改某些（或全部）Linux 内核版本来执行一些非常讨厌的事情：
1. 泄露 Wireguard 密钥，使其被被动拦截。
2. 损害随机数生成，这意味着可以以最小的熵生成密钥（参见几年前的 Debian 证书问题）。
3. 将 LUKS 主密钥（dm-crypt 用于实际解密磁盘的密钥）以可检索格式写入磁盘。
4、将远程根代码执行漏洞引入基本网络功能，例如 TCP/IP 代码路径。
[1]“主要”功能：https://anongit.mindrot.org/openssh.git/tree/sshd.c
[2] https://anongit.mindrot.org/openssh.git/tree/sandbox-seccomp...
[3] https://github.com/gentoo/gentoo/blob/HEAD/net-misc/openssh/...
[deleted]
I guess it seems like the operational parts are a bit poorly done. Valgrind issues, adding a new version with symbols removed, the aforementioned performance issues. Like i would assume the type of person who would do this sort of thing, over a 2 year period no less, would test extensively and be sure all their i's are dotted. Its all kind of surprising given how audacious the attack is.
There are so many variations of Linux/FreeBSD and weird setups and environments that it's almost guaranteed that you'll hit a snag somewhere if you do any major modification like inserting a backdoor.
It's hard enough to get code to work correctly; getting it to be also doing something else is even harder.
The way they went around it, however, was brilliant. Completely reduce the variables to directly target whatever it is you're attacking. Reminds me of stuxnet somewhat.
The way they went around it, however, was brilliant. Completely reduce the variables to directly target whatever it is you're attacking. Reminds me of stuxnet somewhat.
Note that in this case the backdoor was only inserted in some tarballs and enabled itself only when building deb/rpm packages for x86-64 linux and with gcc and the gnu linker. This should already filter out the most exotic setups and makes it harder to reproduce.
the point we got, when even exploits have to rely on user agent string sniffing.
reminds me of the gnu hack discovered because one of the savannah build hosts was some odd architecture the exploit wasn't expecting
reminds me of the gnu hack discovered because one of the savannah build hosts was some odd architecture the exploit wasn't expecting
But they almost got away with it. We could have found ourselves 5 years later with this code in all stable distribution versions, IoT devices etc.
Also, we only catch the ones that we ... catch. The ones that do everything perfectly, unless they come out and confess eventually, we don't get to "praise" them for their impeccable work.
Also, we only catch the ones that we ... catch. The ones that do everything perfectly, unless they come out and confess eventually, we don't get to "praise" them for their impeccable work.
s/can do/have done/
So many malicious actors have been caught because they accidentally created a mild annoyance for someone that went on to bird-dog the problem.
Case in point: https://news.ycombinator.com/item?id=39843930
Which is why a really good backdoor is a one line logic bug somewhere which is fiendishly difficult to trigger.
http://underhanded-c.org if people want examples of what could (and probably, somewhere, IS) being done.
[deleted]
Sure, however the problem that software is really hard also impacts bad actors. So it's probably at least as hard to write that one line logic bug and have it do exactly what you intended as to write equivalent real code that works precisely as intended.
Like the 2003 Linux kernel attempt https://lwn.net/Articles/57135/
Unrelated: as a dog/pointer lover i really like the term "to bird-dog the problem". Never heard of it (iam from germany though)
I’m from the U.S. and have never heard it either, and don’t understand what it means.
It's somewhat regional, and it means to hunt down the target at the expense of everything else, as a dedicated hunting dog might.
Pointing dogs (bird dogs) are made to point in the direction where they have perceived game. Good dogs are then not distracted by anything and stand there motionless, sometimes so far that they have to be carried away because they cannot turn away themselves.
You must mean, "Makes you wonder what more competent actors are doing"
Very annoying - the apparent author of the backdoor was in communication with me over several weeks trying to get xz 5.6.x added to Fedora 40 & 41 because of it's "great new features". We even worked with him to fix the valgrind issue (which it turns out now was caused by the backdoor he had added). We had to race last night to fix the problem after an inadvertent break of the embargo.
He has been part of the xz project for 2 years, adding all sorts of binary test files, and to be honest with this level of sophistication I would be suspicious of even older versions of xz until proven otherwise.
He has been part of the xz project for 2 years, adding all sorts of binary test files, and to be honest with this level of sophistication I would be suspicious of even older versions of xz until proven otherwise.
coding123(1)
Name and shame this author. They should never be allowed anywhere near any open projects ever again.
They might have burnt the reputation built for this particular pseudonym but what is stopping them from doing it again? They were clearly in it for the long run.
You're assuming that it's even a single person, it's just a gmail address and an avatar with a j icon from a clip art thing.
I literally said "they", I know, I know, in English that can also be interpreted as a gender unspecific singular.
Anyways, yes it is an interesting question whether he/she is alone or they are a group. Conway's law probably applies here as well. And my hunch in general is that these criminal mad minds operate individually / alone. Maybe they are hired by an agency but I don't count that as a group effort.
Anyways, yes it is an interesting question whether he/she is alone or they are a group. Conway's law probably applies here as well. And my hunch in general is that these criminal mad minds operate individually / alone. Maybe they are hired by an agency but I don't count that as a group effort.
Please don't?
1. You don't actually know what has been done by whom or why. You don't know if the author intended all of this, or if their account was compromised. You don't know if someone is pretending to be someone else. You don't know if this person was being blackmailed, forced against their will, etc. You don't really know much of anything, except a backdoor was introduced by somebody.
2. Assuming the author did do something maliciously, relying on personal reputation is bad security practice. The majority of successful security attacks come from insiders. You have to trust insiders, because someone has to get work done, and you don't know who's an insider attacker until they are found out. It's therefore a best security practice to limit access, provide audit logs, sign artifacts, etc, so you can trace back where an incursion happened, identify poisoned artifacts, remove them, etc. Just saying "let's ostracize Phil and hope this never happens again" doesn't work.
3. A lot of today's famous and important security researchers were, at one time or another, absolute dirtbags who did bad things. Human beings are fallible. But human beings can also grow and change. Nobody wants to listen to reason or compassion when their blood is up, so nobody wants to hear this right now. But that's why it needs to be said now. If someone is found guilty beyond a reasonable doubt (that's really the important part...), then name and shame, sure, shame can work wonders. But at some point people need to be given another chance.
1. You don't actually know what has been done by whom or why. You don't know if the author intended all of this, or if their account was compromised. You don't know if someone is pretending to be someone else. You don't know if this person was being blackmailed, forced against their will, etc. You don't really know much of anything, except a backdoor was introduced by somebody.
2. Assuming the author did do something maliciously, relying on personal reputation is bad security practice. The majority of successful security attacks come from insiders. You have to trust insiders, because someone has to get work done, and you don't know who's an insider attacker until they are found out. It's therefore a best security practice to limit access, provide audit logs, sign artifacts, etc, so you can trace back where an incursion happened, identify poisoned artifacts, remove them, etc. Just saying "let's ostracize Phil and hope this never happens again" doesn't work.
3. A lot of today's famous and important security researchers were, at one time or another, absolute dirtbags who did bad things. Human beings are fallible. But human beings can also grow and change. Nobody wants to listen to reason or compassion when their blood is up, so nobody wants to hear this right now. But that's why it needs to be said now. If someone is found guilty beyond a reasonable doubt (that's really the important part...), then name and shame, sure, shame can work wonders. But at some point people need to be given another chance.
100% fair -- we don't know if their account was compromised or if they meant to do this intentionally.
If it were me I'd be doing damage control to clear my name if my account was hacked and abused in this manner.
Otherwise if I was doing this knowing full well what would happen then full, complete defederation of me and my ability to contribute to anything ever again should commence -- the open source world is too open to such attacks where things are developed by people who assume good faith actors.
If it were me I'd be doing damage control to clear my name if my account was hacked and abused in this manner.
Otherwise if I was doing this knowing full well what would happen then full, complete defederation of me and my ability to contribute to anything ever again should commence -- the open source world is too open to such attacks where things are developed by people who assume good faith actors.
upon further reflection all 3 of your points are cogent and fair and valid. my original point was a knee-jerk reaction to this. :/
Your being able to reflect upon it and analyze your own reaction is rare, valuable and appreciated
I think I went through all the stages of grief. Now at the stage of acceptance here’s what I hope: I hope justice is done. Whoever is doing this be they a misguided current black hat (hopefully, future white hat) hacker, or just someone or someones that want to see the world burn or something in between that we see justice. And then forgiveness and acceptance and all that can happen later.
Mitnick reformed after he was convicted (whether you think that was warranted or not). Here if these folks are Mitnick’s or bad actors etc let’s get all the facts on the table and figure this out.
What’s clear is that we all need to be ever vigilant: that seemingly innocent patch could be part of a more nefarious thing.
We’ve seen it before with that university sending patches to the kernel to “test” how well the core team was at security and how well that went over.
Anyways. Yeah. Glad you all allowed me to grow. And I learned that I have an emotional connection to open source for better or worse: so much of my life professional and otherwise is enabled by it and so threats to it I guess I take personally.
Mitnick reformed after he was convicted (whether you think that was warranted or not). Here if these folks are Mitnick’s or bad actors etc let’s get all the facts on the table and figure this out.
What’s clear is that we all need to be ever vigilant: that seemingly innocent patch could be part of a more nefarious thing.
We’ve seen it before with that university sending patches to the kernel to “test” how well the core team was at security and how well that went over.
Anyways. Yeah. Glad you all allowed me to grow. And I learned that I have an emotional connection to open source for better or worse: so much of my life professional and otherwise is enabled by it and so threats to it I guess I take personally.
It is reasonable to consider all commits introduced by the backdoor author untrustworthy. This doesn't mean all of it is backdoored, but if they were capable of introducing this backdoor, their code needs scrutiny. I don't care why they did it, whether it's a state-sponsored attack, a long game that was supposed to end with selling a backdoor for all Linux machines out there for bazillions of dollars, or blackmail — this is a serious incident that should eliminate them from open-source contributions and the xz project.
There is no requirement to use your real name when contributing to open source projects. The name of the backdoor author ("Jia Tan") might be fake. If it isn't, and if somehow they are found to be innocent (which I doubt, looking at the evidence throughout the thread), they can create a new account with a new fake identity.
There is no requirement to use your real name when contributing to open source projects. The name of the backdoor author ("Jia Tan") might be fake. If it isn't, and if somehow they are found to be innocent (which I doubt, looking at the evidence throughout the thread), they can create a new account with a new fake identity.
I wonder who the target was!
Every Linux box inside AWS, Azure, and GCP and other cloud providers that retains the default admin sudo-able user (e.g., “ec2”) and is running ssh on port 22.
I bet they intended for their back door to eventually be merged into the base Amazon Linux image.
I bet they intended for their back door to eventually be merged into the base Amazon Linux image.
my understanding is that any Debian/RPM-based Linux running sshd would become vulnerable in a year or two. The best equivalent of this exploit is the One Ring.
So the really strange thing is why they put so little effort into making this undetectable. All they needed was to make it use less time to check each login attempt.
So the really strange thing is why they put so little effort into making this undetectable. All they needed was to make it use less time to check each login attempt.
In the other hand it was very hard to detect. The slow login time was the only thing that gave it away. It more seems like they were so close to being highly successful. In retrospect improving the performance would have been the smart play. But that is one part that went wrong compared to very many that went right.
You don't need a "ec2" user. A backdoor can just allow root login even when that is disabled for people not using the backdoor.
It just requires the SSH port to be reachable unless there is also a callout function (which is risky as people might see the traffic). And with Debian and Fedora covered and the change eventually making its way into Ubuntu and RHEL pretty much everything would have this backdoor.
It just requires the SSH port to be reachable unless there is also a callout function (which is risky as people might see the traffic). And with Debian and Fedora covered and the change eventually making its way into Ubuntu and RHEL pretty much everything would have this backdoor.
Probably less of an individual and more of an exploit to sell.
Distro build hosts and distro package maintainers might not be a bad guess. Depends on whether getting this shipped was the final goal. It might have been just the beginning, part of some bootstrapping.
I think this has been in the making for almost a year. The whole ifunc infrastructure was added in June 2023 by Hans Jansen and Jia Tan. The initial patch is "authored by" Lasse Collin in the git metadata, but the code actually came from Hans Jansen: https://github.com/tukaani-project/xz/commit/ee44863ae88e377...
> Thanks to Hans Jansen for the original patch.
https://github.com/tukaani-project/xz/pull/53
There were a ton of patches by these two subsequently because the ifunc code was breaking with all sorts of build options and obviously caused many problems with various sanitizers. Subsequently the configure script was modified multiple times to detect the use of sanitizers and abort the build unless either the sanitizer was disabled or the use of ifuncs was disabled. That would've masked the payload in many testing and debugging environments.
The hansjans162 Github account was created in 2023 and the only thing it did was add this code to liblzma. The same name later applied to do a NMU at Debian for the vulnerable version. Another "<name><number>" account (which only appears here, once) then pops up and asks for the vulnerable version to be imported: https://www.mail-archive.com/search?l=debian-bugs-dist@lists...
> Thanks to Hans Jansen for the original patch.
https://github.com/tukaani-project/xz/pull/53
There were a ton of patches by these two subsequently because the ifunc code was breaking with all sorts of build options and obviously caused many problems with various sanitizers. Subsequently the configure script was modified multiple times to detect the use of sanitizers and abort the build unless either the sanitizer was disabled or the use of ifuncs was disabled. That would've masked the payload in many testing and debugging environments.
The hansjans162 Github account was created in 2023 and the only thing it did was add this code to liblzma. The same name later applied to do a NMU at Debian for the vulnerable version. Another "<name><number>" account (which only appears here, once) then pops up and asks for the vulnerable version to be imported: https://www.mail-archive.com/search?l=debian-bugs-dist@lists...
Also I saw this hans jansen user pushing for merging the 5.6.1 update in debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708
From: krygorin4545 <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>
Subject: Re: RFS: xz-utils/5.6.1-0.1 [NMU] -- XZ-format compression utilities
Date: Tue, 26 Mar 2024 19:27:47 +0000
Also seeing this bug. Extra valgrind output causes some failed tests for me. Looks like the new version will resolve it. Would like this new version so I can continue work.
--
Wow.
(Edited for clarity.)
Also seeing this bug. Extra valgrind output causes some failed tests for me. Looks like the new version will resolve it. Would like this new version so I can continue work.
--
Wow.
(Edited for clarity.)
我还看到了这个 PR：
https://github.com/tukaani-project/xz/pull/64
https://github.com/tukaani-project/xz/pull/64
> 因为 ifunc 代码破坏了各种构建选项，并且显然导致了各种消毒剂的许多问题
例如，https://github.com/google/oss-fuzz/pull/10667
例如，https://github.com/google/oss-fuzz/pull/10667
1 week ago "Hans Jansen" user "hjansen" was created in debian and opened 8 PRs including the upgrade to 5.6.1 to xz-utils
From https://salsa.debian.org/users/hjansen/activity
Author: Hans Jansen <[email protected]>
- [Debian Games / empire](https://salsa.debian.org/games-team/empire): opened merge request "!2 New upstream version 1.17" - March 17, 2024
- [Debian Games / empire](https://salsa.debian.org/games-team/empire): opened merge request "!1 Update to upstream 1.17" - March 17, 2024
- [Debian Games / libretro / libretro-core-info](https://salsa.debian.org/games-team/libretro/libretro-core-i...): opened merge request "!2 New upstream version 1.17.0" - March 17, 2024
- [Debian Games / libretro / libretro-core-info](https://salsa.debian.org/games-team/libretro/libretro-core-i...): opened merge request "!1 Update to upstream 1.17.0" - March 17, 2024
- [Debian Games / endless-sky](https://salsa.debian.org/games-team/endless-sky): opened merge request "!6 Update upstream branch to 0.10.6" - March 17, 2024
- [Debian Games / endless-sky](https://salsa.debian.org/games-team/endless-sky): opened merge request "!5 Update to upstream 0.10.6" - March 17, 2024
- [Debian / Xz Utils](https://salsa.debian.org/debian/xz-utils): opened merge request "!1 Update to upstream 5.6.1" - March 17, 2024
From https://salsa.debian.org/users/hjansen/activity
Author: Hans Jansen <[email protected]>
- [Debian Games / empire](https://salsa.debian.org/games-team/empire): opened merge request "!2 New upstream version 1.17" - March 17, 2024
- [Debian Games / empire](https://salsa.debian.org/games-team/empire): opened merge request "!1 Update to upstream 1.17" - March 17, 2024
- [Debian Games / libretro / libretro-core-info](https://salsa.debian.org/games-team/libretro/libretro-core-i...): opened merge request "!2 New upstream version 1.17.0" - March 17, 2024
- [Debian Games / libretro / libretro-core-info](https://salsa.debian.org/games-team/libretro/libretro-core-i...): opened merge request "!1 Update to upstream 1.17.0" - March 17, 2024
- [Debian Games / endless-sky](https://salsa.debian.org/games-team/endless-sky): opened merge request "!6 Update upstream branch to 0.10.6" - March 17, 2024
- [Debian Games / endless-sky](https://salsa.debian.org/games-team/endless-sky): opened merge request "!5 Update to upstream 0.10.6" - March 17, 2024
- [Debian / Xz Utils](https://salsa.debian.org/debian/xz-utils): opened merge request "!1 Update to upstream 5.6.1" - March 17, 2024
Wow, what a big pile of infrastructure for a non-optimization.
An internal call via ifunc is not magic — it’s just a call via the GOT or PLT, which boils down to function pointers. An internal call through a hidden visibility function pointer (the right way to do this) is also a function pointer.
The even better solution is a plain old if statement, which implements the very very fancy “devirtualization” optimization, and the result will be effectively predicted on most CPUs and is not subject to the whole pile of issue that retpolines are needed to work around.
An internal call via ifunc is not magic — it’s just a call via the GOT or PLT, which boils down to function pointers. An internal call through a hidden visibility function pointer (the right way to do this) is also a function pointer.
The even better solution is a plain old if statement, which implements the very very fancy “devirtualization” optimization, and the result will be effectively predicted on most CPUs and is not subject to the whole pile of issue that retpolines are needed to work around.
Right, IFUNCs make sense for library function where you have the function pointer indirection anyway. Makes much less sense for internal functions - only argument over a regular function pointer would be the pointer being marked RO after it is resolved (if the library was linked with -z relro -z now), but an if avoids even that issue.
>Hans Jansen and Jia Tan
Are they really two people conspiring?
Unless proven otherwise, it is safe to assume one is just a pseudonym alias of the other.
Are they really two people conspiring?
Unless proven otherwise, it is safe to assume one is just a pseudonym alias of the other.
or possibly just one person acting as two, or a group of people?
Or a group managing many identities, backdooring many different projects
Make it two years.
Jia Tan getting maintainer access looks like it is almost certainly to be part of the operation. Lasse Colling mentioned multiple times how Jia has helped off-list and to me it seems like Jia befriended Lasse as well (see how Lasse talks about them in 2023).
Also the pattern of astroturfing dates back to 2022. See for example this thread where Jia, who has helped at this point for a few weeks, posts a patch, and a <name><number>@protonmail (jigarkumar17) user pops up and then bumps the thread three times(!) lamenting the slowness of the project and pushing for Jia to get commit access: https://www.mail-archive.com/[email protected]/msg00553.h...
Naturally, like in the other instances of this happening, this user only appears once on the internet.
Jia Tan getting maintainer access looks like it is almost certainly to be part of the operation. Lasse Colling mentioned multiple times how Jia has helped off-list and to me it seems like Jia befriended Lasse as well (see how Lasse talks about them in 2023).
Also the pattern of astroturfing dates back to 2022. See for example this thread where Jia, who has helped at this point for a few weeks, posts a patch, and a <name><number>@protonmail (jigarkumar17) user pops up and then bumps the thread three times(!) lamenting the slowness of the project and pushing for Jia to get commit access: https://www.mail-archive.com/[email protected]/msg00553.h...
Naturally, like in the other instances of this happening, this user only appears once on the internet.
Does anybody know anything about Jia Tan? Is it likely just a made up persona? Or is this a well-known person.
It’s certainly a pseudonym just like all the other personas we’ve seen popping up on the mailing list supporting this “Jia Tan” in these couple of years. For all intents and purposes they can be of any nationality until we know more.
It seems like Hans Jansen has also an account on proton.me ([email protected]) with the Outlook address configured as recovery-email.
sorokod(1)
Yesterday sure was fun wasn't it :p Thanks for all your help/working with me on getting this cleaned up in Fedora.
PSA: I just noticed homebrew installed the compromised version on my Mac as a dependency of some other package. You may want to check this to see what version you get:
xz --version
Thanks for this. I just ran brew upgrade and the result was as you described:
xz 5.6.1 -> 5.4.6I also had a homebrew installed affected version.
I understand it's unlikely, but is there anything I can do to check if the backdoor was used? Also any other steps I should take after "brew upgrade"?
I understand it's unlikely, but is there anything I can do to check if the backdoor was used? Also any other steps I should take after "brew upgrade"?
引用 Github 上 Homebrew 的[1]：
>> 看起来 Homebrew 用户（macOS 和 Linux，Intel 和 ARM）不太可能受到影响？
> 正确。尽管我们似乎没有受到影响，但这种恢复是出于非常谨慎的考虑。
[1] https://github.com/Homebrew/homebrew-core/pull/167512
>> 看起来 Homebrew 用户（macOS 和 Linux，Intel 和 ARM）不太可能受到影响？
> 正确。尽管我们似乎没有受到影响，但这种恢复是出于非常谨慎的考虑。
[1] https://github.com/Homebrew/homebrew-core/pull/167512
Is it actually compromised on homebrew though? I guess we can't be sure but it seemed to be checking if it was being packaged as .deb or .rpm?
Is 5.2.2 safe? Just 5.6.0 and 5.6.1 are bad?
sorry, what exact version(s) is the one(s) affected again?
(or SHAs, etc.)
(EDIT: 5.6.0 and 5.6.1 ?)
(EDIT 2: Ooof, looks like the nix unstable channel uses xz 5.6.1 at this time)
I use Nix to manage this stuff on Mac, not Homebrew...
(or SHAs, etc.)
(EDIT: 5.6.0 and 5.6.1 ?)
(EDIT 2: Ooof, looks like the nix unstable channel uses xz 5.6.1 at this time)
I use Nix to manage this stuff on Mac, not Homebrew...
Sleeper.
Debian have reverted xz-utils (in unstable) to 5.4.5 – actual version string is “5.6.1+really5.4.5-1”. So presumably that version's safe; we shall see…
Is that version truly vetted? "Jia Tan" has been the official maintainer since 5.4.3, could have pushed code under any other pseudonym, and controls the signing keys. I would have felt better about reverting farther back, xz hasn't had any breaking changes for a long time.
It's not only that account, other maintainer has been pushing the same promotion all over the place.
It looks like this is being discussed, with a complication of additional symbols that were introduced https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024
Thanks for this! I found this URL in the thread very interesting!
https://www.nongnu.org/lzip/xz_inadequate.html
https://www.nongnu.org/lzip/xz_inadequate.html
[deleted]
It is an excellent technical write-up and yet again another testimonial to the importance of keeping things simple.
这里的其他评论表明后门是一个长期的努力，现在让我想知道这是一个多长时间的努力......
There are suggestions to roll back further
TIL that +really is a canonical string. [0]
[0]: https://www.debian.org/doc/debian-policy/ch-controlfields.ht...
[0]: https://www.debian.org/doc/debian-policy/ch-controlfields.ht...
because of it's "great new features"
"great" for whom? I've seen enough of the industry to immediately feel suspicious when someone uses that sort of phrasing in an attempt to persuade me. It's no different from claiming a "better experience" or similar.
"great" for whom? I've seen enough of the industry to immediately feel suspicious when someone uses that sort of phrasing in an attempt to persuade me. It's no different from claiming a "better experience" or similar.
You can find more examples of that kind of puffer if you go to a website's cookie consent pop-up and find the clause after "we use cookies to...".
I’ve long thought that those “this new version fixes bugs and improves user experience” patch notes that Meta et al copy and paste on every release shouldn’t be permitted.
Tell me about it. I look at all these random updates that get pushed to my mobile phone and they all pretty much have that kind of fluff in the description. Apple/Android should take some steps to improve this or outright ban this practice. In terms of importance to them though I imagine this is pretty low on the list.
I have dreamed about an automated LLM system that can "diff" the changes out of the binary and provide some insight. You know give back a tiny bit of power to the user. I'll keep dreaming.
I have dreamed about an automated LLM system that can "diff" the changes out of the binary and provide some insight. You know give back a tiny bit of power to the user. I'll keep dreaming.
更糟糕的是，作为一个试图提供发行说明的人，我经常被字段的最大长度打断。即便如此，Play 也只会向您显示该应用程序最新版本的注释。
Slack's Mac app release notes [1] rotate a few copy pastes, here's the one that shits me the most.
> We tuned up the engine and gave the interiors a thorough clean. Everything is now running smoothly again.
Yeah nah mate, if every release is the first release where everything is running smoothly, I'm not going to believe it this time either.
Makes me wonder if the team has some release quota to fill and will push a build even if nothing meaningful has actually changed.
[1] https://slack.com/release-notes/mac
> We tuned up the engine and gave the interiors a thorough clean. Everything is now running smoothly again.
Yeah nah mate, if every release is the first release where everything is running smoothly, I'm not going to believe it this time either.
Makes me wonder if the team has some release quota to fill and will push a build even if nothing meaningful has actually changed.
[1] https://slack.com/release-notes/mac
Ugh. That's especially annoying because they're trying to be hip with slang and use a metaphor that requires cultural knowledge that you can't really assume everyone has.
I made a library where version 2 is really really much faster than version 1. I'd want everyone to just move to version 2.
But then you are saying a specific great new feature, performance, and not just the claim and concept performance, but numbers.
I'm sure they actually had new features…
Yeah... RISCV routine was put in, then some binary test files were added later that are probably now suspect.
don't miss out on the quality code, like the line that has: i += 4 - 2;
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=50255feeaab...
don't miss out on the quality code, like the line that has: i += 4 - 2;
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=50255feeaab...
> 后来添加了一些二进制测试文件，现在可能值得怀疑
已确认
来自 https://www.openwall.com/lists/oss-security/2024/03/29/4：
> 包含大量漏洞利用的文件以混淆形式存在于
> 测试/文件/bad-3-corrupt_lzma2.xz
> 测试/文件/good-large_compressed.lzma
> 致力于上游。它们最初被添加到
> https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf...
已确认
来自 https://www.openwall.com/lists/oss-security/2024/03/29/4：
> 包含大量漏洞利用的文件以混淆形式存在于
> 测试/文件/bad-3-corrupt_lzma2.xz
> 测试/文件/good-large_compressed.lzma
> 致力于上游。它们最初被添加到
> https://github.com/tukaani-project/xz/commit/cf44e4b7f5dfdbf...
FWIW, "4 - 2" is explained earlier in the file:
// The "-2" is included because the for-loop will
// always increment by 2. In this case, we want to
// skip an extra 2 bytes since we used 4 bytes
// of input.
i += 4 - 2;What are they specifically?
I don't know how you can be missing the essence of the problem here or that comments point.
Vague claims are meaningless and valueless and are now even worse than that, they are a red flag.
Please don't tell me that you would accept a pr that didn't explain what it did, and why it did it, and how it did it, with code that actually matched up with the claim, and was all actually something you wanted or agreed was a good change to your project.
Updating to the next version of a library is completely unrelated. When you update a library, you don't know what all the changes were to the library, _but the librarys maintainers do_, and you essentially trust that librarys maintainers to be doing their job not accepting random patches that might do anything.
Updating a dependency and trusting a project to be sane is entirely a different prospect from accepting a pr and just trusting that the submitter only did things that are both well intentioned and well executed.
If you don't get this then I for sure will not be using or trusting your library.
I don't know how you can be missing the essence of the problem here or that comments point.
Vague claims are meaningless and valueless and are now even worse than that, they are a red flag.
Please don't tell me that you would accept a pr that didn't explain what it did, and why it did it, and how it did it, with code that actually matched up with the claim, and was all actually something you wanted or agreed was a good change to your project.
Updating to the next version of a library is completely unrelated. When you update a library, you don't know what all the changes were to the library, _but the librarys maintainers do_, and you essentially trust that librarys maintainers to be doing their job not accepting random patches that might do anything.
Updating a dependency and trusting a project to be sane is entirely a different prospect from accepting a pr and just trusting that the submitter only did things that are both well intentioned and well executed.
If you don't get this then I for sure will not be using or trusting your library.
两名 xz 维护者的 Github 帐户已被暂停。
不是真的，原作者没有被停职：https://github.com/Larhzu
https://github.com/JiaT75 暂停了一会儿，但现在不是了吗？
https://github.com/JiaT75 暂停了一会儿，但现在不是了吗？
Both are suspended for me. Check followers on both accounts, both have a suspended pill right next to their names.
GitHub 的 UI 最近在显示一致和及时的信息方面变得出了名的糟糕，这可能是一个由此产生的问题。
是的。 上周遇到了一个奇怪的问题，GitHub 在使用 curl 时从原始 url 提供旧源代码，但在来自浏览器时显示最新源代码。
尝试开发自动化时非常令人沮丧。 :(
尝试开发自动化时非常令人沮丧。 :(
These shouldn't be suspended, and neither should their repositories. People might want to dig through the source code. It's okay if they add a warning on the repository, but suspending _everything_ is a stupid thing to do.
Tools don't read warnings. Of course the information should not be hidden completely but intentionally breaking the download URLs makes sense.
这也可以相对容易地处理。他们可以禁用旧链接，并且可以专门为禁用的存储库添加一个新链接。或者甚至只是让存储库至少可以通过界面浏览。
简单地显示一个巨大的页面说“此存储库已禁用”没有任何帮助。
简单地显示一个巨大的页面说“此存储库已禁用”没有任何帮助。
Interesting that one of the commits commented on update of the test file that it was for better reproducibility for having been generated by a fixed random seed (although how goes unmentioned). For the future, random test data better be generated as part of the build, rather than being committed as opaque blobs...
I agree on principle, but sometimes programmatic generating test data is not so easy.
E.g.: I have a specific JPEG committed into a repository because it triggers a specific issue when reading its metadata. It's not just _random_ data, but specific bogus data.
But yeah, if the test blob is purely random, then you can just commit a seed and generate in during tests.
E.g.: I have a specific JPEG committed into a repository because it triggers a specific issue when reading its metadata. It's not just _random_ data, but specific bogus data.
But yeah, if the test blob is purely random, then you can just commit a seed and generate in during tests.
I’m surprised there isn’t way more of this stuff. The supply chain is so huge and therefore represents so much surface area.
There probably is. Way more than anyone knows. I bet every major project on github is riddled with state actors.
GitHub 已暂停@JiaT75 的帐户。
编辑：Lasse Collin 的帐户@Larhzu 也已被暂停。
编辑：Github 已禁用所有 Tukaani 存储库，包括从发布页面下载。
--
编辑：只是做了一些戳。 xz-embedded 也被 Jia 接触过，它似乎被用在 Linux 内核中。我快速浏览了一下，贾跃亭似乎没有触及任何感兴趣的东西。我还在 tukaani 项目网站上检查了之前的镜像，除了落后了一些提交之外，没有什么不合适的地方：
https://gist.github.com/Qix-/f1a1b9a933e8847f56103bc14783ab7...
--
这是来自他们的邮件列表消息。 2022 年。
https://listor.tp-sv.se/pipermail/tp-sv_listor.tp-sv.se/2022...
--
AUR 上的 MinGW w64 最后由 Jia 于 2 月 29 日发布：
https://aur.archlinux.org/cgit/aur.git/log/?h=mingw-w64-xz（通过搜索其公钥找到：22D465F2B4C173803B20C6DE59FCF207FEA7F445）
--
AUR 上的 pacman-static 仍然将其公钥列为贡献者，xz 最后更新到 5.4.5 于 17-11-2023：https://aur.archlinux.org/cgit/aur.git/?h=pacman-static
编辑：我已向维护人员发送电子邮件以删除密钥。
--
Alpine 截至 6 小时前已修复。
https://git.alpinelinux.org/aports/commit/?id=982d2c6bcbbb57...
--
OpenSUSE 仍然列出 Jia 的公钥：https://sources.suse.com/SUSE:SLE-15-SP6:GA/xz/576e550c49a36...（与 https://web.archive.org/web/20240329235153/https://tukaani.o... 交叉引用）
编辑：与 libera 软件包频道中的一些人交谈，似乎不是问题。它不用作证明，也不用作 ACL。
--
如果我对这个页面的理解正确的话，Arch 似乎仍然将贾列为批准的发布者。
https://gitlab.archlinux.org/archlinux/packaging/packages/xz...
编辑：刚刚向最后一个提交者发送了一封电子邮件以引起他们的注意。
编辑：它已被删除。
--
jiatan 的 Libera 信息表明他们于 2022 年 12 月 12 日 13:43:12 注册，没有时区信息。
-NickServ- jiatan 信息（帐号 jiatan）：
-NickServ- 注册：2022 年 12 月 12 日 13:43:12 +0000（1 年 15 周 3 天前）
-NickServ- 上次出现：（不到两周前）
-NickServ- 用户看到：（不到两周前）
-NickServ- 标志：隐藏邮件、私人
-NickServ- jiatan 已启用缺口保护
-NickServ- *** 信息结束 ***
不幸的是，/who 不久前就过期了。如果有人有的话我很想知道。
他们没有在 freenode 上注册。
编辑：Libera 表示，截至目前，他们尚未收到任何机构的任何信息请求（2024 年 3 月 30 日星期六 00:39:31 UTC）。
编辑：Jia Tan 使用 VPN 进行连接；这就是我要在这里分享的全部内容。
编辑：Lasse Collin 的帐户@Larhzu 也已被暂停。
编辑：Github 已禁用所有 Tukaani 存储库，包括从发布页面下载。
--
编辑：只是做了一些戳。 xz-embedded 也被 Jia 接触过，它似乎被用在 Linux 内核中。我快速浏览了一下，贾跃亭似乎没有触及任何感兴趣的东西。我还在 tukaani 项目网站上检查了之前的镜像，除了落后了一些提交之外，没有什么不合适的地方：
https://gist.github.com/Qix-/f1a1b9a933e8847f56103bc14783ab7...
--
这是来自他们的邮件列表消息。 2022 年。
https://listor.tp-sv.se/pipermail/tp-sv_listor.tp-sv.se/2022...
--
AUR 上的 MinGW w64 最后由 Jia 于 2 月 29 日发布：
https://aur.archlinux.org/cgit/aur.git/log/?h=mingw-w64-xz（通过搜索其公钥找到：22D465F2B4C173803B20C6DE59FCF207FEA7F445）
--
AUR 上的 pacman-static 仍然将其公钥列为贡献者，xz 最后更新到 5.4.5 于 17-11-2023：https://aur.archlinux.org/cgit/aur.git/?h=pacman-static
编辑：我已向维护人员发送电子邮件以删除密钥。
--
Alpine 截至 6 小时前已修复。
https://git.alpinelinux.org/aports/commit/?id=982d2c6bcbbb57...
--
OpenSUSE 仍然列出 Jia 的公钥：https://sources.suse.com/SUSE:SLE-15-SP6:GA/xz/576e550c49a36...（与 https://web.archive.org/web/20240329235153/https://tukaani.o... 交叉引用）
编辑：与 libera 软件包频道中的一些人交谈，似乎不是问题。它不用作证明，也不用作 ACL。
--
如果我对这个页面的理解正确的话，Arch 似乎仍然将贾列为批准的发布者。
https://gitlab.archlinux.org/archlinux/packaging/packages/xz...
编辑：刚刚向最后一个提交者发送了一封电子邮件以引起他们的注意。
编辑：它已被删除。
--
jiatan 的 Libera 信息表明他们于 2022 年 12 月 12 日 13:43:12 注册，没有时区信息。
-NickServ- jiatan 信息（帐号 jiatan）：
-NickServ- 注册：2022 年 12 月 12 日 13:43:12 +0000（1 年 15 周 3 天前）
-NickServ- 上次出现：（不到两周前）
-NickServ- 用户看到：（不到两周前）
-NickServ- 标志：隐藏邮件、私人
-NickServ- jiatan 已启用缺口保护
-NickServ- *** 信息结束 ***
不幸的是，/who 不久前就过期了。如果有人有的话我很想知道。
他们没有在 freenode 上注册。
编辑：Libera 表示，截至目前，他们尚未收到任何机构的任何信息请求（2024 年 3 月 30 日星期六 00:39:31 UTC）。
编辑：Jia Tan 使用 VPN 进行连接；这就是我要在这里分享的全部内容。
Just for posterity since I can no longer edit: Libera staff has been firm and unrelenting in their position not to disclose anything whatsoever about the account. I obtained the last point on my own. Libera has made it clear they will not budge on this topic, which I applaud and respect. They were not involved whatsoever in ascertaining a VPN was used, and since that fact makes anything else about the connection information moot, there's nothing else to say about it.
Fnoord(4)
The alpine patch includes gettext-dev which is likely also exploited as the same authors have been pushing gettext to projects where their changes have been questioned
What do you mean?
Look at the newest commits, do you see anything suspicious:
https://git.alpinelinux.org/aports/log/main/gettext
libunistring could also be affected as that has also been pushed there
https://git.alpinelinux.org/aports/log/main/gettext
libunistring could also be affected as that has also been pushed there
Seeing so many commits that are "skip failing test" is a very strong code smell.
Yes, but it is often a sad reality of trying to run projects mainly written for glibc on musl. Not many people write portable C these days.
It's still the wrong way to go about things. Tests are there for a reason, meaning if they fail you should try to understand them to the point where you can fix the problem (broken test or actual bug) instead of just wantonly distabling tests until you get a green light.
> do you see anything suspicious
No.
> libunistring could also be affected as that has also been pushed there
What do you mean by "that"?
No.
> libunistring could also be affected as that has also been pushed there
What do you mean by "that"?
> 编辑：Github 已禁用所有 Tukaani 存储库，包括从发布页面下载。
为什么？冻结它们并让尽可能多的人分析代码不是更好吗？
为什么？冻结它们并让尽可能多的人分析代码不是更好吗？
You can still find the source everywhere, if you look for it. Having a fine-looking page distribute vulnerable source code is a much bigger threat.
好问题，尽管我可以想象他们采取这一行动有两个原因：
1.他们没有能力冻结回购协议（即需要一些工程工作来实现它），因为我以前从未见过他们这样做。
2. 许多发行版（我假设许多企业）仍在链接到 GitHub 版本以获取受感染的 tarball 进行构建。禁用存储库可以防止这种情况发生。
受感染的 tarball 和 repo 仍然可以在其他地方供研究人员找到。
1.他们没有能力冻结回购协议（即需要一些工程工作来实现它），因为我以前从未见过他们这样做。
2. 许多发行版（我假设许多企业）仍在链接到 GitHub 版本以获取受感染的 tarball 进行构建。禁用存储库可以防止这种情况发生。
受感染的 tarball 和 repo 仍然可以在其他地方供研究人员找到。
They could always archive it. Theoretically (and I mean theoretically only), there's another reason for Microsoft to prevent access to repo: if a nation state was involved, and there've been backdoor conversations to obfuscate the trail.
Maybe one can get the code from here. New commits being added it seems.
https://git.tukaani.org/
https://git.tukaani.org/
The latest commit is interesting (f9cf4c05edd14, "Fix sabotaged Landlock sandbox check").
It looks like one of Jia Tan's commits (328c52da8a2) added a stray "." character to a piece of C code that was part of a check for sandboxing support, which I guess would cause the code to fail to compile, causing the check to fail, causing the sandboxing to be disabled.
It looks like one of Jia Tan's commits (328c52da8a2) added a stray "." character to a piece of C code that was part of a check for sandboxing support, which I guess would cause the code to fail to compile, causing the check to fail, causing the sandboxing to be disabled.
Lasse has also started his own documentation on the incident.
https://tukaani.org/xz-backdoor/
https://tukaani.org/xz-backdoor/
Shouldn't they have tests running to ensure that the check works on at least some systems?
If your project becomes complex enough eventually you need tests for the configure step. Even without malicious actors its easy to miss that a compiler or system change broke some check.
megous(1)
You can find it on archive. Someone archived it last night
Asking this here too: why isn't there an automated A/B or diff match for the tarball contents to match the repo, auto-flag with a warning if that happens? Am I missing something here?
The tarballs mismatching from the git tree is a feature, not a bug. Projects that use submodules may want to include these and projects using autoconf may want to generate and include the configure script.
Here is a longer explainer: https://www.redhat.com/en/blog/what-open-source-upstream
"lol"
> Those days are pretty much behind us. Sure, you can compile code and tweak software configurations if you want to--but most of the time, users don't want to. Organizations generally don't want to, they want to rely on certified products that they can vet for their environment and get support for. This is why enterprise open source exists. Users and organizations count on vendors to turn upstreams into coherent downstream products that meet their needs.
> In turn, vendors like Red Hat learn from customer requests and feedback about what features they need and want. That, then, benefits the upstream project in the form of new features and bugfixes, etc., and ultimately finds its way into products and the cycle continues.
"and when the upstream is tainted, everyone drinks poisoned water downstream, simple as that!"
> Those days are pretty much behind us. Sure, you can compile code and tweak software configurations if you want to--but most of the time, users don't want to. Organizations generally don't want to, they want to rely on certified products that they can vet for their environment and get support for. This is why enterprise open source exists. Users and organizations count on vendors to turn upstreams into coherent downstream products that meet their needs.
> In turn, vendors like Red Hat learn from customer requests and feedback about what features they need and want. That, then, benefits the upstream project in the form of new features and bugfixes, etc., and ultimately finds its way into products and the cycle continues.
"and when the upstream is tainted, everyone drinks poisoned water downstream, simple as that!"
> git 树中的 tarball 不匹配是一个功能，而不是一个错误。
让我们这样说吧，这是一个允许漏洞利用的功能。
在这里：https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...
> 上游发布的版本 tarball 没有与 GitHub 相同的代码。这在 C 项目中很常见，因此下游消费者不需要记住如何运行 autotools 和 autoconf。发布 tarball 中的 build-to-host.m4 版本与 GitHub 上的上游版本有很大不同。
关于该主题的多项建议表明，这是一种可能已经过时的传统做法，尤其是在当前网络威胁的环境下。
有人甚至发布了更全面的要点，说明如何提高透明度并减少 tarball 和 repos 之间的差异：https://gist.github.com/smintrh78/97b5cb4d8332ea4808f25b47c8...
让我们这样说吧，这是一个允许漏洞利用的功能。
在这里：https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...
> 上游发布的版本 tarball 没有与 GitHub 相同的代码。这在 C 项目中很常见，因此下游消费者不需要记住如何运行 autotools 和 autoconf。发布 tarball 中的 build-to-host.m4 版本与 GitHub 上的上游版本有很大不同。
关于该主题的多项建议表明，这是一种可能已经过时的传统做法，尤其是在当前网络威胁的环境下。
有人甚至发布了更全面的要点，说明如何提高透明度并减少 tarball 和 repos 之间的差异：https://gist.github.com/smintrh78/97b5cb4d8332ea4808f25b47c8...
I've posted an earlier WHOWAS of jiatan here: https://news.ycombinator.com/item?id=39868773
It appears to be an RCE, not a public key bypass: https://news.ycombinator.com/item?id=39877312
account is back online
https://github.com/JiaT75
Hopefully still locked just visible so people can find and alayze his contributions.
After reading the original post by Andres Freund, https://www.openwall.com/lists/oss-security/2024/03/29/4, his analysis indicates that the RSA_public_decrypt function is being redirected to the malware code. Since RSA_public_decrypt is only used in the context of RSA public key - private key authentication, can we reasonably conclude that the backdoor does not affect username-password authentication?
Isn't it rather that the attacker can log in to the compromised server by exploiting the RSA code path?
Nice. I worked on a Linux disto when I was a wee lad and all we did was compute a new md5 and ship it.
Can legal action be taken against the author if it's found he maliciously added the backdoor?
Good luck with that.
We don't even know what country is he from.
Probably from China but even if so.
Good luck finding him among 1.5 Billions.
他的帐户在 github 上再次活跃 https://github.com/JiaT75
It is not good to take into consideration something with any unreadable text instead of the open text of the programme. It should be excluded.
The discussion to upload it to Debian is interesting on its own
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708
Wow, that's a lot of anonymous accounts adding comments there urging for a fast merge!
And this "Hans Jansen" guy is apparently running around salsa.debian.org pushing for more updates in other projects as well: https://salsa.debian.org/users/hjansen/activity
And this "Hans Jansen" guy is apparently running around salsa.debian.org pushing for more updates in other projects as well: https://salsa.debian.org/users/hjansen/activity
> running around salsa.debian.org pushing for more updates in other projects as well
This is quite common in most (all?) distributions. People are going through lists of outdated packages, updating them, testing them, and pushing them.
This is quite common in most (all?) distributions. People are going through lists of outdated packages, updating them, testing them, and pushing them.
不过，该帐户似乎是 xz 的贡献者，您可以在 GitHub 存储库上看到他与后门的作者进行了很多互动。一些拉取请求似乎只是他们两个讨论和合并内容（这很正常，但在这种情况下看起来很奇怪）
[deleted]
现在我们明白为什么我不相信匿名者、别名或动漫人物做出贡献了。
我的 GitHub 准确地说明了我是谁！
我的 GitHub 准确地说明了我是谁！
It has been on the agenda for years to identify FOSS contributors with an id… Wet dream for authoritarians like you.
What would it solve when identity theft happens on a mass scale on a day to day basis?
It'd just ruin the life of some random person whose identity got stolen to create the account…
What would it solve when identity theft happens on a mass scale on a day to day basis?
It'd just ruin the life of some random person whose identity got stolen to create the account…
[deleted]
您可以使用生成式 AI 轻松生成逼真的照片、个人简介，甚至整个个人博客和 GitHub 项目，使其看起来像真人。
With close to zero OSS participation rate you can just pick a real living person and just keep in sync with their LinkedIn.
Even if they have a "real" picture or a credible description that is not good enough. Instead of using an anime character a malicious actor could use an image generator [0], they could generate a few images, obtain something credible to most folks, and use that to get a few fake identities going. Sadly, trusting people to be the real thing and not a fake identity on the Internet is difficult now and it will get worse.
[0] https://thispersondoesnotexist.com
[0] https://thispersondoesnotexist.com
>that's a lot of anonymous accounts
Just FYI, [email protected] (the latest message before the upload) was created Tue Mar 26 18:30:02 UTC 2024, about an hour earlier than the message was posted.
Proton generates PGP key upon creating the account, with the real datetime of the key (but the key does not include the timezone).
Just FYI, [email protected] (the latest message before the upload) was created Tue Mar 26 18:30:02 UTC 2024, about an hour earlier than the message was posted.
Proton generates PGP key upon creating the account, with the real datetime of the key (but the key does not include the timezone).
That name jumped out at me, Hans Jansen is the name Dominic Monaghan used when posing as a German interviewer with Elijah Woods. Not that it can't be a real person
https://youtu.be/IfhMILe8C84
https://youtu.be/IfhMILe8C84
I get the feeling that a number of the comments are all the same person / group.
对于其他对 ifunc / Valgrind 错误感到似曾相识的人来说，此 Red Hat 问题 [1] 之前已于 12 天前从 HN 链接[2]。
[1]：https://bugzilla.redhat.com/show_bug.cgi?id=2267598
[2]：https://news.ycombinator.com/item?id=39733185
[1]：https://bugzilla.redhat.com/show_bug.cgi?id=2267598
[2]：https://news.ycombinator.com/item?id=39733185
相当讽刺的是：git 存储库中的最新提交是“Simplify SECURITY.md”，由添加后门的同一 Github 帐户提交。
https://github.com/tukaani-project/xz/commit/af071ef7702debe...
https://github.com/tukaani-project/xz/commit/af071ef7702debe...
It's not ironic, this change is really sinister IMO. They want you to waste more time after you've submitted the security report and maximize the amount of back and forth. Basically the hope is that they'd be able to pester you with requests for more info/details in order to "resolve the issue" which would give them more time to exploit their targets.
I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup (and not in "curl | sh" scripts).
Would be interesting to see what's going on here; the person who did the releases has done previous releases too (are they affected?) And has commits going back to 2022 – relatively recent, but not that recent. Many are real commits with real changes, and they have commits on some related projects like libarchive. Seems like a lot of effort just to insert a backdoor.
Edit: anyone with access can add files to existing releases and it won't show that someone else added it (I just tested). However, the timestamp of the file will be to when you uploaded it, not that of the release. On xz all the timestamps of the files match with the timestamp of the release (usually the .tar.gz is a few minutes earlier, which makes sense). So looks like they were done by the same person who did the release. I suspected someone else might have added/altered the files briefly after the release before anyone noticed, but that doesn't seem to be the case.
Would be interesting to see what's going on here; the person who did the releases has done previous releases too (are they affected?) And has commits going back to 2022 – relatively recent, but not that recent. Many are real commits with real changes, and they have commits on some related projects like libarchive. Seems like a lot of effort just to insert a backdoor.
Edit: anyone with access can add files to existing releases and it won't show that someone else added it (I just tested). However, the timestamp of the file will be to when you uploaded it, not that of the release. On xz all the timestamps of the files match with the timestamp of the release (usually the .tar.gz is a few minutes earlier, which makes sense). So looks like they were done by the same person who did the release. I suspected someone else might have added/altered the files briefly after the release before anyone noticed, but that doesn't seem to be the case.
I would be curious if their commits could be analyzed for patterns that could then be used to detect commits from their other account
[deleted]
There was a DARPA program on this topic called Social Cyber. [1]
1. https://www.darpa.mil/program/hybrid-ai-to-protect-integrity...
1. https://www.darpa.mil/program/hybrid-ai-to-protect-integrity...
I mean, a backdoor at this scale (particularly if it wasn't noticed for a while and got into stable distros) could be worth millions. Maybe hundreds of millions (think of the insider trading possibilities alone, not to mention espionage). 2 years doesn't seem like that much work relative to the potential pay off.
This is the sort of case where america's over the top hacking laws make sense.
This is the sort of case where america's over the top hacking laws make sense.
And what law would you use to target someone who wrote some code and posted it for free on the internet that was willingly consumed?
The computer abuse and fraud act? Seems like a pretty easy question to answer.
Maybe I'm miss understanding things, but it seems like anyone can publish an exploit on the internet without being a crime. In the same way encryption is free speech.
It would seem unlikely this guy would be also logging into peoples boxes after this.
It seems a much tougher job to link something like this to an intentional unauthorized access.
At this point, we have no confirmed access via compromise.
Do you know of a specific case where the existence of a backdoor has been prosecuted without a compromise?
Who would have standing to bring this case? Anyone with a vulnerable machine? Someone with a known unauthorized access. Other maintainers of the repo?
IANAL but it is unclear that a provable crime has been committed here
It would seem unlikely this guy would be also logging into peoples boxes after this.
It seems a much tougher job to link something like this to an intentional unauthorized access.
At this point, we have no confirmed access via compromise.
Do you know of a specific case where the existence of a backdoor has been prosecuted without a compromise?
Who would have standing to bring this case? Anyone with a vulnerable machine? Someone with a known unauthorized access. Other maintainers of the repo?
IANAL but it is unclear that a provable crime has been committed here
> 肛门
最好就这样吧。
不值得你或读者花时间试图想出一个技术细节来使我们知之甚少的事情完全合法，除非它极其危险。
法律不是代码，你必须违反一些基本原则才能完成这样的事情并侥幸逃脱惩罚。
是的，如果您只是一名在 GitHub 上进行实验的安全研究人员，那么您应该摆脱它，这是常识*，是的，很难定义一个逻辑证明来诱捕这个人，而不是研究人员。
*是的，我们可以提出另一个假设，安全研究人员不应该逃脱惩罚。假设一直向下。
最好就这样吧。
不值得你或读者花时间试图想出一个技术细节来使我们知之甚少的事情完全合法，除非它极其危险。
法律不是代码，你必须违反一些基本原则才能完成这样的事情并侥幸逃脱惩罚。
是的，如果您只是一名在 GitHub 上进行实验的安全研究人员，那么您应该摆脱它，这是常识*，是的，很难定义一个逻辑证明来诱捕这个人，而不是研究人员。
*是的，我们可以提出另一个假设，安全研究人员不应该逃脱惩罚。假设一直向下。
And of course an attacker like this has a high likelihood of being a state actor, comfortably secure in their native jurisdiction.
I think this thread is talking at cross-purposes.
1. It should be legal to develop or host pen-testing/cracking/fuzzing/security software that can break other software or break into systems. It should be illegal to _use_ the software to gain _unauthorised_ access to others' systems. (e.g. it's legal to create or own lockpicks and use them on your own locks, or locks you've been given permission to pick. It's not legal to gain unauthorised access _using_ lockpicks)
2. It should be illegal to develop malware that _automatically_ gains unauthorised access to systems (trojans, viruses, etc.). However, it should be legal to maintain an archive of malware, limiting access to vetted researchers, so that it can be studied, reverse-engineered and combatted. (e.g. it's illegal to develop or spread a bioweapon, but it's ok for authorised people to maintain samples of a bioweapon in order to provide antidotes or discover what properties it has)
3. What happened today: It should be illegal to intentionally undermine the security of a project by making bad-faith contributions to it that misrepresent what they do... even if you're a security researcher. It could only possibly be allowed done if an agreement was reached in advance with the project leaders to allow such intentional weakness-probing, with a plan to reveal the deception and treachery.
Remember when university researchers tried to find if LKML submissions could be gamed? They didn't tell the Linux kernel maintainers they were doing that. When the Linux kernel maintainers found out, they banned the entire university from making contributions and removed everything they'd done.
https://lkml.org/lkml/2021/4/21/454
https://arstechnica.com/gadgets/2021/04/linux-kernel-team-re...
1. It should be legal to develop or host pen-testing/cracking/fuzzing/security software that can break other software or break into systems. It should be illegal to _use_ the software to gain _unauthorised_ access to others' systems. (e.g. it's legal to create or own lockpicks and use them on your own locks, or locks you've been given permission to pick. It's not legal to gain unauthorised access _using_ lockpicks)
2. It should be illegal to develop malware that _automatically_ gains unauthorised access to systems (trojans, viruses, etc.). However, it should be legal to maintain an archive of malware, limiting access to vetted researchers, so that it can be studied, reverse-engineered and combatted. (e.g. it's illegal to develop or spread a bioweapon, but it's ok for authorised people to maintain samples of a bioweapon in order to provide antidotes or discover what properties it has)
3. What happened today: It should be illegal to intentionally undermine the security of a project by making bad-faith contributions to it that misrepresent what they do... even if you're a security researcher. It could only possibly be allowed done if an agreement was reached in advance with the project leaders to allow such intentional weakness-probing, with a plan to reveal the deception and treachery.
Remember when university researchers tried to find if LKML submissions could be gamed? They didn't tell the Linux kernel maintainers they were doing that. When the Linux kernel maintainers found out, they banned the entire university from making contributions and removed everything they'd done.
https://lkml.org/lkml/2021/4/21/454
https://arstechnica.com/gadgets/2021/04/linux-kernel-team-re...
谈论相互矛盾的目的？
不，人们会保持礼貌并避免使用更直接的答案，否则会让人感觉不好。
我们其他人凭直觉理解这一点，而且情况已经如此，因此假装需要解决这个问题，充其量只能验证一个人的误解。
不太重要，因为这只是烦恼而不是信息危害：它完全偏离主题。即使在这种情况下，安全研究人员在 GitHub 上发布“rm -rf *”并最终陷入法律麻烦的法律假设也是 5 步，这是一种完全不同的情况。当每个人都必须通过假设进行“IANAL”时，情况就更是如此。
不，人们会保持礼貌并避免使用更直接的答案，否则会让人感觉不好。
我们其他人凭直觉理解这一点，而且情况已经如此，因此假装需要解决这个问题，充其量只能验证一个人的误解。
不太重要，因为这只是烦恼而不是信息危害：它完全偏离主题。即使在这种情况下，安全研究人员在 GitHub 上发布“rm -rf *”并最终陷入法律麻烦的法律假设也是 5 步，这是一种完全不同的情况。当每个人都必须通过假设进行“IANAL”时，情况就更是如此。
I'm not looking for a loophole or a legal hypothetical, I'm wondering if our laws are keeping up, which they very often do not with tech.
This is not unauthorized access, but is also clearly wrong. I'm wondering if its illegal, or if its unauthorized access . . .
This is not unauthorized access, but is also clearly wrong. I'm wondering if its illegal, or if its unauthorized access . . .
> but it seems like anyone can publish an exploit on the internet without being a crime
Of course. The mere publishing of the exploit is not the criminal part. Its the manner & intent in which it was published that is the problem.
> At this point, we have no confirmed access via compromise.
While i don't know the specifics for this particular law, generally it doesn't matter what you actually did. What is relavent is what you tried to do. Lack of success doesn't make you innocent.
> Who would have standing to bring this case?
The state obviously. This is a criminal matter not a civil one. You don't even need the victim's consent to bring a case.
[IANAL]
Of course. The mere publishing of the exploit is not the criminal part. Its the manner & intent in which it was published that is the problem.
> At this point, we have no confirmed access via compromise.
While i don't know the specifics for this particular law, generally it doesn't matter what you actually did. What is relavent is what you tried to do. Lack of success doesn't make you innocent.
> Who would have standing to bring this case?
The state obviously. This is a criminal matter not a civil one. You don't even need the victim's consent to bring a case.
[IANAL]
[deleted]
Some types of criminal cases are only pursued on a victim's complaint.
Not this kind!
See for example page 35 in the Justice Department’s computer crimes handbook (dated, but basically AIUI the same way they still do things) [0]
[0] https://www.justice.gov/d9/criminal-ccips/legacy/2015/01/14/...
See for example page 35 in the Justice Department’s computer crimes handbook (dated, but basically AIUI the same way they still do things) [0]
[0] https://www.justice.gov/d9/criminal-ccips/legacy/2015/01/14/...
By this logic you could say that leaving a poisoned can of food in a public pantry is not a crime because poison is legal for academic purposes, and whoever ate it took it willingly.
Also, I think getting malicious code into a repo counts as a compromise in and of itself.
Also, I think getting malicious code into a repo counts as a compromise in and of itself.
Or shooting someone isn't a crime, since you only pulled the trigger. After all it was the bullet that killed them
Are you suggesting intent is impossible to determine?
Similar laws we use to prosecute someone who intentionally brought a poisened cake to the potluck.
Every single commit this person ever did should immediately be rolled back in all projects.
It's weird and disturbing that this isn't the default perspective.
Well, it is much easier said than done. Philosophically I agree, but in the real world where you have later commits that might break and downstream projects, etc, it isn't very practical. It strikes me as in a similar vein to high school students and beauty pageant constestants calling for world peace. Really great goal, not super easy to implement.
I would definitely be looking at every single commit though and if it isn't obviously safe I'd be drilling in.
I would definitely be looking at every single commit though and if it isn't obviously safe I'd be drilling in.
[deleted]
Imagine someone tried to revert all the commits you ever did. Doesn't sound easy.
Some of those commits might fix genuine vulnerabilities. So you might trade a new backdoor for an old vulnerability that thousands of criminal orgs have bots for exploiting.
Damage wise, most orgs aren't going to be hurt much by NSA or the Chinese equivalent getting access, but a Nigerian criminal gang? They're far more likely to encrypt all your files and demand a ransom.
Damage wise, most orgs aren't going to be hurt much by NSA or the Chinese equivalent getting access, but a Nigerian criminal gang? They're far more likely to encrypt all your files and demand a ransom.
Still.. At this point the default assumption should be every commit is a vulnerability or facilitating a potential vulnerability.
For example, change from safe_fprintf to fprintf. It would be appropriate that every commit should be reviewed and either tweaked or re-written to ensure the task is being done in the safest way and doesn't have anything that is "off" or introducing a deviation from the way that codebase standardly goes about tasks within functions.
For example, change from safe_fprintf to fprintf. It would be appropriate that every commit should be reviewed and either tweaked or re-written to ensure the task is being done in the safest way and doesn't have anything that is "off" or introducing a deviation from the way that codebase standardly goes about tasks within functions.
Surely this is happening right now.
A lot of eyes are on the code. From all sides. Folks trying to find old unpatched backdoors to exploit or patch.
A lot of eyes are on the code. From all sides. Folks trying to find old unpatched backdoors to exploit or patch.
it's not weird at all?
randomly reverting two years of things across dozens of repositories will break them, almost definitely make them unbuildable, but also make them unreleasable in case any other change needs to happen soon.
all of their code needs to be audited to prove it shouldn't be deleted, of course, but that can't happen in the next ten minutes.
I swear that HN has the least-thought-through hot takes of any media in the world.
randomly reverting two years of things across dozens of repositories will break them, almost definitely make them unbuildable, but also make them unreleasable in case any other change needs to happen soon.
all of their code needs to be audited to prove it shouldn't be deleted, of course, but that can't happen in the next ten minutes.
I swear that HN has the least-thought-through hot takes of any media in the world.
Yeah if you tried to revert stuff that was
done weeks ago on a relatively small team you know how much painstaking work it can be.
* I swear that HN has the least-thought-through hot takes of any media in the world.*
The irony is too good.
The irony is too good.
Too much fallout.
Hoe will you do that practically though? That’s probably thousands of commits upon which tens or hundred thousand commits from others were built. You can’t just rollback everything two years and expect it not to break or bring back older vulnerabilities that were patched in those commits.
Likely part of what the attacker(s) are counting on. Anyone want to place odds this isn't the only thing that's going to be found?
I’d bet you at even odds that nothing else malicious by this person is found in 1 month, and at 1:2.5 odds that nothing is found in a year.
Only if you consider "this person" to be equal to "this identity".
Rolling back two years worth of commits made by a major contributor is going to be hell. I'm looking forward to see how they'll do this.
Not really. xz worked fine 2 years ago. Roll back to 5.3.1 and apply a fix for the 1 security hole that was fixed since that old version. (ZDI-CAN-16587)
Slight oversimplification, see https://bugs.debian.org/1068024 discussion.
Slight oversimplification, see https://bugs.debian.org/1068024 discussion.
Couldn't the autoconf soup be generated from simpler inputs by the CI/CD system to avoid this kind of problem? Incomprehensible soup as a build artifact (e.g. executables) is perfectly normal, but it seems to me that such things don't belong in the source code.
(This means you too, gradle-wrapper! And your generated wrapper for your generated wrapper. That junk is not source code and doesn't belong in the repo.)
(This means you too, gradle-wrapper! And your generated wrapper for your generated wrapper. That junk is not source code and doesn't belong in the repo.)
Yes, it's usually regenerated already. However even the source is often pretty gnarly.
And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code.
This is also why I like meson, because it's much more constrained than the others and the build system tends to be more modular and the complex parts split across multiple smaller, mostly independent scripts (written in Python or bash, 20-30 lines max). It's still complex, but I find it easier to organize.
And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code.
This is also why I like meson, because it's much more constrained than the others and the build system tends to be more modular and the complex parts split across multiple smaller, mostly independent scripts (written in Python or bash, 20-30 lines max). It's still complex, but I find it easier to organize.
> And in general, the build system of a large project is doing a lot of work and is considered pretty uninteresting and obscure. Random CMake macros or shell scripts would be just as likely to host bad code.
Build systems can even have undefined behaviour in the C++ sense. For example Conan 2 has a whole page on that.
Build systems can even have undefined behaviour in the C++ sense. For example Conan 2 has a whole page on that.
The other thing besides the autoconf soup is the XZ project contains incomprehensible binaries as "test data"; the "bad-3-corrupt_lzma2.xz"
part of the backdoor that they even put in the repo.
It's entirely possible they could have got that injection through review, even if they had that framwork and instead put it in source files used to generate autoconf soup.
It's entirely possible they could have got that injection through review, even if they had that framwork and instead put it in source files used to generate autoconf soup.
gradle-wrapper is just a convenience, you can always just build the project with an installed version of gradle.
Although I get your point, it’s a great place to hide nefarious code.
[deleted]
Pure speculation but my guess is a specific state actor ahem is looking for developers innocently working with open source to then strongarm them into doing stuff like this.
Or hiring them to do it for years without telling them why until they need a favor.
many people are patriots of their countries. if state agency would approach them proposing to have paid OSS work and help their country to fight terrorism/dictatorships/capitalists/whatever-they-believe, they will feel like killing two birds with one job
While this seems plausible, it is notable that this person seems to be anonymous from the get go. Most open source maintainers are proud of their work and maintain publicly available personas.
While I don't doubt there are people who would gladly do this work for money/patriotism/whatever, adding a backdoor to your own project isn't really reconcilable with the motivations behind wanting to do OSS work.
> I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup (and not in "curl | sh" scripts).
Yeah, I've been banging on that same drum for ages too... for example on this very site a decade ago: https://news.ycombinator.com/item?id=7213563
I'm honestly surprised that this autoconf vector hasn't happened more often... or more often that we know of.
Yeah, I've been banging on that same drum for ages too... for example on this very site a decade ago: https://news.ycombinator.com/item?id=7213563
I'm honestly surprised that this autoconf vector hasn't happened more often... or more often that we know of.
Given that this was discovered by sheer luck, I'd expect way more such exploits in the wild.
> they have commits on some related projects like libarchive
Windows started using libarchive to support .rar, .7z, ...
https://arstechnica.com/gadgets/2023/05/cancel-your-winrar-t...
Windows started using libarchive to support .rar, .7z, ...
https://arstechnica.com/gadgets/2023/05/cancel-your-winrar-t...
Yeah this was my first thought too. Though I think the case against autoconf is already so overwhelming I think anyone still using it is just irredeemable; this isn't going to persuade them.
How about wheels in the python ecosystem
> I've long since said that if you want to hide something nefarious you'd do that in the GNU autoconf soup
If I recall correctly, xz can be built with both autoconf and cmake, are cmake configs similarly affected?
If I recall correctly, xz can be built with both autoconf and cmake, are cmake configs similarly affected?
Yes, there is evidence of sabotage on the CMake configs too.
https://git.tukaani.org/?p=xz.git;a=commit;h=f9cf4c05edd14de...
https://git.tukaani.org/?p=xz.git;a=commit;h=f9cf4c05edd14de...
For those panicking, here are some key things to look for, based on the writeup:
- A very recent version of liblzma5 - 5.6.0 or 5.6.1. This was added in the last month or so. If you're not on a rolling release distro, your version is probably older.
- A debian or RPM based distro of Linux on x86_64. In an apparent attempt to make reverse engineering harder, it does not seem to apply when built outside of deb or rpm packaging. It is also specific to Linux.
- Running OpenSSH sshd from systemd. OpenSSH as patched by some distros only pulls in libsystemd for logging functionality, which pulls in the compromised liblzma5.
Debian testing already has a version called '5.6.1+really5.4.5-1' that is really an older version 5.4, repackaged with a newer version to convince apt that it is in fact an upgrade.
It is possible there are other flaws or backdoors in liblzma5, though.
- A very recent version of liblzma5 - 5.6.0 or 5.6.1. This was added in the last month or so. If you're not on a rolling release distro, your version is probably older.
- A debian or RPM based distro of Linux on x86_64. In an apparent attempt to make reverse engineering harder, it does not seem to apply when built outside of deb or rpm packaging. It is also specific to Linux.
- Running OpenSSH sshd from systemd. OpenSSH as patched by some distros only pulls in libsystemd for logging functionality, which pulls in the compromised liblzma5.
Debian testing already has a version called '5.6.1+really5.4.5-1' that is really an older version 5.4, repackaged with a newer version to convince apt that it is in fact an upgrade.
It is possible there are other flaws or backdoors in liblzma5, though.
Ubuntu 仍在 24.03 上提供 5.4.5 版本（目前）。
我对源代码（packages.ubuntu.com 上的.orig 文件）进行了快速对比，发现除了 Changelog 和一些翻译文件外，大部分内容都与 5.4.5 github 标签相符。不过它确实与压缩包的内容一致。
因此，5.4.5 的标签版本和 github 上的下载版本是不同的。
它确实改变了格式字符串，例如
+#: src/xz/args.c:735
+#, fuzzy
+#| msgstr "%s：使用--format=raw，除非写入 stdout，否则必须使用--suffix=.SUF"
+msgid "使用--format=raw，除非写入 stdout，否则必须使用--suffix=.SUF"
+msgstr "%s: amb --format=raw, --suffix=.SUF és necessari si no s'escriu a la sortida estàndard"
例如，printf 没有第二个参数。我认为旧版本的压缩包中至少有一个格式字符串注入。
[编辑] 格式化
我对源代码（packages.ubuntu.com 上的.orig 文件）进行了快速对比，发现除了 Changelog 和一些翻译文件外，大部分内容都与 5.4.5 github 标签相符。不过它确实与压缩包的内容一致。
因此，5.4.5 的标签版本和 github 上的下载版本是不同的。
它确实改变了格式字符串，例如
+#: src/xz/args.c:735
+#, fuzzy
+#| msgstr "%s：使用--format=raw，除非写入 stdout，否则必须使用--suffix=.SUF"
+msgid "使用--format=raw，除非写入 stdout，否则必须使用--suffix=.SUF"
+msgstr "%s: amb --format=raw, --suffix=.SUF és necessari si no s'escriu a la sortida estàndard"
例如，printf 没有第二个参数。我认为旧版本的压缩包中至少有一个格式字符串注入。
[编辑] 格式化
Thanks for the heads up.
RHEL9 is shipping 5.2.5; RHEL8 is on 5.2.4.
仅供参考，您的格式已损坏。 Hacker News 不支持反引号代码块，您必须缩进代码。
无论如何，所以... xz 项目已经被泄露了很长一段时间，至少从 5.4.5 开始。我发现这个 JiaT75 多年来一直是至少 GitHub 版本的主要负责人。我们是否应该将他参与后的所有发布视为可能受到损害？
无论如何，所以... xz 项目已经被泄露了很长一段时间，至少从 5.4.5 开始。我发现这个 JiaT75 多年来一直是至少 GitHub 版本的主要负责人。我们是否应该将他参与后的所有发布视为可能受到损害？
Thank you, formatting fixed.
My TLDR is that I would regard all commits by JiaT75 as potentially compromised.
Given the ability to manipulate gitnhistory I am not sure if a simple time based revert is enough.
It would be great to compare old copies of the repo with the current state. There is no guarantee that the history wasn't tampered with.
Overall the only safe action would IMHO to establish a new upstream from an assumed good state, then fully audit it. At that point we should probably just abandon it and use zstd instead.
My TLDR is that I would regard all commits by JiaT75 as potentially compromised.
Given the ability to manipulate gitnhistory I am not sure if a simple time based revert is enough.
It would be great to compare old copies of the repo with the current state. There is no guarantee that the history wasn't tampered with.
Overall the only safe action would IMHO to establish a new upstream from an assumed good state, then fully audit it. At that point we should probably just abandon it and use zstd instead.
Zstd belongs to the class of speed-optimized compressors providing “tolerable” compression ratios. Their intended use case is wrapping some easily compressible data with negligible (in the grand scale) performance impact. So when you have a server which sends gigabits of text per second, or caches gigabytes of text, or processes a queue with millions of text protocol messages, you can add compression on one side and decompression on the other to shrink them without worrying too much about CPU usage.
Xz is an implant of 7zip's LZMA(2) compression into traditional Unix archiver skeleton. It trades long compression times and giant dictionaries (that need lots of memory) for better (“much-better-than-deflate”) compression ratios. Therefore, zstd, no matter how fashionable that name might be in some circles, is not a replacement for xz.
It should also be noted that those LZMA-based archive formats might not be considered state-of-the-art today. If you worry about data density, there are options for both faster compression at the same size, and better compression in the same amount of time (provided that data is generally compressible). 7zip and xz are widespread and well tested, though, and allow decompression to be fast, which might be important in some cases. Alternatives often decompress much slowly. This is also a trade-off between total time spent on X nodes compressing data, and Y nodes decompressing data. When X is 1, and Y is in the millions (say, software distribution), you can spend A LOT of time compressing even for relatively minuscule gains without affecting the scales.
It should also be noted that many (or most) decoders of top compressing archivers are implemented as virtual machines executing chains of transform and unpack operations defined in archive file over pieces of data also saved there. Or, looking from a different angle, complex state machines initializing their state using complex data in the archive. Compressor tries to find most suitable combination of basic steps based on input data, and stores the result in the archive. (This is logically completed in neural network compression tools which learn what to do with data from data itself.) As some people may know, implementing all that byte juggling safely and effectively is a herculean task, and compression tools had exploits in the past because of that. Switching to a better solution might introduce a lot more potentially exploited bugs.
Xz is an implant of 7zip's LZMA(2) compression into traditional Unix archiver skeleton. It trades long compression times and giant dictionaries (that need lots of memory) for better (“much-better-than-deflate”) compression ratios. Therefore, zstd, no matter how fashionable that name might be in some circles, is not a replacement for xz.
It should also be noted that those LZMA-based archive formats might not be considered state-of-the-art today. If you worry about data density, there are options for both faster compression at the same size, and better compression in the same amount of time (provided that data is generally compressible). 7zip and xz are widespread and well tested, though, and allow decompression to be fast, which might be important in some cases. Alternatives often decompress much slowly. This is also a trade-off between total time spent on X nodes compressing data, and Y nodes decompressing data. When X is 1, and Y is in the millions (say, software distribution), you can spend A LOT of time compressing even for relatively minuscule gains without affecting the scales.
It should also be noted that many (or most) decoders of top compressing archivers are implemented as virtual machines executing chains of transform and unpack operations defined in archive file over pieces of data also saved there. Or, looking from a different angle, complex state machines initializing their state using complex data in the archive. Compressor tries to find most suitable combination of basic steps based on input data, and stores the result in the archive. (This is logically completed in neural network compression tools which learn what to do with data from data itself.) As some people may know, implementing all that byte juggling safely and effectively is a herculean task, and compression tools had exploits in the past because of that. Switching to a better solution might introduce a lot more potentially exploited bugs.
Arch Linux switched switched from xz to zstd, with neglectable increase in size (<1%) but massive speedup on decompression. This is exactly the use case of many people downloading ($$$) and decompressing. It is the software distribution case. Other distributions are following that lead.
You should use ultra settings and >=19 as the compression level. E.g. arch used 20 and higher compression levels do exist, but they were already at a <1% increase.
It does beat xz for these tasks. It's just not the default settings as those are indeed optimized for the lzo to gzip/bzip2 range.
You should use ultra settings and >=19 as the compression level. E.g. arch used 20 and higher compression levels do exist, but they were already at a <1% increase.
It does beat xz for these tasks. It's just not the default settings as those are indeed optimized for the lzo to gzip/bzip2 range.
Note that the xz CLI does not expose all available compression options of the library. E.g. rust release tarballs are xz'd with custom compression settings.
But yeah, zstd is good enough for many uses.
My bad, I was too focused on that class in general, imagining “lz4 and friends”.
Zstd does reach LZMA compression ratios on high levels, but compression times also drop to LZMA level. Which, obviously, was clearly planned in advance to cover both high speed online applications and slow offline compression (unlike, say, brotli). Official limit on levels can also be explained by absence of gains on most inputs in development tests.
Distribution packages contain binary and mixed data, which might be less compressible. For text and mostly text, I suppose that some old style LZ-based tools can still produce an archive roughly 5% percent smaller (and still unpack fast); other compression algorithms can certainly squeeze it much better, but have symmetric time requirements. I was worried about the latter kind being introduced as a replacement solution.
Zstd does reach LZMA compression ratios on high levels, but compression times also drop to LZMA level. Which, obviously, was clearly planned in advance to cover both high speed online applications and slow offline compression (unlike, say, brotli). Official limit on levels can also be explained by absence of gains on most inputs in development tests.
Distribution packages contain binary and mixed data, which might be less compressible. For text and mostly text, I suppose that some old style LZ-based tools can still produce an archive roughly 5% percent smaller (and still unpack fast); other compression algorithms can certainly squeeze it much better, but have symmetric time requirements. I was worried about the latter kind being introduced as a replacement solution.
> the lzo to gzip/bzip2 range
bzip2 is a pig that has no place being in the same sentence as lzo and gzip. It's nieche was maximum compression no matter the speed but it hasn't been relevant even there for a long time.
Yet tools still need to support bzip2 because bzip2 archives are still out there and are still being produced. So we can't get rid of libbz2 anytime soon - same for liblzma.
bzip2 is a pig that has no place being in the same sentence as lzo and gzip. It's nieche was maximum compression no matter the speed but it hasn't been relevant even there for a long time.
Yet tools still need to support bzip2 because bzip2 archives are still out there and are still being produced. So we can't get rid of libbz2 anytime soon - same for liblzma.
期待Meta何时公开https://github.com/facebookincubator/zstrong.git
发现它在 https://github.com/facebook/proxygen/blob/main/build/fbcode_... 中提到，看起来它将是 zstd 的表弟，但也许是为了更强的压缩用例
发现它在 https://github.com/facebook/proxygen/blob/main/build/fbcode_... 中提到，看起来它将是 zstd 的表弟，但也许是为了更强的压缩用例
> Given the ability to manipulate gitnhistory I am not sure if a simple time based revert is enough.
Rewritten history is not a real concern because it would have been immediately noticed by anyone updating an existing checkout.
> Overall the only safe action would IMHO to establish a new upstream from an assumed good state, then fully audit it. At that point we should probably just abandon it and use zstd instead.
This is absurd and also impossible without breaking backwards compatibility all over the place.
Rewritten history is not a real concern because it would have been immediately noticed by anyone updating an existing checkout.
> Overall the only safe action would IMHO to establish a new upstream from an assumed good state, then fully audit it. At that point we should probably just abandon it and use zstd instead.
This is absurd and also impossible without breaking backwards compatibility all over the place.
$ dpkg-query -W liblzma5
liblzma5:amd64 5.4.1-0.2
liblzma5:amd64 5.4.1-0.2
I did notice that my debian-based system got noticeably slower and unresponsive at times the last two weeks, without obvious reasons. Could it be related?
I read through the report, but what wasn't directly clear to me was: what does the exploit actually do?
My normal internet connection has such an appalling upload that I don't think anything relevant could be uploaded. But I will change my ssh keys asap.
I read through the report, but what wasn't directly clear to me was: what does the exploit actually do?
My normal internet connection has such an appalling upload that I don't think anything relevant could be uploaded. But I will change my ssh keys asap.
> I did notice that my debian-based system got noticeably slower and unresponsive at times the last two weeks, without obvious reasons. Could it be related?
Possible but unlikely.
> I read through the report, but what wasn't directly clear to me was: what does the exploit actually do?
It injects code that runs early during sshd connection establishment. Likely allowing remote code execution if you know the right magic to send to the server.
Possible but unlikely.
> I read through the report, but what wasn't directly clear to me was: what does the exploit actually do?
It injects code that runs early during sshd connection establishment. Likely allowing remote code execution if you know the right magic to send to the server.
Thank you for the explanation.
本文提供了一个简单的 shell 脚本的链接，该脚本可检测受损函数的签名。
> 从 systemd 运行 OpenSSH sshd
我认为这无关紧要。
摘自文章：“最初在 systemd 之外启动 sshd 并没有显示出速度减慢，尽管后门被短暂调用。”如果我对整个部分的理解正确的话，从 systemd 启动时 OpenSSH 的行为可能会有所不同，但在这两种情况下都存在后门。
也许某些不使用 systemd 的发行版会从上游 OpenSSH 版本中删除 libxz 代码，但如果有可用的修复程序，我不会打赌它。
> 从 systemd 运行 OpenSSH sshd
我认为这无关紧要。
摘自文章：“最初在 systemd 之外启动 sshd 并没有显示出速度减慢，尽管后门被短暂调用。”如果我对整个部分的理解正确的话，从 systemd 启动时 OpenSSH 的行为可能会有所不同，但在这两种情况下都存在后门。
也许某些不使用 systemd 的发行版会从上游 OpenSSH 版本中删除 libxz 代码，但如果有可用的修复程序，我不会打赌它。
I think the distributions that do use systemd are the ones that add the libsystemd code, which in turn brings in the liblzma5 code. So, it may not be entirely relevant how it is run, but it needs to be a version of OpenSSH patched.
> 摘自文章：“最初在 systemd 之外启动 sshd 并没有显示出速度减慢，尽管后门被短暂调用。”如果我对整个部分的理解正确的话，从 systemd 启动时 OpenSSH 的行为可能会有所不同，但在这两种情况下都存在后门。
看起来，当后门检测到以交互方式启动时，后门就会自行“停用”，就像安全研究人员可能会做的那样。我最终能够绕过这个问题，但除非你这样做，否则交互启动时它不会被激活。
然而，如果您在交互式 shell 的上下文之外使用 shell 脚本（如传统的 sys-v rc 脚本所做的那样）启动后门，后门也会处于活动状态，因为在该上下文中也不会设置 TERM。
> 也许某些不使用 systemd 的发行版会从上游 OpenSSH 版本中删除 libxz 代码，但如果有可用的修复程序，我不会打赌它。
openssh 中没有 xz 代码。
看起来，当后门检测到以交互方式启动时，后门就会自行“停用”，就像安全研究人员可能会做的那样。我最终能够绕过这个问题，但除非你这样做，否则交互启动时它不会被激活。
然而，如果您在交互式 shell 的上下文之外使用 shell 脚本（如传统的 sys-v rc 脚本所做的那样）启动后门，后门也会处于活动状态，因为在该上下文中也不会设置 TERM。
> 也许某些不使用 systemd 的发行版会从上游 OpenSSH 版本中删除 libxz 代码，但如果有可用的修复程序，我不会打赌它。
openssh 中没有 xz 代码。
> 也许某些不使用 systemd 的发行版会从上游 OpenSSH 版本中删除 libxz 代码，但如果有可用的修复程序，我不会打赌它。
OpenSSH 是由 OpenBSD 项目开发的，systemd 与 OpenBSD 不兼容。上游项目没有要删除的 systemd 或 liblzma 代码。如果您的 sshd 二进制文件链接到 liblzma，那是因为您的发行版的软件包维护者不遗余力地将 systemd 的补丁添加到您的 sshd 二进制文件中。
> 摘自文章：“最初在 systemd 之外启动 sshd 并没有显示出速度减慢，尽管后门被短暂调用。”如果我对整个部分的理解正确的话，从 systemd 启动时 OpenSSH 的行为可能会有所不同，但在这两种情况下都存在后门。
据我了解，后门会检测它是否处于少数不同的调试环境中的任何一个中。如果它处于调试环境中或者不是由 systemd 启动的，它不会自行连接。 （“这里没什么可看的，伙计们……”）但是，如果 sshd 一开始就没有链接到 liblzma，则后门的代码甚至都不存在于进程的页面映射中。
当然，我仍在降级到不受影响的版本，但很高兴知道我从来不会仅仅通过输入“ldd `which sshd”而不会看到 liblzma.so 就容易受到攻击。
OpenSSH 是由 OpenBSD 项目开发的，systemd 与 OpenBSD 不兼容。上游项目没有要删除的 systemd 或 liblzma 代码。如果您的 sshd 二进制文件链接到 liblzma，那是因为您的发行版的软件包维护者不遗余力地将 systemd 的补丁添加到您的 sshd 二进制文件中。
> 摘自文章：“最初在 systemd 之外启动 sshd 并没有显示出速度减慢，尽管后门被短暂调用。”如果我对整个部分的理解正确的话，从 systemd 启动时 OpenSSH 的行为可能会有所不同，但在这两种情况下都存在后门。
据我了解，后门会检测它是否处于少数不同的调试环境中的任何一个中。如果它处于调试环境中或者不是由 systemd 启动的，它不会自行连接。 （“这里没什么可看的，伙计们……”）但是，如果 sshd 一开始就没有链接到 liblzma，则后门的代码甚至都不存在于进程的页面映射中。
当然，我仍在降级到不受影响的版本，但很高兴知道我从来不会仅仅通过输入“ldd `which sshd”而不会看到 liblzma.so 就容易受到攻击。
> Debian testing already has a version called '5.6.1+really5.4.5-1' that is really an older version 5.4, repackaged with a newer version to convince apt that it is in fact an upgrade.
I'm surprised .deb doesn't have a better approach. RPM has epoch for this purpose http://novosial.org/rpm/epoch/index.html
I'm surprised .deb doesn't have a better approach. RPM has epoch for this purpose http://novosial.org/rpm/epoch/index.html
Debian packages can have epochs too. I’m not sure why the maintainers haven’t just bumped the epoch here.
Maybe they’re expecting a 5.6.x release shortly that fixes all these issues & don’t want to add an epoch for a very short term packaging issue?
Maybe they’re expecting a 5.6.x release shortly that fixes all these issues & don’t want to add an epoch for a very short term packaging issue?
.deb has epochs too, but I think Debian developers avoid it where possible because 1:5.4.5 is interpreted as newer than anything without a colon, so it would break eg. packages that depend on liblzma >= 5.0, < 6. There may be more common cases that aren't coming to mind now.
Seems like debian is mixing too many things into the package version - version used for deciding on upgrades and abi version for dependencies should be decoupled like it is in modern RPM distros.
If a binary library ABI is backwards-incompatible, they change the package name. I was just guessing at the reason epoch is avoided and that <6 is probably an awful example.
So now I actually bothered to look it up, and it turns out the actual reason is that the epoch changes what version is considered "greater", but it's not part of the .deb filename, so you still can't reuse version numbers used in the past. If you release 5.0, then 5.1, then you want to rollback and release 1:5.0, it's going to break things in the Debian archives. https://www.debian.org/doc/debian-policy/ch-binary.html#uniq...
Additionally, once you add an epoch you're stuck with it forever, while if you use 5.1+really5.0, you can get rid of the kludge when 5.2 is out. https://www.debian.org/doc/debian-policy/ch-controlfields.ht...
So now I actually bothered to look it up, and it turns out the actual reason is that the epoch changes what version is considered "greater", but it's not part of the .deb filename, so you still can't reuse version numbers used in the past. If you release 5.0, then 5.1, then you want to rollback and release 1:5.0, it's going to break things in the Debian archives. https://www.debian.org/doc/debian-policy/ch-binary.html#uniq...
Additionally, once you add an epoch you're stuck with it forever, while if you use 5.1+really5.0, you can get rid of the kludge when 5.2 is out. https://www.debian.org/doc/debian-policy/ch-controlfields.ht...
Debian has epochs, but it's a bad idea to use them for this purpose.
Two reasons:
1. Once you bump the epoch, you have to use it forever. 2. The deb filename often doesn't contain the epoch (we use a colon which isn't valid on many filesystems), so an epoch-revert will give the same file name as pre-epoch, which breaks your repository.
So, the current best practice is the +really+ thing.
Two reasons:
1. Once you bump the epoch, you have to use it forever. 2. The deb filename often doesn't contain the epoch (we use a colon which isn't valid on many filesystems), so an epoch-revert will give the same file name as pre-epoch, which breaks your repository.
So, the current best practice is the +really+ thing.
Got this on OpenSUSE: `5.6.1.revertto5.4-3.2`
Honestly, the Gentoo-style global blacklist (package.mask) to force a downgrade is probably a better approach for cases like this. Epochs only make sense if your upstream is insane and does not follow a consistent numbering system.
Gentoo also considers the repository (+overlays) to be the entire set of possible versions so simply removing the bad version will cause a downgrade, unlike debian and RPM systems where installing packages outside a repository is supported.
Thanks for the info, the filename thing sounds like a problem, one aspect of the epoch system doesn't work for the purpose then.
Stop the cap your honor. There is not a single filesystem that prevents you from using colons in filenames except exfat, I went ahead and checked and ext4, xfs, btrfs, zfs, and even reiserfs let you use any characters you want except \0 and /.
And I fail to see why bumping the epoch would ever be a problem. Using the epoch not a reason why its bad.
And I fail to see why bumping the epoch would ever be a problem. Using the epoch not a reason why its bad.
I really like the XBPS way of the reverts keyword in the package template that forces a downgrade from said software version. It's simple but works without any of the troubles RPM epochs have with resolving dependencies as it's just literally a way to tell xbps-install that "yeah, this is a lower version number in the repository but you should update anyway".
[deleted]
> If you're not on a rolling release distro, your version is probably older.
Ironic considering security is often advertised as a feature of rolling release distros. I suppose in most instances it does provide better security, but there are some advantages to Debian's approach (stable Debian, that is).
Ironic considering security is often advertised as a feature of rolling release distros. I suppose in most instances it does provide better security, but there are some advantages to Debian's approach (stable Debian, that is).
>Ironic considering security is often advertised as a feature of rolling release distros.
Security is a feature of rolling release. But supply-chain attacks like this are the exception to the rule.
Security is a feature of rolling release. But supply-chain attacks like this are the exception to the rule.
Isn't that what security-updates-only is for?
This particular backdoor is not shipped inside of a security patch, right?
This particular backdoor is not shipped inside of a security patch, right?
i mean, rolling implies rolling 0-days, too.
Focusing on sshd is the wrong approach. The backdoor was in liblzma5. It was discovered to attack sshd, but it very likely had other targets as well. The payload hasn't been analyzed yet, but _almost everything_ links to libzma5. Firefox and Chromium do. Keepassxc does. And it might have made arbitrary changes to your system, so installing the security update might not remove the backdoor.
From what I'm understanding it's trying to patch itself into the symbol resolution step of ld.so specifically for libcrypto under systemd on x86_64. Am I misreading the report?
That's a strong indication it's targeting sshd specifically.
That's a strong indication it's targeting sshd specifically.
Lots of software links both liblzma and libcrypto. As I read Andres Freund's report, there is still a lot of uncertainty:
"There's lots of stuff I have not analyzed and most of what I observed is purely from observation rather than exhaustively analyzing the backdoor code."
"There are other checks I have not fully traced."
"There's lots of stuff I have not analyzed and most of what I observed is purely from observation rather than exhaustively analyzing the backdoor code."
"There are other checks I have not fully traced."
As mentioned many times in other places now, this account had control over xz code for 2 years. The discovered CVE might be just a tip of an iceberg.
It checks for argv[0] == "sshd"
Tumbleweed has a package: liblzma5-5.6.1.revertto5.4-3.2.x86_64 FYI
revertto probably just means "revert to" but it does sound quite italian lol.
[deleted]
提交这些补丁的用户的最新提交奇怪地简化了安全报告过程，不要求太多细节：
https://github.com/tukaani-project/xz/commit/af071ef7702debe...
不知道该怎么做。
https://github.com/tukaani-project/xz/commit/af071ef7702debe...
不知道该怎么做。
Potentially the purpose is that if someone goes to the effort to get those details together, they are more likely to send the same report to other trusted individuals. Maybe it was originally there to add legitimacy, then they got a report sent in, and removed it to slow the spread of awareness
> Affected versions of XZ Utils
Most people, to find the affected versions, would either have to bisect or delve deep enough to find the offending commit. Either of which would reveal the attacker.
By not asking for the version, there is a good chance you just report "It's acting oddly, plz investigate".
Most people, to find the affected versions, would either have to bisect or delve deep enough to find the offending commit. Either of which would reveal the attacker.
By not asking for the version, there is a good chance you just report "It's acting oddly, plz investigate".
I think the reason is pretty obvious. They want you to waste more time after you've submitted the security report and maximize the amount of back and forth. Basically the hope is that they'd be able to pester you with requests for more info/details in order to "resolve the issue" which would give them more time to exploit their targets.
该存储库现已禁用。 但这里对 tukaani-project 的 .github 存储库从 @JiaT75 到错误报告模板进行了类似的更改：
+ 或者创建一个私人安全建议。
在标题为“在问题模板 .yaml 文件上换行文本”的提交下。
[1] https://github.com/tukaani-project/.github/commit/44b766adc4...
+ 或者创建一个私人安全建议。
在标题为“在问题模板 .yaml 文件上换行文本”的提交下。
[1] https://github.com/tukaani-project/.github/commit/44b766adc4...
[deleted]
Yikes! Do you have any info on the individual's background or possible motivations?
Yikes indeed. This fix is being rolled out very fast, but what about the entire rest of the codebase? And scripts? I mean, years of access? I'd trust no aspect of this code until a full audit is done, at least of every patch this author contributed.
(note: not referring to fedora here, a current fix is required. But just generally. As in, everyone is rolling out this fix, but... I mean, this codebase is poison in my eyes without a solid audit)
(note: not referring to fedora here, a current fix is required. But just generally. As in, everyone is rolling out this fix, but... I mean, this codebase is poison in my eyes without a solid audit)
似乎就是这个账户，如果错了请纠正我（链接自安全电子邮件的提交链接）：
https://github.com/JiaT75
我希望所有这些项目的作者都能得到提醒。
STest - C/C++ 的单元测试框架。只需将 stest.c 和 stest.h 放入项目中即可轻松使用！
libarchive/libarchive - 多格式归档与压缩库
Seatest - 基于 C 语言的简单单元测试
该账户所做的一切都值得研究。
哇哈，这是合法的还是谷歌的某种骗局？
https://github.com/google/oss-fuzz/pull/11587
编辑：我一定是漏掉了什么，或者我搞糊涂了。 上述作者似乎是 xz 的主要联系人？ 他们刚刚接手了吗？ 还是坏的提交来自其他来源，然后由一个合法的人应用了它？
我有点糊涂了。
https://github.com/JiaT75
我希望所有这些项目的作者都能得到提醒。
STest - C/C++ 的单元测试框架。只需将 stest.c 和 stest.h 放入项目中即可轻松使用！
libarchive/libarchive - 多格式归档与压缩库
Seatest - 基于 C 语言的简单单元测试
该账户所做的一切都值得研究。
哇哈，这是合法的还是谷歌的某种骗局？
https://github.com/google/oss-fuzz/pull/11587
编辑：我一定是漏掉了什么，或者我搞糊涂了。 上述作者似乎是 xz 的主要联系人？ 他们刚刚接手了吗？ 还是坏的提交来自其他来源，然后由一个合法的人应用了它？
我有点糊涂了。
The concern about other projects is fine, but let's be careful with attacks directed at the person.
Maybe their account is compromised, maybe the username borrows the identity of an innocent person with the same name.
Focus on the code, not people. No point forming a mob.
(e: post above was edited and is no longer directed at the person. thanks for the edit.)
Maybe their account is compromised, maybe the username borrows the identity of an innocent person with the same name.
Focus on the code, not people. No point forming a mob.
(e: post above was edited and is no longer directed at the person. thanks for the edit.)
[deleted]
It's important to focus on people, not just code, when suspecting an adversary. Now, I have no idea if this is the right account, and if it has recently been compromised/sold/lost, or if it has always been under the ownership of the person who committed the backdoor. But IF this is indeed the right account, then it's important to block any further commit from it to any project, no matter how innocuous it seems, and to review thoroughly any past commit. For the most security-conscious projects, it would be a good idea to even consider reverting and re-implementing any work coming from this account if it's not fully understood.
An account that has introduced a backdoor is not the same thing as an account who committed a bug.
An account that has introduced a backdoor is not the same thing as an account who committed a bug.
I agree we should look at the account and its contributions, I make a distinction between the account and the person.
Sometimes the distinction is not meaningful, but better safe than sorry.
Sometimes the distinction is not meaningful, but better safe than sorry.
Oh, agreed then.
They appear to have moved carefully to set this up over the course of weeks by setting up the framework to perform this attack.
I would now presume this person to be a hostile actor and their contributions anywhere and everywhere must be audited. I would not wait for them to cry 'but my bother did it', because an actual malicious actor would say the same thing. The 'mob' should be pouring over everything they've touched.
Audit now and audit aggressively.
I would now presume this person to be a hostile actor and their contributions anywhere and everywhere must be audited. I would not wait for them to cry 'but my bother did it', because an actual malicious actor would say the same thing. The 'mob' should be pouring over everything they've touched.
Audit now and audit aggressively.
我上面的帖子显示 xz 的主域从 tukaani.org 转移到 xz.tukaani.org。 虽然它托管在 github 上：
$ 主机 xz.tukaani.org
主机 xz.tukaani.org 是 tukaani-project.github.io 的别名。
原来它不是：
$ 主机 tukaani.org
tukaani.org 的地址为 5.44.245.25
（貌似是在芬兰）
根据我上一篇文章中列出的提交，它于今年一月移至那里。 由同一个人/帐户。 这意味着直接受不受信任帐户控制的帐户现在可以编辑网页，而无需任何其他人的参与，而不是 Lasse Collin 的限制性更强的网页。
例如，对向何处报告安全问题等进行细微更改。
到目前为止，我没有看到任何邪恶的东西，但与此同时，这不是也托管着不良 tarball 的域/页面吗？
$ 主机 xz.tukaani.org
主机 xz.tukaani.org 是 tukaani-project.github.io 的别名。
原来它不是：
$ 主机 tukaani.org
tukaani.org 的地址为 5.44.245.25
（貌似是在芬兰）
根据我上一篇文章中列出的提交，它于今年一月移至那里。 由同一个人/帐户。 这意味着直接受不受信任帐户控制的帐户现在可以编辑网页，而无需任何其他人的参与，而不是 Lasse Collin 的限制性更强的网页。
例如，对向何处报告安全问题等进行细微更改。
到目前为止，我没有看到任何邪恶的东西，但与此同时，这不是也托管着不良 tarball 的域/页面吗？
> tukaani.org has address 5.44.245.25 (seemingly in Finland)
Hetzner?
Hetzner?
No:
route: 5.44.240.0/21
descr: Zoner Oy
origin: AS201692
mnt-by: MNT-ZONER
created: 2014-09-03T08:09:00Z
last-modified: 2014-09-03T08:09:00Z
source: RIPEInteresting, seems to be a tiny finnish hosting company: https://www.zoner.fi/english/
It's Finnish, Oy is short for "Osake Yhtiö" (share-association, basically a LLC), seems to be registered/hosted at https://www.zoner.fi/
So probably Suojelupoliisi, Finnish Security and Intelligence Service is behind all this
Zoner is a Finnish web hosting company, which has a history of providing hosting for Finnish open source projects, and the original maintainer (and most of the original crew) is Finnish as well. Nothing weird here.
For what it's worth, tukaani is how you spell toucan (the bird) in Finnish, and Lasse is a common Finnish name; the site being previously hosted in Finland is very plausible.
[deleted]
Yeah according to their website[0] it looks like majority of the past contributors were Finnish so nothing odd about the hosting provider. On the same page it says that Jia Tan became co-maintainer of xz in 2022.
0: https://tukaani.org/about.html
0: https://tukaani.org/about.html
该帐户将 xz github 中报告安全问题的说明更改为最后一次提交：
提交 af071ef7702debef4f1d324616a0137a5001c14c （HEAD -> master、origin/master、origin/HEAD）
作者：贾谭<[email protected]>
日期：2024 年 3 月 26 日星期二 01:50:02 +0800
文档：简化 SECURITY.md。
diff --git a/.github/SECURITY.md b/.github/SECURITY.md
索引 e9b3458a..9ddfe8e9 100644
---a/.github/SECURITY.md
+++ b/.github/SECURITY.md
@@ -16,13 +16,7 @@ 在补丁发布之前利用该漏洞的机会。
您可以通过发送电子邮件给我们来提交报告：
[[email protected]](mailto:[email protected])，或通过
[安全建议](https://github.com/tukaani-project/xz/security/advisories/new)。
- 虽然这两个选项都可用，但我们更喜欢电子邮件。无论如何，请
- 提供漏洞的清晰描述，包括：
-
-- 受影响的 XZ Utils 版本
-- 估计的严重性（低、中、高、严重）
-- 重现漏洞的步骤
-- 所有相关文件（核心转储、构建日志、输入文件等）
+虽然这两个选项都可用，但我们更喜欢电子邮件。
该项目由一组志愿者以合理的努力维护
基础。因此，请给我们 90 天的时间来修复问题
看起来无害，但也许他们正在计划进一步的改变。
提交 af071ef7702debef4f1d324616a0137a5001c14c （HEAD -> master、origin/master、origin/HEAD）
作者：贾谭<[email protected]>
日期：2024 年 3 月 26 日星期二 01:50:02 +0800
文档：简化 SECURITY.md。
diff --git a/.github/SECURITY.md b/.github/SECURITY.md
索引 e9b3458a..9ddfe8e9 100644
---a/.github/SECURITY.md
+++ b/.github/SECURITY.md
@@ -16,13 +16,7 @@ 在补丁发布之前利用该漏洞的机会。
您可以通过发送电子邮件给我们来提交报告：
[[email protected]](mailto:[email protected])，或通过
[安全建议](https://github.com/tukaani-project/xz/security/advisories/new)。
- 虽然这两个选项都可用，但我们更喜欢电子邮件。无论如何，请
- 提供漏洞的清晰描述，包括：
-
-- 受影响的 XZ Utils 版本
-- 估计的严重性（低、中、高、严重）
-- 重现漏洞的步骤
-- 所有相关文件（核心转储、构建日志、输入文件等）
+虽然这两个选项都可用，但我们更喜欢电子邮件。
该项目由一组志愿者以合理的努力维护
基础。因此，请给我们 90 天的时间来修复问题
看起来无害，但也许他们正在计划进一步的改变。
> Seems innocuous, but maybe they were planning further changes.
Seems like an attempt to get 90 days of "use" of this vulnerability after discovery. If they only had checked performance before!
Seems like an attempt to get 90 days of "use" of this vulnerability after discovery. If they only had checked performance before!
No, they just removed the bullet points about what to include in a report. The 90 days part was in both versions.
网站的更改让我想起了 lbzip2.org https://github.com/kjn/lbzip2/issues/26#issuecomment-1582645...尽管目前看来只是垃圾邮件。最后一次提交是 6 年前，所以我想这比维护者更改更好......
[deleted]
If the owner of the account is innocent and their account was compromised, it's on them to come out and say that. All signs currently point to the person being a malicious actor, so I'll proceed on that assumption.
Does the person exist at all? Maybe they're a persona of a team working at some three letter agency...
Or for some three letter party.
可能不会。我对他们的电子邮件/其他标识符进行了一些生活模式分析。它看起来和我设置刻录机在线身份时一模一样——足以通过平台注册，但他们并没有足够关心让它看起来真实。
例如，他们的电子邮件仅注册到 GitHub 和 Twitter。他们甚至已经快一年没有登录谷歌帐户了。也没有任何数据泄露的历史（因为他们从不使用它）。
烧死女巫。
例如，他们的电子邮件仅注册到 GitHub 和 Twitter。他们甚至已经快一年没有登录谷歌帐户了。也没有任何数据泄露的历史（因为他们从不使用它）。
烧死女巫。
It would be interesting to hear the whole arc of social engineering behind getting access to the repo. Although, as a maintainer of a large-ish OSS project myself, I know that under a lot of burden any help will be welcomed with open arms, and I've never really talked about private stuff with any of them.
did you find the Twitter account associated to Jia's email?
[deleted]
Found it by myself! https://twitter.com/JiaT03868010
哦不，不是 libarchive！ GitHub 搜索显示 2021 年合并了 6 个拉取请求。
https://github.com/search?q=repo%3Alibarchive%2Flibarchive+j...
不过看起来确实够无辜的。希望没有涉及 unicode 欺骗......
https://github.com/search?q=repo%3Alibarchive%2Flibarchive+j...
不过看起来确实够无辜的。希望没有涉及 unicode 欺骗......
也许不是。他们在这里删除了 safe_fprintf() 并将其替换为（不安全的）fprintf()。
https://github.com/libarchive/libarchive/commit/e37efc16c866...
https://github.com/libarchive/libarchive/commit/e37efc16c866...
If libarchive is also backdoored, would that allow specifically crafted http gzip encoded responses to do bad things?
What software is using libarchive to decode HTTP responses?
I don't know, way outside my domain. Possibly none I guess?
FreeBSD's archive tools are built on top of libarchive IIRC. Not sure about the other BSDs.
Well for one, the Powershell script I just wrote to build all the 3rd-party library dependencies for a video game.
tar.exe was added to Windows this January, sourced from libarchive: https://learn.microsoft.com/en-us/virtualization/community/t...
Unlike the GNU tar I'm used to, it's actually a "full fat" command line archiving tool, compressing & decompressing zip, xz, bz2 on the command-line - really handy :-O
tar.exe was added to Windows this January, sourced from libarchive: https://learn.microsoft.com/en-us/virtualization/community/t...
Unlike the GNU tar I'm used to, it's actually a "full fat" command line archiving tool, compressing & decompressing zip, xz, bz2 on the command-line - really handy :-O
No. There's no good reason HTTP response decoding would ever be implemented in terms of libarchive; using libz directly is simpler and supports some use cases (like streaming reads) which libarchive doesn't.
编辑：啊，我错了，错过了添加“strerror”
公关是相当狡猾的。
JiaT75 声称“在解包时添加了打印警告时的错误文本和 bsdtar 中的错误。以前，存在神秘的错误消息”，并引用此内容来修复之前的问题。
https://github.com/libarchive/libarchive/pull/1609
然而它实际上并没有这样做！
PR 从字面上删除了第一个“safe_fprintf()”调用中 2 个参数之间的新行，并将“safe_fprintf()”转换为对“fprintf()”的不安全直接调用。在所有情况下，这些函数的参数都是完全相同的！因此，它实际上并没有使错误消息有任何不同，它实际上并没有解决它引用的问题。维护者接受了它，没有任何评论！
公关是相当狡猾的。
JiaT75 声称“在解包时添加了打印警告时的错误文本和 bsdtar 中的错误。以前，存在神秘的错误消息”，并引用此内容来修复之前的问题。
https://github.com/libarchive/libarchive/pull/1609
然而它实际上并没有这样做！
PR 从字面上删除了第一个“safe_fprintf()”调用中 2 个参数之间的新行，并将“safe_fprintf()”转换为对“fprintf()”的不安全直接调用。在所有情况下，这些函数的参数都是完全相同的！因此，它实际上并没有使错误消息有任何不同，它实际上并没有解决它引用的问题。维护者接受了它，没有任何评论！
But I see the "strerror" call is added
reread it...
It does remove the safe prefixes... But it also adds one print statement to "strerror()", which could plausibly give better explanations for the error code...
The only suspicious thing here is the lack for safe_ prefix (and the potential for the strerror() function to already be backdoored elsewhere in another commit)
It does remove the safe prefixes... But it also adds one print statement to "strerror()", which could plausibly give better explanations for the error code...
The only suspicious thing here is the lack for safe_ prefix (and the potential for the strerror() function to already be backdoored elsewhere in another commit)
[deleted]
That seems to be fine. safe_fprintf() takes care of non-printable characters. It's used for archive_entry_pathname, which can contain them, while "unsafe" fprintf is used to print out archive_error_string, which is a library-provided error string, and strerror(errno) from libc.
We know there's long-cons in action here, though. This PR needn't be the exploit. It needn't be anywhere _temporally_ close to the exploit. It could just be laying groundwork for later pull requests by potentially different accounts.
Exactly. If we assume the backdoor via liblzma as a template, this could be a ploy to hook/detour both fprintf and strerror in a similar way. Get it to diffuse into systems that rely on libarchive in their package managers.
When the trap is in place deploy a crafted package file that appears invalid on the surface level triggers this trap. In that moment fetch the payload from the (already opened) archive file descriptor, execute it, but also patch the internal state of libarchive so that it will process the rest of the archive file as if nothing happened, and the desired outcome also appearing in the system.
When the trap is in place deploy a crafted package file that appears invalid on the surface level triggers this trap. In that moment fetch the payload from the (already opened) archive file descriptor, execute it, but also patch the internal state of libarchive so that it will process the rest of the archive file as if nothing happened, and the desired outcome also appearing in the system.
Assuming there isn't another commit somewhere modifying a library-provided error string or anything returned by libc. There is all kinds of mischief to be had there, which may or may not have already happened, e.g. now you do some i18n and introduce Unicode shenanigans.
That looks like a repo that would sound alarms if you look at it from a security standpoint.
JiaT75 also has commits in wasmtime according to https://hachyderm.io/@joeyh/112180082372196735
per https://hachyderm.io/@bjorn3/112180226784517099, "The only contribution by them to Wasmtime is a doc change. No actual code or binary blobs have been changed by them."
幸运的是，只是更改了文档：
https://github.com/bytecodealliance/wasmtime/commits?author=...
他们也向其他项目提交了一些文档调整；例如：
https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp...
我不知道这是一个以前合法的开源贡献者后来变得流氓，还是一个深藏不露的人物，将看似无害的文档更改作为烟幕弹传播到其他项目。
https://github.com/bytecodealliance/wasmtime/commits?author=...
他们也向其他项目提交了一些文档调整；例如：
https://learn.microsoft.com/en-us/cpp/overview/whats-new-cpp...
我不知道这是一个以前合法的开源贡献者后来变得流氓，还是一个深藏不露的人物，将看似无害的文档更改作为烟幕弹传播到其他项目。
较小的文档更改 PR 是一种众所周知的策略，用于使您的 GitHub 个人资料看起来更好（尤其是对潜在雇主而言）。
他可能出于其他原因做同样的事情；没有人真正深入研究任何东西，所以我可以看到有人基于看起来不错的 Github 图表和一些合理性将共同维护移交给了一个项目。
他可能出于其他原因做同样的事情；没有人真正深入研究任何东西，所以我可以看到有人基于看起来不错的 Github 图表和一些合理性将共同维护移交给了一个项目。
Consider the possibility those type of submissions were part of the adversary's strategy in order to make their account appear more legitimate rather than appearing out of nowhere wanting to become the maintainer of some project.
> 上述作者似乎是xz 的主要联系人？
大约一年前，他们使自己成为 Google oss-fuzz 的 xz 的主要联系人：https://github.com/google/oss-fuzz/commit/6403e93344476972e9...
大约一年前，他们使自己成为 Google oss-fuzz 的 xz 的主要联系人：https://github.com/google/oss-fuzz/commit/6403e93344476972e9...
像这样的 SourceGraph 搜索显示 https://sourcegraph.com/search?q=context:global+JiaT75&patte...
- 谭嘉<[email protected]>
- jiat75 <[email protected]>
````
amap =generate_author_map("xz")
test_author = amap.get_author_by_name("Jia Cheong Tan")
self.assertEqual(
test_author.names, {"Jia Cheong Tan", "Jia Tan", "jiat75"}
）
self.assertEqual(
test_author.mail_addresses，
{"[email protected]", "[email protected]"}
）
````
- 谭嘉<[email protected]>
- jiat75 <[email protected]>
````
amap =generate_author_map("xz")
test_author = amap.get_author_by_name("Jia Cheong Tan")
self.assertEqual(
test_author.names, {"Jia Cheong Tan", "Jia Tan", "jiat75"}
）
self.assertEqual(
test_author.mail_addresses，
{"[email protected]", "[email protected]"}
）
````
additionally, even though the commit messages they've made are mostly plain, there may be features of their commit messages that could provide leads, such as his using what looks like a very obscure racist joke of referring to a gitignore file as a 'gitnigore'.
There's barely a handful of people on the whole planet making this 'joke'.
Can you point to where you saw that racist joke?
I don't see anything at https://sourcegraph.com/search?q=context:global+author:jiat0...
I don't see anything at https://sourcegraph.com/search?q=context:global+author:jiat0...
在 JiaT75 的其他存储库中进行的第一次提交 https://github.com/JiaT75/STest/commits/master/
Thank you. If you wouldn't have explained the background, I totally would've thought that this is just an innocent typo.
(I still think it's like... 60% a typo? don't know)
Anyhow, other people called the CCing of JiaT75 by Lasse suspicious:
https://news.ycombinator.com/item?id=39867593
https://lore.kernel.org/lkml/20240320183846.19475-2-lasse.co...
Someone pointed out the "mental health issues" and "some other things"
https://news.ycombinator.com/item?id=39868881
https://www.mail-archive.com/[email protected]/msg00567.h...
Lasse is of course a Nordic name, and the whole project has a finnish name and hosting
https://news.ycombinator.com/item?id=39866902
If I wanted to go rogue and insert a backdoor in a project of mine, I'd probably create a new sockpuppet account and hand over management of the project to them. The above is worringly compatible with this hypothesis.
OTOH, JiaT75 did not reuse the existing hosting provider, but rather switched the site to github.io and uploaded there old tarballs:
https://github.com/tukaani-project/tukaani-project.github.io...
If JiaT75 is an old-timer in the project, wouldn't they have kept using the same hosting infra?
There are also some other grim possibilities: someone forced Lasse to hand over the project (violence or blackmailing? as farfetched as that sounds)... or maybe stole Lasse devices (and identity?) and now Lasse is incapacitated?
Or maybe it's just some other fellow scandinavian who pretended to be chinese and got Lasse's trust. In which case I wish Lasse all the best, and hope they'll be able to clear their name.
Is the same person sockpuppeting Hans Jansen? It's amusing (but unsurprising) that they are using both german-sounding and chinese-sounding identities.
That said, I don't think it's unreasonable to think that Lasse genuinely trusted JiaT75, genuinely believed that the ifunc stuff was reasonable (it probably isn't: https://news.ycombinator.com/item?id=39869538 ) and handed over the project to them.
And at the end of the day, the only thing linking JiaT75 to a nordic identity is a nordic racist joke which could well be a typo. People already checked the timezone of the commits, but I wonder if anyone has already checked the time-of-day of those commits... does it actually match the working hours that a person genuinely living (and sleeping) in China would follow? (of course, that's also easy to manipulate, but maybe they could've slip up)
Anyhow, I guess that security folks at Microsoft and Google (because of JiaT75 email account) are probably going to cooperate with authorities on trying to pin down the identity of JiaT75 (which might not be very useful, depending on where they live).
(I still think it's like... 60% a typo? don't know)
Anyhow, other people called the CCing of JiaT75 by Lasse suspicious:
https://news.ycombinator.com/item?id=39867593
https://lore.kernel.org/lkml/20240320183846.19475-2-lasse.co...
Someone pointed out the "mental health issues" and "some other things"
https://news.ycombinator.com/item?id=39868881
https://www.mail-archive.com/[email protected]/msg00567.h...
Lasse is of course a Nordic name, and the whole project has a finnish name and hosting
https://news.ycombinator.com/item?id=39866902
If I wanted to go rogue and insert a backdoor in a project of mine, I'd probably create a new sockpuppet account and hand over management of the project to them. The above is worringly compatible with this hypothesis.
OTOH, JiaT75 did not reuse the existing hosting provider, but rather switched the site to github.io and uploaded there old tarballs:
https://github.com/tukaani-project/tukaani-project.github.io...
If JiaT75 is an old-timer in the project, wouldn't they have kept using the same hosting infra?
There are also some other grim possibilities: someone forced Lasse to hand over the project (violence or blackmailing? as farfetched as that sounds)... or maybe stole Lasse devices (and identity?) and now Lasse is incapacitated?
Or maybe it's just some other fellow scandinavian who pretended to be chinese and got Lasse's trust. In which case I wish Lasse all the best, and hope they'll be able to clear their name.
Is the same person sockpuppeting Hans Jansen? It's amusing (but unsurprising) that they are using both german-sounding and chinese-sounding identities.
That said, I don't think it's unreasonable to think that Lasse genuinely trusted JiaT75, genuinely believed that the ifunc stuff was reasonable (it probably isn't: https://news.ycombinator.com/item?id=39869538 ) and handed over the project to them.
And at the end of the day, the only thing linking JiaT75 to a nordic identity is a nordic racist joke which could well be a typo. People already checked the timezone of the commits, but I wonder if anyone has already checked the time-of-day of those commits... does it actually match the working hours that a person genuinely living (and sleeping) in China would follow? (of course, that's also easy to manipulate, but maybe they could've slip up)
Anyhow, I guess that security folks at Microsoft and Google (because of JiaT75 email account) are probably going to cooperate with authorities on trying to pin down the identity of JiaT75 (which might not be very useful, depending on where they live).
> 它真的符合一个真正生活（和睡觉）在中国的人所遵循的工作时间吗？
不，它没有：
https://play.clickhouse.com/play?user=play#U0VMRUNUIHRvSG91c...
他们的 Github 互动绝大多数发生在 12:00 UTC 到 18:00 UTC 之间
不，它没有：
https://play.clickhouse.com/play?user=play#U0VMRUNUIHRvSG91c...
他们的 Github 互动绝大多数发生在 12:00 UTC 到 18:00 UTC 之间
It's worth mentioning Lasse is still online in the Libera chat room, idling. Nothing's been said.
From elsewhere in the comments:
https://news.ycombinator.com/item?id=39874621
> He came on IRC, he seemed ok. He did some cleanup of access and signed off for easter.
https://news.ycombinator.com/item?id=39874621
> He came on IRC, he seemed ok. He did some cleanup of access and signed off for easter.
i think it's American trauma. outside of the Western hemisphere, sexist and racist jokes are just jokes
Pretty sure this is just a typo...
我试图理解这一点的重要性（父母可能暗示他们重用了一些测试代码生成的完全虚构的身份），我认为这是良性的。
该项目仅包含有关一堆示例项目的一些元数据，并且它直接链接到 xz 项目本身的镜像：
https://github.com/se-sic/VaRA-Tool-Suite/blob/982bf9b9cbf64...
我假设它下载项目，检查 git 历史记录，然后测试确保识别正确的作者姓名和电子邮件地址。
（也就是说，我还没有检查项目的其余部分，所以我不知道随后是否构建了 xz 的代码，或者其他项目是否可以以不安全的方式使用它）
该项目仅包含有关一堆示例项目的一些元数据，并且它直接链接到 xz 项目本身的镜像：
https://github.com/se-sic/VaRA-Tool-Suite/blob/982bf9b9cbf64...
我假设它下载项目，检查 git 历史记录，然后测试确保识别正确的作者姓名和电子邮件地址。
（也就是说，我还没有检查项目的其余部分，所以我不知道随后是否构建了 xz 的代码，或者其他项目是否可以以不安全的方式使用它）
[deleted]
Interesting thing about this [email protected] email is that it seems to not exist?
The google account: "Couldn't find your Google Account"
The email: "50 5.1.1 The email account that you tried to reach does not exist"
But then when you try to register it says it's taken.
Was it disabled?
The google account: "Couldn't find your Google Account"
The email: "50 5.1.1 The email account that you tried to reach does not exist"
But then when you try to register it says it's taken.
Was it disabled?
I'd say at this point all major tech companies, ISPs and authorities should have more enough information and disabling and freezing their accounts would be the first step.
This can happen if you delete your old gmail account. Source: I deleted a gmail account I shouldn't have years ago. It will say taken if it previously existed, and was deleted.
>Woha, is this legit or some sort of scam on Google in some way?:
I work on OSS-Fuzz.
As far as I can tell, the author's PRs do not compromise OSS-Fuzz in any way.
OSS-Fuzz doesn't trust user code for this very reason.
I work on OSS-Fuzz.
As far as I can tell, the author's PRs do not compromise OSS-Fuzz in any way.
OSS-Fuzz doesn't trust user code for this very reason.
It looks more like they disabled a feature of oss-fuzz that would've caught the exploit, no?
That's what people are saying though I haven't had the chance to look into this myself.
Fuzzing isn't really the best tool for catching bugs the maintainer intentionally inserted though.
Fuzzing isn't really the best tool for catching bugs the maintainer intentionally inserted though.
It's more likely that fuzzing would blow up on new code and they wanted an excuse to remove it.
After all, if it hadn't had a performance regression (someone could submit a PR fixing whatever slowed it down, heh) it still wouldn't be known.
After all, if it hadn't had a performance regression (someone could submit a PR fixing whatever slowed it down, heh) it still wouldn't be known.
There is also a variety of new, parallelized implementations of compression algorithms which would be good to have a close look at. Bugs causing undefined behaviour in parallel code are notoriously hard to see, and the parallel versions (which are actually much faster) could be take the place of well-established programs which have earned a lot of trust.
Well that account also did most of the releases since 5.4.0.
+1 Can see from project homepage http://web.archive.org/web/20240329165859/https://xz.tukaani... they have some release responsibility from 5.2.12.
> Versions 5.2.12, 5.4.3 and later have been signed with Jia Tan's OpenPGP key . The older releases have been signed with Lasse Collin's OpenPGP key .
It must be assume that before acquiring that privilege, they also contributed code to project. Probably most was to establish respectable record. Still could be malicious code going back someways.
> Versions 5.2.12, 5.4.3 and later have been signed with Jia Tan's OpenPGP key . The older releases have been signed with Lasse Collin's OpenPGP key .
It must be assume that before acquiring that privilege, they also contributed code to project. Probably most was to establish respectable record. Still could be malicious code going back someways.
看起来 Jia Tan OpenPGP 密钥也在几个月前被更换：https://github.com/tukaani-project/tukaani-project.github.io...
I handed over all the emails I received to the security team, who I guess will send them "higher". I'll let them analyse it.
There is zero web presence for this person and associated email address.
Looks more likely a fake identity than compromised account.
Looks more likely a fake identity than compromised account.
Did you check Chinese social media?
Why would you think the person would have social media (or would even be on Chinese social media specifically), given the sophistication and planning?
I mention Chinese social media specifically because I know it's not indexed so well by western search engines. You can't conclude someone has no social footprint until you've actually checked.
Regardless of how likely you think it is, finding a social media footprint would be useful information. Seek information first, reach conclusions second.
Regardless of how likely you think it is, finding a social media footprint would be useful information. Seek information first, reach conclusions second.
I found this link on Zhihu: https://www.zhihu.com/question/650826484
Actually the "jiat0218" user part in his email address [email protected] has a bunch of matches on Taiwanese sites:
https://char.tw/blog/post/24397301
https://forum.babyhome.com.tw/topic/167439
https://bmwcct.com.tw/forums/thread1828.html
https://char.tw/blog/post/24397301
https://forum.babyhome.com.tw/topic/167439
https://bmwcct.com.tw/forums/thread1828.html
It might just be a coincidence, but the same username from that gmail account also appears to have a Proton Mail address
I think it's not a coincidence: Hans Jansen ([email protected]) has a matching account on Proton mail too ([email protected]).
Furthermore, the Outlook account is configured as recovery e-mail for the Proton account.
I've never had a web presencse for my associated emails due to wanting to avoid spammers. I don't have a false identity.
Keep in mind that having a "false identity" does not make you a malicious actor. I have a serious project I work on under another pseudonym, but it has to do more with the fact that I do not want my real name to be associated with that project AND having a serious case of impostor syndrome. :/
That, and I used to contribute to various games (forks of ioquake3) when I was a teen and I wanted to keep my real name private.
That, and I used to contribute to various games (forks of ioquake3) when I was a teen and I wanted to keep my real name private.
Someone named "John is good" claims they aren't a malicious actor... You're trying real hard to convince us, huh.
Oh yeah, I am using a pseudonym here as well, because I have controversial views in some topics. :P
> I don't have a false identity.
That's just what someone with a false identity would say.. get him boys!
The biggest /S
That's just what someone with a false identity would say.. get him boys!
The biggest /S
这是我能找到的关于它们的所有信息。
carrd.co [email protected] business https://[email protected]
eBay JiaT75 购物 https://www.ebay.com/usr/JiaT75
giters jiat0218 编码 https://giters.com/jiat0218
giters JiaT75 编码 https://giters.com/JiaT75
GitHub jiat0218 编码 https://github.com/jiat0218
GitHub JiaT75 编码 https://github.com/JiaT75
Mastodon-meow.so... [email protected] 社交 https://meow.social/@[email protected]
除此之外，没有任何有把握的信息。(如果有人好奇，这些都是可以公开查询的信息）。
carrd.co [email protected] business https://[email protected]
eBay JiaT75 购物 https://www.ebay.com/usr/JiaT75
giters jiat0218 编码 https://giters.com/jiat0218
giters JiaT75 编码 https://giters.com/JiaT75
GitHub jiat0218 编码 https://github.com/jiat0218
GitHub JiaT75 编码 https://github.com/JiaT75
Mastodon-meow.so... [email protected] 社交 https://meow.social/@[email protected]
除此之外，没有任何有把握的信息。(如果有人好奇，这些都是可以公开查询的信息）。
[deleted]
JiaT75 also used "jiatan" on Libera.Chat using a Singapore IP address (possibly a proxy/VPN).
Where did you gather this information from?
I am more interest about his git commits https://github.com/JiaT75?tab=overview&from=2021-12-01&to=20...
If JiaT75 is a Chinese, then his working log should follow Chinese Holiday, especially Spring Festival and National Holiday.
Chinese usually not work on first 3 days of Spring Festival and National Holiday -
2021 2/11 - 2/13 (few commits), 2021 10/1 - 10/3 (nothing)
2022 1/31 - 2/2 (huge commits on 1/31, suspect), 2022 10/1 - 10/3 (nothing)
2023 and 2024, not very much commits.
So 2022 1/31 huge commits is a proof that he is not follow Chinese holiday.
But wait, 2021 is his active year, but he missed almost all Aug. Is he on holiday? Who can have such a long holiday? What i can think is a solider who has a long vacation (探亲假). So let's guess he is a solider then it's sense that he worked on Spring Holiday because they need on duty. Let's double check again, if he is a solider, then they will have a holiday on every Aug. 1 because it's liberation army day. I check and no commits on all 4 years Aug. 1.
But wait, 2021 is his active year, but he missed almost all Aug. Is he on holiday? Who can have such a long holiday? What i can think is a solider who has a long vacation (探亲假). So let's guess he is a solider then it's sense that he worked on Spring Holiday because they need on duty. Let's double check again, if he is a solider, then they will have a holiday on every Aug. 1 because it's liberation army day. I check and no commits on all 4 years Aug. 1.
i wonder if that avatar, familiarity with C/C++ and Git, and "offering help with open source projects" is just coincidence
https://github.com/JiaT75
https://twitter.com/JiaTan1337/status/1774931375994319244
kind of interesting also to see this account was set up ~2 months ago. if it's a troll, it's a somewhat poor joke.
https://github.com/JiaT75
https://twitter.com/JiaTan1337/status/1774931375994319244
kind of interesting also to see this account was set up ~2 months ago. if it's a troll, it's a somewhat poor joke.
I get why people are focusing on this bad actor. But the question that interests me more: how many other apparent individuals fit the profile that this person presented before caught?
Apparently, many.
It looks like gettext may be containing a part of their attack infrastructure.
https://github.com/microsoft/vcpkg/pull/37199#pullrequestrev...
https://github.com/microsoft/vcpkg/pull/37356/files#diff-e16...
https://github.com/MonicaLiu0311
It looks like gettext may be containing a part of their attack infrastructure.
https://github.com/microsoft/vcpkg/pull/37199#pullrequestrev...
https://github.com/microsoft/vcpkg/pull/37356/files#diff-e16...
https://github.com/MonicaLiu0311
Are you referencing the '-unsafe' suffix in the second link? That is not something to worry about.
This is from Gnulib, which is used by Gettext and other GNU projects. Using 'setlocale (0, NULL)' is not thread-safe on all platforms. Gnulib has modules to work around this, but not all projects want the extra locking. Hence the name '-unsafe'. :)
See: https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg001...
This is from Gnulib, which is used by Gettext and other GNU projects. Using 'setlocale (0, NULL)' is not thread-safe on all platforms. Gnulib has modules to work around this, but not all projects want the extra locking. Hence the name '-unsafe'. :)
See: https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg001...
[deleted]
They may be right: https://git.alpinelinux.org/aports/log/main/gettext
Timeline matches and there is a sudden switch of maintainer. And they add dependency to xz!
Timeline matches and there is a sudden switch of maintainer. And they add dependency to xz!
psykose was a prolific contributor to Alpine's aports, with thousands of
commits over the past few years[0]. So, I doubt They're involved.
[0]: https://git.alpinelinux.org/aports/stats/?period=y&ofs=10
[0]: https://git.alpinelinux.org/aports/stats/?period=y&ofs=10
JiaT75 was also a prolific contributor to xz over the past few years, so your assumptions are generally invalid at this point.
我猜这是一个国家演员。一般来说，在黑帽世界中，攻击者都有非常精确的目标。他们想要攻击这家公司或这群人。但是，在开源基础设施的核心部分设置后门的人希望撒下一张大网来攻击尽可能多的人。因此，这符合对监视一切感兴趣的政府情报机构的形象。
或者理论上它可能是恶意软件作者（勒索软件等）。然而，这些人倾向于瞄准容易实现的目标。他们想快速赚钱。我认为他们没有足够的耐心和毅力去渗透一个开源项目两年之久才能最终获得足够的信任并获得后门。另一方面，国家行为者是长期的，因此他们会花费大量时间（甚至更多）来实现这一目标。
这就是我的猜测：贾坦是某个情报机构的雇员。他选择展现亚洲人的形象，但这不一定是他真正代表的人。实际上可能是任何人：俄罗斯、中国、以色列，甚至美国等。
编辑：鉴于 Lasse Collin 是 2022 年 Jia Tan 之前 xz utils 的唯一维护者，如果国家演员以某种方式干扰 Lasse，我不会感到惊讶。他们可以做任何事情来分散他对项目的注意力：在他的生活中引入一个情妇，给他一份高薪工作，让他的配偶生病，这样他就必须照顾她，等等。由于 Lasse 没有那么多时间花在这个项目上，他更有可能允许一个大约在同一时间出现并且非常积极地贡献代码的开发人员。我有兴趣与 Lasse 交谈，了解他在 2022 年左右的情况。
或者理论上它可能是恶意软件作者（勒索软件等）。然而，这些人倾向于瞄准容易实现的目标。他们想快速赚钱。我认为他们没有足够的耐心和毅力去渗透一个开源项目两年之久才能最终获得足够的信任并获得后门。另一方面，国家行为者是长期的，因此他们会花费大量时间（甚至更多）来实现这一目标。
这就是我的猜测：贾坦是某个情报机构的雇员。他选择展现亚洲人的形象，但这不一定是他真正代表的人。实际上可能是任何人：俄罗斯、中国、以色列，甚至美国等。
编辑：鉴于 Lasse Collin 是 2022 年 Jia Tan 之前 xz utils 的唯一维护者，如果国家演员以某种方式干扰 Lasse，我不会感到惊讶。他们可以做任何事情来分散他对项目的注意力：在他的生活中引入一个情妇，给他一份高薪工作，让他的配偶生病，这样他就必须照顾她，等等。由于 Lasse 没有那么多时间花在这个项目上，他更有可能允许一个大约在同一时间出现并且非常积极地贡献代码的开发人员。我有兴趣与 Lasse 交谈，了解他在 2022 年左右的情况。
Or they have just one or a small number of targets, but don’t want the target(s) to know that they were the only target(s), so they backdoor a large number of victims to “hide in the crowd”.
I agree that this is likely a state actor, or at least a very large & wealthy private actor who can play the long game…
I agree that this is likely a state actor, or at least a very large & wealthy private actor who can play the long game…
According to top comment he committed multiple binary files to xz for the last two years.
Most likely this is not the first backdoor, just the first one to be discovered, so it wasn't two years of work until there were results.
But I still agree that he's probably a state actor.
Most likely this is not the first backdoor, just the first one to be discovered, so it wasn't two years of work until there were results.
But I still agree that he's probably a state actor.
Don't forget that you could have state actors who are otherwise interested in open source code, and working to actually improve it.
In fact, that'd be the best form of deep cover. It'll be interested to watch as people more knowledgable than I pour over every single commit and change.
In fact, that'd be the best form of deep cover. It'll be interested to watch as people more knowledgable than I pour over every single commit and change.
(not to be overly pedantic, but you probably meant pore, not pour: https://www.merriam-webster.com/grammar/pore-over-vs-pour-ov... )
If you have a backdoor in a specific piece of software already, what is the purpose of trying to introduce another backdoor (and risk it getting caught)?
This backdoor targeted only sshd.
There could be other backdoors for other targets.
There could be other backdoors for other targets.
There are two general attack targets I'd use if I had access to a library/binary like xz:
(1) A backdoor like this one, which isn't really about its core functions, but about the fact that it's a library linked into critical code, so that you can use it to backdoor _other things_. Those are complex and tricky because you have to manipulate the linking/GOT specifically for a target.
(2) Insert an exploitable flaw such as a buffer overflow so that you can craft malicious .xz files that result in a target executing code if they process your file. This is a slightly more generic attack vector but that requires a click/download/action.
Not every machine or person you want to compromise has an exposed service like ssh, and not every target will download/decompress a file you send to them. These are decently orthogonal attack vectors even though they both involve a library.
(Note that there's as yet no evidence for #2 - I'm just noting how I'd try to leverage this to maximum effect if I wanted to.)
(1) A backdoor like this one, which isn't really about its core functions, but about the fact that it's a library linked into critical code, so that you can use it to backdoor _other things_. Those are complex and tricky because you have to manipulate the linking/GOT specifically for a target.
(2) Insert an exploitable flaw such as a buffer overflow so that you can craft malicious .xz files that result in a target executing code if they process your file. This is a slightly more generic attack vector but that requires a click/download/action.
Not every machine or person you want to compromise has an exposed service like ssh, and not every target will download/decompress a file you send to them. These are decently orthogonal attack vectors even though they both involve a library.
(Note that there's as yet no evidence for #2 - I'm just noting how I'd try to leverage this to maximum effect if I wanted to.)
xz is a data compression tool, so it's natural to have compressed files for (de)compression tests.
these files are also useful to check that the library we just built works correctly. but they aren't necessary for installation.
we may have more sophisticated procedures that will allow us to use some parts of distribution only for tests. This may significantly reduce an attack vector - many projects have huge, sophisticated testing infrastructure where you can hide the entire Wikipedia.
these files are also useful to check that the library we just built works correctly. but they aren't necessary for installation.
we may have more sophisticated procedures that will allow us to use some parts of distribution only for tests. This may significantly reduce an attack vector - many projects have huge, sophisticated testing infrastructure where you can hide the entire Wikipedia.
5p4n911(3)
If anyone here happens to know Lasse, it might be good to check up on him and see how he's doing.
> I wouldn't be surprised if the state actor interfered with Lasse somehow
People could also just get tired after years of active maintainership or become busier with life. Being the sole maintainer of an active open source project on top of work and perhaps family takes either a lot of enthusiasm or a lot of commitment. It's not really a given that people want to (or can) keep doing that forever at the same pace.
Someone then spots the opportunity.
I have no idea what the story is here but it might be something rather mundane.
People could also just get tired after years of active maintainership or become busier with life. Being the sole maintainer of an active open source project on top of work and perhaps family takes either a lot of enthusiasm or a lot of commitment. It's not really a given that people want to (or can) keep doing that forever at the same pace.
Someone then spots the opportunity.
I have no idea what the story is here but it might be something rather mundane.
> I haven't lost interest but my ability to care has been fairly limited
mostly due to longterm mental health issues but also due to some other
things. Recently I've worked off-list a bit with Jia Tan on XZ Utils and
perhaps he will have a bigger role in the future, we'll see.
https://www.mail-archive.com/[email protected]/msg00567.h...
https://www.mail-archive.com/[email protected]/msg00567.h...
Dated June 2022. Good find!
That "Jigar Kumar" is like fake and one-time throw-off account, probably from the same state actor to orchestrate the painstakingly prepared supply chain attack (under the sun).
At first glance I thought it was a far-fetched conclusion but then I read in a subsequent reply he wrote:
> With your current rate, I very doubt to see 5.4.0 release this year. The only progress since april has been small changes to test code. You ignore the many patches bit rotting away on this mailing list. Right now you choke your repo. Why wait until 5.4.0 to change maintainer? Why delay what your repo needs?
https://www.mail-archive.com/[email protected]/msg00568.h...
The last two sentences really make it look as if he were trying to pressure the original author.
> With your current rate, I very doubt to see 5.4.0 release this year. The only progress since april has been small changes to test code. You ignore the many patches bit rotting away on this mailing list. Right now you choke your repo. Why wait until 5.4.0 to change maintainer? Why delay what your repo needs?
https://www.mail-archive.com/[email protected]/msg00568.h...
The last two sentences really make it look as if he were trying to pressure the original author.
Oh wow, all his posts are trying to pressure Lasse, or guilt him into getting Jia on board. They're definitely conspiring.
"Your efforts are good but based on the slow release schedule it will unfortunatly be years until the community actually gets this quality of life feature."
"Patches spend years on this mailing list. 5.2.0 release was 7 years ago. There is no reason to think anything is coming soon."
"With your current rate, I very doubt to see 5.4.0 release this year. The only progress since april has been small changes to test code. You ignore the many patches bit rotting away on this mailing list. Right now you choke your repo. Why wait until 5.4.0 to change maintainer? Why delay what your repo needs?"
"Progress will not happen until there is new maintainer. XZ for C has sparse commit log too. Dennis you are better off waiting until new maintainer happens or fork yourself. Submitting patches here has no purpose these days. The current maintainer lost interest or doesn't care to maintain anymore. It is sad to see for a repo like this."
"Is there any progress on this? Jia I see you have recent commits. Why can't you commit this yourself?"
"Over 1 month and no closer to being merged. Not a suprise."
"Your efforts are good but based on the slow release schedule it will unfortunatly be years until the community actually gets this quality of life feature."
"Patches spend years on this mailing list. 5.2.0 release was 7 years ago. There is no reason to think anything is coming soon."
"With your current rate, I very doubt to see 5.4.0 release this year. The only progress since april has been small changes to test code. You ignore the many patches bit rotting away on this mailing list. Right now you choke your repo. Why wait until 5.4.0 to change maintainer? Why delay what your repo needs?"
"Progress will not happen until there is new maintainer. XZ for C has sparse commit log too. Dennis you are better off waiting until new maintainer happens or fork yourself. Submitting patches here has no purpose these days. The current maintainer lost interest or doesn't care to maintain anymore. It is sad to see for a repo like this."
"Is there any progress on this? Jia I see you have recent commits. Why can't you commit this yourself?"
"Over 1 month and no closer to being merged. Not a suprise."
[deleted]
> They want to attack this company or this group of individuals. But someone who backdoors such a core piece of open source infrastructure wants to cast a wide net to attack as many as possible.
The stuxnet malware, which compromised Siemens industrial controls to attack specific centrifuges in uranium enrichment plants in Iran, is a counterexample to that.
The stuxnet malware, which compromised Siemens industrial controls to attack specific centrifuges in uranium enrichment plants in Iran, is a counterexample to that.
Stuxnet wasn't similar to this xz backdoor. The Stuxnet creators researched (or acquired) four Windows zero-days, a relatively short-term endeavor. Whereas the xz backdoor was a long-term 2.5 years operation to slowly gain trust from Lasse Collin.
But, anyway, I'm sure we can find other counter-examples.
But, anyway, I'm sure we can find other counter-examples.
If a government wants to cast a wide nest and catch what they can, they'll just throw a tap in some IXP.
If a government went to this much effort to plant this vulnerability, they absolutely have targets in mind - just like they did when they went to the effort of researching (or acquiring) four separate Windows zero-days, combining them, and delivering them...
If a government went to this much effort to plant this vulnerability, they absolutely have targets in mind - just like they did when they went to the effort of researching (or acquiring) four separate Windows zero-days, combining them, and delivering them...
> a long-term 2.5 years operation to slowly gain trust from Lasse Collin
Couldn't the account that committed the backdoor have been compromised recently?
Couldn't the account that committed the backdoor have been compromised recently?
It's ridiculous to think it's the US as it would be an attack on Red Hat a US company and an attack on Americans. It's a good way to be dragged in front of Congress.
The US has backdoored RSA's RNG and thus endangered the security of American companies. It is naive to think that US intelligence agencies will act in the best interest of US citizens or companies.
That is speculation and has never been confirmed.
What type of confirmation do you want? The documents aren't going to be declassified in the next couple of decades, if ever.
I've never heard anyone claim that Dual_EC_DRBG is most likely not intentionally backdoored, but there's literally no way to confirm because of how its written. If we can't analyze intention from the code, we can look at the broader context for clues. The NSA spent an unusual amount of effort trying to push forward an algorithm that kept getting shot down because it was slower than similar algorithms with no additional benefits (the $10 million deal specified it as a requirement [1]). If you give the NSA the benefit of the doubt, they spent a lot of time and money to... intentionally slow down random number generation?!
As an American, I'd prefer a competent NSA than an incompetent NSA that spends my tax dollars to make technology worse for literally no benefit...
[1] https://www.reuters.com/article/us-usa-security-rsa-idUSBRE9...
I've never heard anyone claim that Dual_EC_DRBG is most likely not intentionally backdoored, but there's literally no way to confirm because of how its written. If we can't analyze intention from the code, we can look at the broader context for clues. The NSA spent an unusual amount of effort trying to push forward an algorithm that kept getting shot down because it was slower than similar algorithms with no additional benefits (the $10 million deal specified it as a requirement [1]). If you give the NSA the benefit of the doubt, they spent a lot of time and money to... intentionally slow down random number generation?!
As an American, I'd prefer a competent NSA than an incompetent NSA that spends my tax dollars to make technology worse for literally no benefit...
[1] https://www.reuters.com/article/us-usa-security-rsa-idUSBRE9...
You are understating the level of evidence that points to the NSA being fully aware of what it was doing.
To be clear, the method of attack was something that had been described in a paper years earlier, the NSA literally had a program (BULLRUN) around compromising and attacking encryption, and there were security researchers at NIST and other places that raised concerns even before it was implemented as a standard. Oh, and the NSA paid the RSA $10 million to implement it.
Heck, even the chairman of the RSA implies they got used by the NSA:
In an impassioned speech, Coveillo said RSA, like many in industry, has worked with the NSA on projects. But in the case of the NSA-developed algorithm which he didn’t directly name, Coviello told conference attendees that RSA feels NSA exploited its position of trust. In its job, NSA plays two roles, he pointed out. In the information assurance directorate (IAD) arm of NSA, it decides on security technologies that might find use in the government, especially the military. The other side of the NSA is tasked with vacuuming up data for cyber-espionage purposes and now is prepared to take an offensive role in cyber-attacks and cyberwar.
“We can’t be sure which part of the NSA we’re working with,” said Coviello with a tone of anguish. He implied that if the NSA induced RSA to include a secret backdoor in any RSA product, it happened without RSA’s consent or awareness.
https://www.networkworld.com/article/687628/security-rsa-chi...
To be clear, the method of attack was something that had been described in a paper years earlier, the NSA literally had a program (BULLRUN) around compromising and attacking encryption, and there were security researchers at NIST and other places that raised concerns even before it was implemented as a standard. Oh, and the NSA paid the RSA $10 million to implement it.
Heck, even the chairman of the RSA implies they got used by the NSA:
In an impassioned speech, Coveillo said RSA, like many in industry, has worked with the NSA on projects. But in the case of the NSA-developed algorithm which he didn’t directly name, Coviello told conference attendees that RSA feels NSA exploited its position of trust. In its job, NSA plays two roles, he pointed out. In the information assurance directorate (IAD) arm of NSA, it decides on security technologies that might find use in the government, especially the military. The other side of the NSA is tasked with vacuuming up data for cyber-espionage purposes and now is prepared to take an offensive role in cyber-attacks and cyberwar.
“We can’t be sure which part of the NSA we’re working with,” said Coviello with a tone of anguish. He implied that if the NSA induced RSA to include a secret backdoor in any RSA product, it happened without RSA’s consent or awareness.
https://www.networkworld.com/article/687628/security-rsa-chi...
当显示他们为 DSA 做了相反的事情（使用只有他们当时知道的数学来强化安全性）时怎么样？
What about it?
There's an implicit "always" in their second sentence, if you're confused by the wording. They aren't positing the equivalent of the guard that only lies.
There's an implicit "always" in their second sentence, if you're confused by the wording. They aren't positing the equivalent of the guard that only lies.
It's an interesting story for those who haven't heard about that an think the NSA could only be up to evil. You may not have read it as the guard only ever lies, but that doesn't stop people from thinking that anyway.
It's an interesting story, but I still don't know what you wanted as an answer to "What about".
They were responding to:
> It is naive to think that US intelligence agencies will act in the best interest of US citizens or companies.
With an example of them doing exactly that.
> It is naive to think that US intelligence agencies will act in the best interest of US citizens or companies.
With an example of them doing exactly that.
This is addressed very directly by the second paragraph of my first comment. Please adjust your response to take that into account.
why are you so fight-y? do you have to be right, or have the last word? what is it?
I'm perfectly willing to have an actual discussion, but someone coming along to ignore what I said is kind of annoying.
Is there something more productive that I could have replied with? (I know I could have been less snippy, but I think being snippy is fair there.)
Is there something more productive that I could have replied with? (I know I could have been less snippy, but I think being snippy is fair there.)
Notably that was a "no-one-but-us" backdoor, that requires a specific secret key to exploit. We'll see when someone analyzes the payload further, but presumably this backdoor also triggers on a specific private key. If not there are ways to do it that would look far more like an innocent mistake, like a logic bug or failed bounds check.
I can see some arguments that might persuade the NSA to run an attack like this
I can see some arguments that might persuade the NSA to run an attack like this
- gathers real world data on detection of supply attacks
- serves as a wake-up call for a software community that has grown complacent on the security impact of dependencies
- in the worst case, if no one finds it then hey, free backdoorHardly ridiculous.
You say that as if members of US government agencies didn't plot terror attacks on Americans (Operation Northwood), steal the medical records of American whistleblowers (Ellsberg), had to be prevented from assassinating American journalists (Gordon Liddy, on Jack Anderson), collude to assassinate American political activists (Fred Hampton), spy on presidential candidates (Watergate), sell weapons to countries who'd allegedly supported groups who'd launched suicide bombing attacks on American soldiers (Iran-Contra), allow drug smugglers to flood the USA with cocaine so that they could supply illegal guns to terrorists abroad on their return trip (Iran-Contra again) and get caught conducting illegal mass-surveillance on American people as a whole (Snowden). Among others.
It's super-naive to suggest that government agencies wouldn't act against the interest of American citizens and companies because there might be consequences if they were caught. Most of the instances above actually were instances where the perpetrators did get caught, which is why we know about them.
You say that as if members of US government agencies didn't plot terror attacks on Americans (Operation Northwood), steal the medical records of American whistleblowers (Ellsberg), had to be prevented from assassinating American journalists (Gordon Liddy, on Jack Anderson), collude to assassinate American political activists (Fred Hampton), spy on presidential candidates (Watergate), sell weapons to countries who'd allegedly supported groups who'd launched suicide bombing attacks on American soldiers (Iran-Contra), allow drug smugglers to flood the USA with cocaine so that they could supply illegal guns to terrorists abroad on their return trip (Iran-Contra again) and get caught conducting illegal mass-surveillance on American people as a whole (Snowden). Among others.
It's super-naive to suggest that government agencies wouldn't act against the interest of American citizens and companies because there might be consequences if they were caught. Most of the instances above actually were instances where the perpetrators did get caught, which is why we know about them.
I love being called naive.
Whisper it to me lover.
Seems like an appropriately used descriptor here.
You don’t even have to be this conspiratorially minded to believe the NSA is a legitimate suspect here. (For the record, I think literally every intelligence agency on Earth is plausible here.)
You kind of lost the thread when you say, “act against the interests of American citizens and companies”. Bro, literally anyone could be using xz, and anyone could be using Red Hat. You’re only “acting against Americans” if you use it against Americans. I don’t know who was behind this, but a perfectly plausible scenario would be the NSA putting the backdoor in with an ostensibly Chinese login and then activating on machines hosted and controlled by people outside of the US.
Focusing on a specific distro is myopic. Red Hat is popular.
You kind of lost the thread when you say, “act against the interests of American citizens and companies”. Bro, literally anyone could be using xz, and anyone could be using Red Hat. You’re only “acting against Americans” if you use it against Americans. I don’t know who was behind this, but a perfectly plausible scenario would be the NSA putting the backdoor in with an ostensibly Chinese login and then activating on machines hosted and controlled by people outside of the US.
Focusing on a specific distro is myopic. Red Hat is popular.
> but a perfectly plausible scenario would be the NSA putting the backdoor in with an ostensibly Chinese login and then activating on machines hosted and controlled by people outside of the US.
There's a term for that: NOBUS (https://en.wikipedia.org/wiki/NOBUS). It won't surprise me at all if this backdoor can only be exploited if the attacker has the private key corresponding to a public key contained in the injected code. It also won't surprise me if this private key ends up being stolen by someone else, and used against its original owner.
There's a term for that: NOBUS (https://en.wikipedia.org/wiki/NOBUS). It won't surprise me at all if this backdoor can only be exploited if the attacker has the private key corresponding to a public key contained in the injected code. It also won't surprise me if this private key ends up being stolen by someone else, and used against its original owner.
>It also won't surprise me if this private key ends up being stolen by someone else, and used against its original owner.
And that is exactly why backdoored encryption is bad.
And that is exactly why backdoored encryption is bad.
100%.
The HN crowd has come a long way from practically hero-worshipping Snowden to automatically assuming that 'state actor' must mean the countries marked evil by the US.
The HN crowd has come a long way from practically hero-worshipping Snowden to automatically assuming that 'state actor' must mean the countries marked evil by the US.
[deleted]
Caught and, more importantly, nothing bad typically happened to anyone involved. Also worth noting that there is probably a survivorship bias in play.
Have you forgotten about the Snowden leaks exposing the surveillance on Americans by the American govt?
Every country spies on its own citizens.
By comparison America is actually quite timid compared to other countries e.g. UK and the widespread CCTV network.
By comparison America is actually quite timid compared to other countries e.g. UK and the widespread CCTV network.
I'd say that CCTV is quite different to wiretapping. You (generally) wouldn't have the expectation of privacy in a public place, most people would expect that phone calls, messages, etc do remain private.
Now, GCHQ is no better than the NSA for that either, but I don't think CCTV is a good comparison.
Now, GCHQ is no better than the NSA for that either, but I don't think CCTV is a good comparison.
While his leaks expose surveillance, he was useful idiot https://en.wikipedia.org/wiki/Useful_idiot in hands of Assange club. And it might be event of his saving was trigger for Putin to start war. So no, I'd better see whole camaraderie before court and sentenced. Regardless of 'heroism'.
And yes, most of modern supporters of Wikileaks / Assange / Snowden / etc, chanting 'release Assange' and 'pardon Snowden' are useful idiots in hands of tyrannies like BRICS club.
And yes, most of modern supporters of Wikileaks / Assange / Snowden / etc, chanting 'release Assange' and 'pardon Snowden' are useful idiots in hands of tyrannies like BRICS club.
I'm not very inclined to think this is the US govt, however, you should better acquaint yourself with the morals of some members of Congress.
I think the best reason to doubt USG involvement is the ease with which somebody discovered this issue, which is only a month or two old. I feel like NSA etc. knows not to get caught doing this so easily.
I think the best reason to doubt USG involvement is the ease with which somebody discovered this issue, which is only a month or two old. I feel like NSA etc. knows not to get caught doing this so easily.
Yeah as we know, intelligence agencies are very often held accountable in the US. As witnessed by all the individuals that got charged or punished for uh... nevermind.
鉴于另一条评论 [1] 的详细信息，听起来两个维护者都很可疑。 Lasse 的行为最近发生了变化，他一直在推动将 Jia Tan 的更改纳入 Linux 内核。有可能这两个帐户甚至不再由原来的 Lasse Collin 和 Jia Tan 管理。
编辑：此外，Github 已暂停这两个帐户。也许他们知道一些我们不知道的事情。
[1] https://news.ycombinator.com/item?id=39865810#39866275
编辑：此外，Github 已暂停这两个帐户。也许他们知道一些我们不知道的事情。
[1] https://news.ycombinator.com/item?id=39865810#39866275
Where does that comment mention the other maintainer (Lasse Collin)?
Whoops, I linked the wrong comment. I meant to link this one [1]. Anyway, seems like there's potentially a whole trail of compromised and fake accounts [2]. Someone in a government agency somewhere is pretty disappointed right now.
[1] https://news.ycombinator.com/item?id=39867593
[2] https://news.ycombinator.com/item?id=39866936
[1] https://news.ycombinator.com/item?id=39867593
[2] https://news.ycombinator.com/item?id=39866936
According to Webarchive, https://tukaani.org/contact.html changed very recently (between 11/02/2024 and 29/02/2024) to add Lasse Collin's PGP key fingerprint. That timing is weird, considering his git activity at that time is almost non existent. Although, i checked, this key existed back in 2012.
> considering his git activity at that time is almost non existent
Are you looking at the same repositories I am? He's made 88 commits to xz in that time period, two-thirds of the total.
Are you looking at the same repositories I am? He's made 88 commits to xz in that time period, two-thirds of the total.
> Generally in the blackhat world, attackers have very precise targets
Lol, what
> wants to cast a wide net to attack as many as possible. So that fits the profile of a government intelligence agency
That's quite backwards. Governments are far more likely to deploy a complex attack against a single target (see also: Stuxnet); other attackers (motivated primarily by money) are far more likely to cast a wide net.
Lol, what
> wants to cast a wide net to attack as many as possible. So that fits the profile of a government intelligence agency
That's quite backwards. Governments are far more likely to deploy a complex attack against a single target (see also: Stuxnet); other attackers (motivated primarily by money) are far more likely to cast a wide net.
> That's quite backwards. Governments are far more likely to deploy a complex attack against a single target (see also: Stuxnet); other attackers (motivated primarily by money) are far more likely to cast a wide net.
Governments are well known to keep vulnerabilities hidden (see EternalBlue). Intentionally introducing a vulnerability doesn’t seem that backwards tbh
Governments are well known to keep vulnerabilities hidden (see EternalBlue). Intentionally introducing a vulnerability doesn’t seem that backwards tbh
Oh for sure. I'm not suggesting that this wasn't a government actor, although I'd only give you 50/50 odds on it myself. It coulda just been someone with a bunch of time, like phreakers of old.
Literally this https://xkcd.com/2347/
Bit much speculating about mistresses and poisoned spouses with well anything to go on...
Yes, I believe it's an state actor, and the intention of choosing a typical Chinese name Jia Tan is intentially and malicious.
Adding some unreadable binary to the source code is a really dangerous thing to do.
We also need tools to quickly detect the addition of indentation symbols that can be easily overlooked.
BYW,I had a classmate who used to play DOTA1(on war3) under this name at the University of Science and Technology of China a long time ago, and this was his first girlfriend name (maybe) . His father was a high-ranking official. Then he joined the parent department of the Internal Security Detachment, a secret service that has gained a lot of power in the last few years. I hope I'm not awake . lol.
BYW,I had a classmate who used to play DOTA1(on war3) under this name at the University of Science and Technology of China a long time ago, and this was his first girlfriend name (maybe) . His father was a high-ranking official. Then he joined the parent department of the Internal Security Detachment, a secret service that has gained a lot of power in the last few years. I hope I'm not awake . lol.
Seems to be a perfect project to hijack. Not too much happening, widely used, long history, single maintainer who no longer has time to manage the project and wants to pass it over.
We detached this subthread from https://news.ycombinator.com/item?id=39866275. (It's fine; I'm just trying to prune the top-heavy subthread.)
Not a developer but reading the changelogs and commit history from this person seem interesting, as they appear to be some effort consolidate control and push things in the direction of supporting wider dissemination of their backdoor code:
Discussing commits that the other author has since reverted, IFUNC change with Project Zero tests, a focus on embedded, etc.:
https://www.mail-archive.com/[email protected]/msg00642.h...
Trimming security reporting details:
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=af071ef7702...
Discussing commits that the other author has since reverted, IFUNC change with Project Zero tests, a focus on embedded, etc.:
https://www.mail-archive.com/[email protected]/msg00642.h...
Trimming security reporting details:
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=af071ef7702...
"crazytan" is the LinkedIn profile of a security software engineer named Jia Tan in Sunnyvale working at Snowflake, who attended Shanghai Jiao Tong University from 2011 to 2015 and Georgia Institute of Technology from 2015 to 2017. However, this Jia Tan on LinkedIn might not be the same Jia Tan who worked on XZ Utils. Also, the person who inserted the malicious code might be someone else who hijacked the account of the Jia Tan who worked on XZ Utils.
我发现了一个对我来说可疑的用户。
https://github.com/snappyJack/CVE-request-XZ-5.2.5-has-denia...
在开发以下存储库时，他很早就了解了软件架构。他把其他项目中的点联系起来，然后开始胡作非为。 （可能从加密货币中受益？）。看看他的其他存储库和代码风格以及最近在 github 上的点赞。他就是我们的贾坦吗？
https://github.com/snappyJack/CVE-request-XZ-5.2.5-has-denia...
在开发以下存储库时，他很早就了解了软件架构。他把其他项目中的点联系起来，然后开始胡作非为。 （可能从加密货币中受益？）。看看他的其他存储库和代码风格以及最近在 github 上的点赞。他就是我们的贾坦吗？
May or may not be related:
https://www.linkedin.com › crazytan
Jia Tan - Snowflake | LinkedIn
Has Jia in any way posted a response to the incident?
My assumption would be that he knows the jig is up, and is probably going to do everything he can to jettison the JiaTan account, lest any IPs he uses be turned over to authorities.
An Indian with the name, Jigar (meaning heart) would never address himself as Jigar, as seen in the citation. This would be culturally a bit weird. Unless he is being sarcastic or writing this on some comic note.
Secondly, the use of English is not consistent in what should be from typical Indian. He should be from a foreign background or a very reputed English medium.
The language though seemingly simple for a native English speaker but it seems in this case; a person whose first language: likely is not English.
It is possible that Grammarly or auto correct could have been used to write these. But can't be certain of anything stated above.
I do think that this is a sabotage account with 60% chances unless Mr. Kumar comes out clean, publicly. He is likely a state sponsored actor.
Secondly, the use of English is not consistent in what should be from typical Indian. He should be from a foreign background or a very reputed English medium.
The language though seemingly simple for a native English speaker but it seems in this case; a person whose first language: likely is not English.
It is possible that Grammarly or auto correct could have been used to write these. But can't be certain of anything stated above.
I do think that this is a sabotage account with 60% chances unless Mr. Kumar comes out clean, publicly. He is likely a state sponsored actor.
If you have a recently updated NixOS unstable it has the affected version:
$ xz --version
xz (XZ Utils) 5.6.1
liblzma 5.6.1
[deleted]
> “文档：简化 SECURITY.md。”
https://github.com/tukaani-project/xz/commit/af071ef7702debe...
删除有关与安全报告相关的详细信息的说明。 呵呵，不错的一个。
https://github.com/tukaani-project/xz/commit/af071ef7702debe...
删除有关与安全报告相关的详细信息的说明。 呵呵，不错的一个。
Given the recent ( not so recent ) attacks/"bugs" I feel there is a need to do more than the already hard task of investigating and detecting attacks but also to bring IRL consequences to these people.
My understanding is that right now it's pretty much a name and shame of people who most of the time aren't even real "people" but hostile agents either working for governments or criminal groups ( or both )
Getting punched in the face is actually a necessary human condition for a healthy civilization.
My understanding is that right now it's pretty much a name and shame of people who most of the time aren't even real "people" but hostile agents either working for governments or criminal groups ( or both )
Getting punched in the face is actually a necessary human condition for a healthy civilization.
In the article it says CISA was notified - that sounds like it's going to be a federal investigation if nothing else. If I was this person, I wouldn't be in the USA (or any US friendly nation) ASAP.
One of Jia Tan's recent contributions is "Speed up CRC32 calculation on LoongArch" I would guess the odds are that this is not someone in the US.
Yeah I saw that - I wouldn't bet on them being in the US but who knows. Maybe they just really love CRC32 ;) And introducing backdoors (if it that was them not an account takeover).
Those tarballs are PGP signed, too..
这是对别人作品的评论？ https://github.com/tukaani-project/xz/pull/86
Since that repo is disabled: here is a mirror of the discussion [1]
[1] https://archive.is/tksCR
[1] https://archive.is/tksCR
It's also very possible that the account was compromised and taken over. A two years long con with real useful work is a lot of patience and effort vs. just stealing a weakly protected account. I wonder if MFA shouldn't be a requirement for accounts that contribute to important OSS projects.
This is most likely not his first backdoor, but the first which was detected.
So most likely he didn't wait two years to benefit.
So most likely he didn't wait two years to benefit.
> 与仅仅窃取受保护较弱的帐户相比，为期两年的真正有用的骗局需要大量的耐心和努力。
长期骗局理论目前似乎更合理一些
https://github.com/google/oss-fuzz/pull/10667
长期骗局理论目前似乎更合理一些
https://github.com/google/oss-fuzz/pull/10667
It might not even be a long time. He might have just been approached exactly because of his history to insert the back door. And offered either money, or blackmailed or threatened
Oh man. The was a scenario that didn't cross my mind. I was too narrowly focused on the technical aspects rather than the social aspects of security. Great point.
What if this contributor was a member of a state actor/persistent threat group and, like some totally legit software dev houses, they encourage their people to contribute to OSS projects for the whole personal pursuit/enjoyment/fulfillment angle?
With the added bonus that sometimes they get to pull off a longcon like this.
With the added bonus that sometimes they get to pull off a longcon like this.
If you really step back and think about it, this type of behavior is perfectly aligned with any number of well resourced criminal groups and state actors. Two years of contributing in less visible software with the goal of gaining trust and then slowly pushing your broken fix in.
To me that's way more plausible than losing control of your account and the person who compromised it then having someone over a long time insert the backdoor that took a long time to develop and then obfuscate it.
Likely someone at GH is talking to some government agencies right now about the behavior of the private repos of that user and their associated users.
To me that's way more plausible than losing control of your account and the person who compromised it then having someone over a long time insert the backdoor that took a long time to develop and then obfuscate it.
Likely someone at GH is talking to some government agencies right now about the behavior of the private repos of that user and their associated users.
This would be the smarter attack vector, but I've noticed over time that these people are just assholes. They aren't patient. They are in for the smash/grab.
I would not be surprised if there was a group using this approach, but I doubt most of them are/would. If they were that dedicated, they'd just have a fucking job, instead of being dicks on the internet for a living.
I would not be surprised if there was a group using this approach, but I doubt most of them are/would. If they were that dedicated, they'd just have a fucking job, instead of being dicks on the internet for a living.
I think you are confusing non-state e.g. ransomware groups, which are usually not part of a government (although some exceptions like North Korea likely exist) with state-sponsored hackers who are often directly working under military command. Soldiers are not "dicks on the internet".
As someone who has been in a fair few discord chats with soldiers, I'd beg to differ...
>As someone who has been in a fair few discord chats with soldiers, I'd beg to differ...
As someone that's spent a lot of time in darker places, I would agree.
As someone that's spent a lot of time in darker places, I would agree.
For some groups they certainly are.
However at this point: every developed nation has a professional offensive security group that have varying degrees of potency. All are more resourced than 99.9% of organizations defending and enjoy legal autonomy in their country and allied countries for their work.
If you're getting salaried comfortably, and you have near infinite resources, a two year timeline is trivial. As an American, I always like to point to things we know our own services have done first[0].
Each actor group have their own motivations and tactics[1]. As someone who spent a lot of time dealing with a few state actors, you learn your adversaries tricks of the trade and they are patient for the long-con because they can afford to be.
[0] - https://www.npr.org/2020/03/05/812499752/uncovering-the-cias... [1] - https://learn.microsoft.com/en-us/microsoft-365/security/def...
However at this point: every developed nation has a professional offensive security group that have varying degrees of potency. All are more resourced than 99.9% of organizations defending and enjoy legal autonomy in their country and allied countries for their work.
If you're getting salaried comfortably, and you have near infinite resources, a two year timeline is trivial. As an American, I always like to point to things we know our own services have done first[0].
Each actor group have their own motivations and tactics[1]. As someone who spent a lot of time dealing with a few state actors, you learn your adversaries tricks of the trade and they are patient for the long-con because they can afford to be.
[0] - https://www.npr.org/2020/03/05/812499752/uncovering-the-cias... [1] - https://learn.microsoft.com/en-us/microsoft-365/security/def...
This is not that costly. Growing bonsai trees also takes a lot of patience, decades, but you don't have to grow only one at a time, the pros are growing them in large numbers, with minimal work on each individual trees once in a while.
There is a survivorship bias problem there; what if the stupid criminals are the only ones which you notice?
I am thinking more in so-called rubberhose cryptoanalysis.
https://xkcd.com/538/
https://xkcd.com/538/
> It's also very possible that the account was compromised and taken over
Or they WERE legit and simply went rogue, perhaps due to external factors.
Or they WERE legit and simply went rogue, perhaps due to external factors.
2 years of one engineer's time is very cheap, compared to e.g. the NSA's CryptoAG scam. I'd say most likely a Chinese intelligence plant, kindly offering to relieve the burden of the original author of xz.
I got the same idea. On XZ dev mailing list there were a few discussions about "is there a maintainer?" 2-3 years ago. It's not hard to find these types discussions and then dedicate a few years of effort to start "helping out" and eventually be the one signing releases for the project. That's peanuts for a state actor.
This right here. This is exactly what I would be doing - find small broke maintainers offer them a few hundred grand - with a target in mind.
[deleted]
The full name "Jia Cheong Tan" doesn't sound like Mainland China. The name and actions could be intentionally misleading though.
https://news.ycombinator.com/item?id=39867737
https://news.ycombinator.com/item?id=39867737
We're way too global now for this to be more than a tiny extra signal. People move around, families preserve names.
Also nobody checked that person's id, so "Jia" is only slightly more meaningful than "ghrssbitrvii".
Also nobody checked that person's id, so "Jia" is only slightly more meaningful than "ghrssbitrvii".
Names can be faked, and even real names are not a great indicator.
Unless you have some very specific cultural knowledge you could not make even vaguely useful deductions about my location, nationality, culture, ethnicity etc. from my name. I get a lot of wrong guesses though!
Unless you have some very specific cultural knowledge you could not make even vaguely useful deductions about my location, nationality, culture, ethnicity etc. from my name. I get a lot of wrong guesses though!
[deleted]
由于他在 github 和 git repos 之外的唯一出现是在一些台湾博客上，我们可以将所有出现的中国更改为台湾吗？
还有一些人通过比较时区暗示了东欧。不过，台湾仍然是最强烈的暗示。
还有一些人通过比较时区暗示了东欧。不过，台湾仍然是最强烈的暗示。
What law do you think is being broken here?
Maybe https://www.law.cornell.edu/uscode/text/18/1030#a_5 ?
> knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer;
> knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer;
How does posting an exploit POC differ here?
Intent. It's a big part of law and prosecution.
No, freedom of speech (as far as I know) protects even exploit code. The statutes being linked would cover using the backdoor to gain unauthorized entry to a system. I think the question of whether anything illegal has occurred from the public facts is unclear, at least to me, and interesting.
我看到该项目的开发人员刚刚发布消息说它已经在野外被发现，所以我想你会站在那里。
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...
The first amendment might overrule the cited law if that law didn't already include a requirement for intentional harm. But since the law does already have that requirement, there's not really an opportunity for a freedom of speech justification to be what protects a non-malicious publication of a proof of concept. The law isn't trying to infringe on freedom of speech.
But my argument isn't that freedom of speech could be used as an excuse for something that would otherwise be illegal -- my argument is that publishing and discussing exploit code is a constitutionally-protected activity. The CFAA statutes can be violated by gaining unauthorized access to a protected computer system, but that did not happen in the process of authoring and publishing the exploit code. The attacker was authorized to release new versions of the software, and they did. Their choice of what to make their software actually do is not regulated by the government, any more than a musician's choice of which lyrics to include in their song.
If an attacker then actually uses the backdoor created by someone else's decision to deploy the new release into their own environment, to gain unauthorized access to a protected computer system, then obviously there's a CFAA violation there. The public facts don't contain documented examples of this having happened (yet), though it will be unsurprising if that changes.
So it is still not obvious, at least to me, that any crime under US law has occurred so far. I am not a lawyer, though I'm aware of how badly the government has lost the previous court cases that attempted to restrict what humans can put in source code.
If an attacker then actually uses the backdoor created by someone else's decision to deploy the new release into their own environment, to gain unauthorized access to a protected computer system, then obviously there's a CFAA violation there. The public facts don't contain documented examples of this having happened (yet), though it will be unsurprising if that changes.
So it is still not obvious, at least to me, that any crime under US law has occurred so far. I am not a lawyer, though I'm aware of how badly the government has lost the previous court cases that attempted to restrict what humans can put in source code.
From their Git commits, they're in China's time zone.
My git commits are sometimes in UTC, depending on which computer I make them from. Sometimes my laptop just switches timezones depending on whether I'm using wifi or LTE. I wouldn't put much weight on the timezone.
git 提交的时间戳取决于提交签入的计算机的系统时钟。github 和 co 无法检查这一点（除非他们可以拒绝将来具有时间戳的提交）。
Remember that agencies like NSA, GCHQ etc will always use false flags in their code, even when it doesn’t have as high risk of exposure as a backdoor in public has.
Looking at the times of commits shouldn’t be given much value at all. A pretty pointless endeavour.
Looking at the times of commits shouldn’t be given much value at all. A pretty pointless endeavour.
State actors are actually known for not doing that; after all, there's no need to hide when what you're doing is legal. They also tend to work 9-5 in their own timezones.
It might be legal but would (or at least should) be seen as an attack by all other countries using the software, even allies, and in a saner world wouldl receive a strong political response.
但与 Github 的实际交互是在 12:00 UTC 到 18:00 UTC 之间完成的
https://news.ycombinator.com/item?id=39870925
https://play.clickhouse.com/play?user=play#U0VMRUNUIHRvSG91c...
https://news.ycombinator.com/item?id=39870925
https://play.clickhouse.com/play?user=play#U0VMRUNUIHRvSG91c...
有趣的！
正如一些推文回复提到的，他们发布了包含后门的版本，并在“通常”的时间进行了其他有问题的更改。可以肯定的是，我们几乎肯定不会处理受感染的工作站，所以我认为这不能解释最严重的违规更改的不同时间。
也许他有一些技术专家/处理程序/经理必须监督他们何时引入实际的恶意更改，因此这反映了他何时从这些其他人那里得到了继续信号（从而反映了他们的工作时间？）
或者也许他们当时只是在旅行？ （也许是去拜访上述的处理人员？或者去拜访家人……即使罪犯也有父母）
另外，请记住，我的 Clickhouse 查询包括所有 Github 交互（例如，问题评论的时间戳）...并且与 Git 提交时间戳不同，很难伪造这些（因为您需要安排此类评论的发布，可能通过 API。并非不可能，但更容易认为 JiaT75 只是使用 Gitub UI 来编写评论），推文仅提到“提交历史记录”
通常，更简单的解释出错的可能性较小......考虑一些可能性：
- 中国/台湾国家演员，雇用员工朝九晚五（但不知何故，他们的人在当地时间 20:00 - 02:00 工作）
- 中国/台湾流氓组织/独狼...在他们的日常工作之后兼职利用此漏洞（考虑到要与 Lasse 互动，他们将被迫工作到很晚，这并非超出了可能性范围）
- 非中国国家行为者，雇用朝九晚五的人员（与大多数 Github 互动一致），希望将责任归咎于中国/台湾（+0800 时区的提交），这出于某种无法解释的原因在非常奇怪的时间推动了最严重的违规更改。
- 中国/台湾的国家行为者，想要将责任归咎于西方国家行为者（通过使所有的变化有时与在欧洲工作的人兼容），但不知何故，他们在推动最严重的令人反感的变化时犯了错误。
- 中国/台湾的国家行为者，在欧洲雇用某人（如果他们需要获得更改的批准/获得前维护者 Lasse 的信任，那么更好/更多的时区重叠可能是有意义的）...出于某种奇怪（但“无辜”）的原因，保留了他们工作的设备，配置了 +0800 时区
- 非中国国家行为者，假装是一个中国实体，想要将责任归咎于西方实体，并在凌晨 3 点做出了最严重的违规更改（也就是说，这不是一个失误，而是误导努力的一部分。）
其中一些假设有点牵强，但现实比小说更奇怪
正如一些推文回复提到的，他们发布了包含后门的版本，并在“通常”的时间进行了其他有问题的更改。可以肯定的是，我们几乎肯定不会处理受感染的工作站，所以我认为这不能解释最严重的违规更改的不同时间。
也许他有一些技术专家/处理程序/经理必须监督他们何时引入实际的恶意更改，因此这反映了他何时从这些其他人那里得到了继续信号（从而反映了他们的工作时间？）
或者也许他们当时只是在旅行？ （也许是去拜访上述的处理人员？或者去拜访家人……即使罪犯也有父母）
另外，请记住，我的 Clickhouse 查询包括所有 Github 交互（例如，问题评论的时间戳）...并且与 Git 提交时间戳不同，很难伪造这些（因为您需要安排此类评论的发布，可能通过 API。并非不可能，但更容易认为 JiaT75 只是使用 Gitub UI 来编写评论），推文仅提到“提交历史记录”
通常，更简单的解释出错的可能性较小......考虑一些可能性：
- 中国/台湾国家演员，雇用员工朝九晚五（但不知何故，他们的人在当地时间 20:00 - 02:00 工作）
- 中国/台湾流氓组织/独狼...在他们的日常工作之后兼职利用此漏洞（考虑到要与 Lasse 互动，他们将被迫工作到很晚，这并非超出了可能性范围）
- 非中国国家行为者，雇用朝九晚五的人员（与大多数 Github 互动一致），希望将责任归咎于中国/台湾（+0800 时区的提交），这出于某种无法解释的原因在非常奇怪的时间推动了最严重的违规更改。
- 中国/台湾的国家行为者，想要将责任归咎于西方国家行为者（通过使所有的变化有时与在欧洲工作的人兼容），但不知何故，他们在推动最严重的令人反感的变化时犯了错误。
- 中国/台湾的国家行为者，在欧洲雇用某人（如果他们需要获得更改的批准/获得前维护者 Lasse 的信任，那么更好/更多的时区重叠可能是有意义的）...出于某种奇怪（但“无辜”）的原因，保留了他们工作的设备，配置了 +0800 时区
- 非中国国家行为者，假装是一个中国实体，想要将责任归咎于西方实体，并在凌晨 3 点做出了最严重的违规更改（也就是说，这不是一个失误，而是误导努力的一部分。）
其中一些假设有点牵强，但现实比小说更奇怪
We shouldn't rule out the probability that this account is from a U.S. agency as well.
Just so I understand, you're alleging that a U.S. agency was, among other things, submitting patches for a mainland Chinese home-grown CPU architecture (Loongson)?
Aren't you confusing JiaT75 and xry111?
And if someone wanted to attack a target running on Loongson, they would certainly have to make sure the code can actually run there in the first place.
And if someone wanted to attack a target running on Loongson, they would certainly have to make sure the code can actually run there in the first place.
No, they're not. They are saying that due to the extraordinary circumstances with this case US agencies cannot be excluded from suspicion. At this time no actor seems to be a more likely perpetrator than the next. (Keep in mind that false-flag operations are a very common occurrence in cyber warfare and this cannot be ruled out yet.)
It doesn't seem out of the question that the U.S. or allied nations might want to be involved in the development effort around these CPUs. Even if initially it's just to build some credibility for this account so future adversarial patches are accepted with less suspicion? If you think that's implausible, I'm interested why?
We shouldn't rule it out, but it seems unlikely to me.
This is more reckless than any backdoor I can think of by a US agency . NSA backdoored Dual EC DRBG, which was extremely reckless, but this makes that look careful and that was the Zenith of NSA recklessness. The attackers here straight up just cowboy'd the joint. I can't think of any instance in which US intelligence used sock puppets on public forums and mailinglists to encourage deployment of the backdoored software and I maintain a list of NSA backdoors: https://www.ethanheilman.com/x/12/index.html
It just doesn't seem like their style.
This is more reckless than any backdoor I can think of by a US agency . NSA backdoored Dual EC DRBG, which was extremely reckless, but this makes that look careful and that was the Zenith of NSA recklessness. The attackers here straight up just cowboy'd the joint. I can't think of any instance in which US intelligence used sock puppets on public forums and mailinglists to encourage deployment of the backdoored software and I maintain a list of NSA backdoors: https://www.ethanheilman.com/x/12/index.html
It just doesn't seem like their style.
The CIA had plans to commit terrorist acts against American civilians to start a war against Cuba in the 60s. This is quite literally their style. For example, perhaps they were planning to blame the hack of a power plant or critical infrastructure on this exploit, then use the "evidence" that was leaked to prove it was China, and from there carry out an offensive operation against Chinese infrastructure. There are lots of subversive reasons they would want to do this.
The CIA in 2024 really doesn't have any continuity with itself in 1960. Things like the Church Commission changed how it was governed.
You are referring to Operation Northwoods [0], a set of plans from the 1960s, all of which were rejected.
Operation Northwoods came about because Brig. Gen. Edward Lansdale, asked the CIA to come up with a list of pretexts that might be used to justify an invasion of Cuba. This request had a number of planners at the CIA enumerate possible false flags that could be used as a pretext. One of those plans was a terror attack against US citizens. Operation Northwoods was rejected and never implemented.
The US has plans for nearly everything, but there is a massive difference between a plan that some CIA analyst is pitching and something the US is likely or even able to do. The US had all sorts of plans for how to handle a pandemic, but then when one actually happened, the plans couldn't be implemented because the US didn't actually have the capabilities the plans called for.
> example, perhaps they were planning to blame the hack of a power plant or critical infrastructure on this exploit, then use the "evidence" that was leaked to prove it was China, and from there carry out an offensive operation against Chinese infrastructure.
Backdooring OpenSSH would in no way function as a pretext for attacks on Chinese infrastructure. No one outside the tech companies cares about this. The US also doesn't need to invent hacking pretexts, you could just point to one of many exposed Chinese hacking incidents.
[0] : https://en.wikipedia.org/wiki/Operation_Northwoods
Operation Northwoods came about because Brig. Gen. Edward Lansdale, asked the CIA to come up with a list of pretexts that might be used to justify an invasion of Cuba. This request had a number of planners at the CIA enumerate possible false flags that could be used as a pretext. One of those plans was a terror attack against US citizens. Operation Northwoods was rejected and never implemented.
The US has plans for nearly everything, but there is a massive difference between a plan that some CIA analyst is pitching and something the US is likely or even able to do. The US had all sorts of plans for how to handle a pandemic, but then when one actually happened, the plans couldn't be implemented because the US didn't actually have the capabilities the plans called for.
> example, perhaps they were planning to blame the hack of a power plant or critical infrastructure on this exploit, then use the "evidence" that was leaked to prove it was China, and from there carry out an offensive operation against Chinese infrastructure.
Backdooring OpenSSH would in no way function as a pretext for attacks on Chinese infrastructure. No one outside the tech companies cares about this. The US also doesn't need to invent hacking pretexts, you could just point to one of many exposed Chinese hacking incidents.
[0] : https://en.wikipedia.org/wiki/Operation_Northwoods
CISA Advisory:
https://www.cisa.gov/news-events/alerts/2024/03/29/reported-...
Note that it say "Fedora 41" in the CISA page link to Red Hat, but Red Hat changed the blog title to "Fedora 40" and left the HTML page title as "Fedora 41".
Note that it say "Fedora 41" in the CISA page link to Red Hat, but Red Hat changed the blog title to "Fedora 40" and left the HTML page title as "Fedora 41".
And I bet if it ended up on a NATO system, things escalate quickly for the person / nation states being scrutinized (https://www.nato.int/cps/en/natohq/topics_78170.htm)
A federal investigation into what, itself? The primary actors doing this type of thing are the US Government.
> Getting punched in the face is actually a necessary human condition for a healthy civilization.
Aside from signed commits, we need to bring back GPG key parties and web of trust. When using a project you would know how many punches away from the committers you are.
Aside from signed commits, we need to bring back GPG key parties and web of trust. When using a project you would know how many punches away from the committers you are.
PGP is more famous for "web of trust" topologies, not chains of trust.
For all of their nerd cred, key parties didn't accomplish very much (as evidenced by the fact that nothing on the Internet really broke when the WoT imploded a few years ago[1]). The "real" solution here is mostly cultural: treating third-party software like the risky thing it actually is, rather than a free source of pre-screened labor.
[1]: https://inversegravity.net/2019/web-of-trust-dead/
For all of their nerd cred, key parties didn't accomplish very much (as evidenced by the fact that nothing on the Internet really broke when the WoT imploded a few years ago[1]). The "real" solution here is mostly cultural: treating third-party software like the risky thing it actually is, rather than a free source of pre-screened labor.
[1]: https://inversegravity.net/2019/web-of-trust-dead/
Chain/web was typo, corrected, thanks.
I know of the key party issues. But there is some value to knowing how far removed from me and people I trust the project authors are.
I know of the key party issues. But there is some value to knowing how far removed from me and people I trust the project authors are.
> But there is some value to knowing how far removed from me and people I trust the project authors are
That's true!
That's true!
Nowadays i achieve this with linkedin[1] connections. Less nerd cred, but achieves roughly the same purpose (most of the people I care about in my niche are at most a 3rd degree connection - a friend of a friend of a friend).
[1] formerly also twitter, at least partially.
[1] formerly also twitter, at least partially.
Yes, but there was also little pressure to really build the WOT. People, like myself, did it because it was fun, but no one really relied on it. This could change, but it is still far from certain if it'd work given enough pressure.
The web of punches?
> Getting punched in the face is actually a necessary human condition for a healthy civilization.
This is factually false - in fact, it's literally the direct opposite of the truth. "Getting punched in the face" is base violence that is incompatible with a healthy civilization. A good government with a robust justice system is what is actually needed for a healthy civilization.
This is factually false - in fact, it's literally the direct opposite of the truth. "Getting punched in the face" is base violence that is incompatible with a healthy civilization. A good government with a robust justice system is what is actually needed for a healthy civilization.
Is this a crime? Has anyone been prosecuted for adding a backdoor like this?
Has anyone been prosecuted for adding a backdoor
Google up Randal Schwartz. Caution: clickhole.
Google up Randal Schwartz. Caution: clickhole.
Seems a little different. Based on a quick read, he gained unauthorized access to systems.
In this case, backdoor code was offered to and accepted by xz maintainers.
In this case, backdoor code was offered to and accepted by xz maintainers.
Lots of things are crimes even though they're just offering something to a victim who willingly accepts it, e.g. phishing attacks, fraudulent investment schemes, contaminated food products.
Sure. I'm wondering if there is a specific law that was broken here. It seems to me that it might be beneficial if there were some legal protection against this sort of act.
As far as I remember, he added no backdoors.
He was a consultant/sysadmin for Intel, and he did 3 things which he thought his employer would support, and was astonished to find that not only did his employer not support, but actively had him prosecuted for doing it. Ouch.
1. He ran a reverse-proxy on two machines so he could check in on them from home.
2. He used the crack program to find weak passwords.
3. He found a weak password, and used it to log into a system, which he copied the /etc/shadow file from to look for additional weak passwords.
https://www.giac.org/paper/gsec/4039/intel-v-randal-l-schwar...
https://web.archive.org/web/20160216204357/http://www.lightl...
He didn't try and hide his activities, and didn't do anything else untoward, it was literally just these things which most people wouldn't bat an eyelid at. These days, it is completely normal for a company to provide VPNs for their employees, and completely normal to continually scan for unexpected user accounts or weak passwords. But... because he didn't explain this to higher-ups and get their buy-in, they prosecuted him instead of thanking him.
He was a consultant/sysadmin for Intel, and he did 3 things which he thought his employer would support, and was astonished to find that not only did his employer not support, but actively had him prosecuted for doing it. Ouch.
1. He ran a reverse-proxy on two machines so he could check in on them from home.
2. He used the crack program to find weak passwords.
3. He found a weak password, and used it to log into a system, which he copied the /etc/shadow file from to look for additional weak passwords.
https://www.giac.org/paper/gsec/4039/intel-v-randal-l-schwar...
https://web.archive.org/web/20160216204357/http://www.lightl...
He didn't try and hide his activities, and didn't do anything else untoward, it was literally just these things which most people wouldn't bat an eyelid at. These days, it is completely normal for a company to provide VPNs for their employees, and completely normal to continually scan for unexpected user accounts or weak passwords. But... because he didn't explain this to higher-ups and get their buy-in, they prosecuted him instead of thanking him.
To be fair, it is perfectly normal for a surgeon to cut people with a sharp knife with their permission while in the hospital.
It is kinda sus when they do it at home without consent.
It is kinda sus when they do it at home without consent.
I find it useful to compare the reactions of O'Reilly and Intel. Schwartz worked for both (he wrote Learning Perl and co-authored Programming Perl for O'Reilly and made them plenty of money). He cracked the passwords of both companies without first getting permission.
O'Reilly's sysadmin told him off for not getting permission, and told him not to do it again, but used his results to let people with weak passwords know to change them.
Intel's sysadmin started collecting a dossier on Schwartz and ultimately Intel pushed for state criminal charges against him.
O'Reilly's sysadmin testified in Schwartz's defense that he was an overly eager guy with no nefarious intent. So - kinda-sus or not - Intel could have resolved this with a dressing down, or even termination if they were really unhappy. Intel _chose_ to go nuclear, and invoke the Oregon computer crime laws, and demand the state prosecute him.
O'Reilly's sysadmin told him off for not getting permission, and told him not to do it again, but used his results to let people with weak passwords know to change them.
Intel's sysadmin started collecting a dossier on Schwartz and ultimately Intel pushed for state criminal charges against him.
O'Reilly's sysadmin testified in Schwartz's defense that he was an overly eager guy with no nefarious intent. So - kinda-sus or not - Intel could have resolved this with a dressing down, or even termination if they were really unhappy. Intel _chose_ to go nuclear, and invoke the Oregon computer crime laws, and demand the state prosecute him.
apparently he did that after leaving the company, which is pretty sus.
Fascinating. Just yesterday the author added a `SECURITY.md` file to the `xz-java` project.
> If you discover a security vulnerability in this project please report it privately. *Do not disclose it as a public issue.* This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released.
Reading that in a different light, it says give me time to adjust my exploits and capitalize on any targets. Makes me wonder what other vulns might exist in the author's other projects.
> If you discover a security vulnerability in this project please report it privately. *Do not disclose it as a public issue.* This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released.
Reading that in a different light, it says give me time to adjust my exploits and capitalize on any targets. Makes me wonder what other vulns might exist in the author's other projects.
90 day dark window for maintainers is SOP though. Then after 90 days, it’s free game for public disclosure
How many of people like this one exist?
If this question had a reliable (and public) answer then the world would be a very different place!
That said, this is an important question. We, particularly those us who work on critical infrastructure or software, should be asking ourselves this regularly to help prevent this type of thing.
Note that it's also easy (and similarly catastrophic) to swing too far the other way and approach all unknowns with automatic paranoia. We live in a world where we have to trust strangers every day, and if we lose that option completely then our civilization grinds to a halt.
But-- vigilance is warranted. I applaud these engineers who followed their instincts and dug into this. They all did us a huge service!
EDIT: wording, spelling
That said, this is an important question. We, particularly those us who work on critical infrastructure or software, should be asking ourselves this regularly to help prevent this type of thing.
Note that it's also easy (and similarly catastrophic) to swing too far the other way and approach all unknowns with automatic paranoia. We live in a world where we have to trust strangers every day, and if we lose that option completely then our civilization grinds to a halt.
But-- vigilance is warranted. I applaud these engineers who followed their instincts and dug into this. They all did us a huge service!
EDIT: wording, spelling
Yeah thanks for saying this; I agree. And as cliche as it is to look for a technical solution to a social problem, I also think better tools could help a lot here.
The current situation is ridiculous - if I pull in a compression library from npm, cargo or Python, why can that package interact with my network, make syscalls (as me) and read and write files on my computer? Leftpad shouldn’t be able to install crypto ransomware on my computer.
To solve that, package managers should include capability based security. I want to say “use this package from cargo, but refuse to compile or link into my binary any function which makes any syscall except for read and write. No open - if I want to compress or decompress a file, I’ll open the file myself and pass it in.” No messing with my filesystem. No network access. No raw asm, no trusted build scripts and no exec. What I allow is all you get.
The capability should be transitive. All dependencies of the package should be brought in under the same restriction.
In dynamic languages like (server side) JavaScript, I think this would have to be handled at runtime. We could add a capability parameter to all functions which issue syscalls (or do anything else that’s security sensitive). When the program starts, it gets an “everything” capability. That capability can be cloned and reduced to just the capabilities needed. (Think, pledge). If I want to talk to redis using a 3rd party library, I pass the redis package a capability which only allows it to open network connections. And only to this specific host on this specific port.
It wouldn’t stop all security problems. It might not even stop this one. But it would dramatically reduce the attack surface of badly behaving libraries.
The current situation is ridiculous - if I pull in a compression library from npm, cargo or Python, why can that package interact with my network, make syscalls (as me) and read and write files on my computer? Leftpad shouldn’t be able to install crypto ransomware on my computer.
To solve that, package managers should include capability based security. I want to say “use this package from cargo, but refuse to compile or link into my binary any function which makes any syscall except for read and write. No open - if I want to compress or decompress a file, I’ll open the file myself and pass it in.” No messing with my filesystem. No network access. No raw asm, no trusted build scripts and no exec. What I allow is all you get.
The capability should be transitive. All dependencies of the package should be brought in under the same restriction.
In dynamic languages like (server side) JavaScript, I think this would have to be handled at runtime. We could add a capability parameter to all functions which issue syscalls (or do anything else that’s security sensitive). When the program starts, it gets an “everything” capability. That capability can be cloned and reduced to just the capabilities needed. (Think, pledge). If I want to talk to redis using a 3rd party library, I pass the redis package a capability which only allows it to open network connections. And only to this specific host on this specific port.
It wouldn’t stop all security problems. It might not even stop this one. But it would dramatically reduce the attack surface of badly behaving libraries.
Doesn't this exact exploit not fixed by your capability theory?
It is hijacking a process that has network access at runtime not build time.
The build hack grabs files from the repo and inspects build parameters (in a benign way, everyone checks whether you are running on X platform etc)
It is hijacking a process that has network access at runtime not build time.
The build hack grabs files from the repo and inspects build parameters (in a benign way, everyone checks whether you are running on X platform etc)
The problem we have right now is that any linked code can do anything, both at build time and at runtime. A good capability system should be able to stop xz from issuing network requests even if other parts of the process do interact with the network. It certainly shouldn't have permission to replace crc32_resolve() and crc64_resolve() via ifunc.
Another way of thinking about the problem is that right now every line of code within a process runs with the same permissions. If we could restrict what 3rd party libraries can do - via checks either at build time or runtime - then supply chain attacks like this would be much harder to pull off.
Another way of thinking about the problem is that right now every line of code within a process runs with the same permissions. If we could restrict what 3rd party libraries can do - via checks either at build time or runtime - then supply chain attacks like this would be much harder to pull off.
I'm not convinced this is such a cure-all as any library must necessarily have the ability to "taint" its output. Like consider this library. It's a compression library. You would presumably trust it to decompress things right? Like programs? And then you run those programs with full permission? Oops..
It’s not a cure-all. I mean, we’re talking about infosec - so nothing is. But that said, barely any programs need the ability to execute arbitrary binaries. I can’t remember the last time I used eval() in JavaScript.
I agree that it wouldn’t stop this library from injecting backdoors into decompressed executables. But I still think it would be a big help anyway. It would stop this attack from working.
At the big picture, we need to acknowledge that we can’t implicitly trust opensource libraries on the internet. They are written by strangers, and if you wouldn’t invite them into your home you shouldn’t give them permission to execute arbitrary code with user level permissions on your computer.
I don’t think there are any one size fits all answers here. And I can’t see a way to make your “tainted output” idea work. But even so, cutting down the trusted surface area from “leftpad can cryptolocker your computer” to “Leftpad could return bad output” sounds like it would move us in the right direction.
I agree that it wouldn’t stop this library from injecting backdoors into decompressed executables. But I still think it would be a big help anyway. It would stop this attack from working.
At the big picture, we need to acknowledge that we can’t implicitly trust opensource libraries on the internet. They are written by strangers, and if you wouldn’t invite them into your home you shouldn’t give them permission to execute arbitrary code with user level permissions on your computer.
I don’t think there are any one size fits all answers here. And I can’t see a way to make your “tainted output” idea work. But even so, cutting down the trusted surface area from “leftpad can cryptolocker your computer” to “Leftpad could return bad output” sounds like it would move us in the right direction.
There are attacks that embed hacks into built compilers so unless you are looking to write your software from scratch you need to trust people.
And by scratch I mean "without modern hardware" given supply chain attacks also apply to the hardware you build from.
And by scratch I mean "without modern hardware" given supply chain attacks also apply to the hardware you build from.
Of course we need to trust people to some degree. There's an old Jewish saying - put your trust in god, but your money in the bank. I think its like that. I'm all for trusting people - but I still like how my web browser sandboxes every website I visit. That is a good idea.
We (obviously) put too much trust in little libraries like xz. I don't see a world in which people start using fewer dependencies in their projects. So given that, I think anything which makes 3rd party dependencies safer than they are now is a good thing. Hence the proposal.
The downside is it adds more complexity. Is that complexity worth it? Hard to say. Thats still worth talking about.
We (obviously) put too much trust in little libraries like xz. I don't see a world in which people start using fewer dependencies in their projects. So given that, I think anything which makes 3rd party dependencies safer than they are now is a good thing. Hence the proposal.
The downside is it adds more complexity. Is that complexity worth it? Hard to say. Thats still worth talking about.
i guess the big opensource community should put a little bit more trust in statistics or integrate statistic evaluation in their decission making to use specific products in their supply chains.
there are some researches on the right track already https://www.se.cs.uni-saarland.de/projects/congruence/
there are some researches on the right track already https://www.se.cs.uni-saarland.de/projects/congruence/
This approach could work for dynamic libraries, but a lot of modern ecosystems (Go, Rust, Swift) prefer to distribute packages as source code that gets compiled with the including executable or library.
Yes, and?
The goal is to restrict what included libraries can do. As you say, in languages like Rust, Go or Swift, the mechanism to do this would also need to work with statically linked code to work. And thats quite tricky, because there are no isolation boundaries between functions in executables.
It should still be possible to build something like this. It would just be inconvenient. In rust, swift and go you'd probably want to implement something like this at compile time.
In rust, I'd start by banning unsafe in dependencies. (Or whitelisting which projects are allowed to use unsafe code.) Then add special annotations on all the methods in the standard library which need special permissions to run. For example, File::open, fork, exec, networking, and so on. In cargo.toml, add a way to specify which permissions your child libraries get. "Import serde, but give it no OS permissions". When you compile your program, the compiler can look at the call tree of each function to see what actually gets called, and make sure the permissions match up. If you call a function in serde which in turn calls File::open (directly or indirectly), and you didn't explicitly allow that, the program should fail to compile.
It should be fine for serde to contain some utility function that calls the banned File::open, so long as the utility function isn't called.
Permissions should be in a tree. As you get further out in the dependency tree, libraries get fewer permissions. If I pass permissions {X,Y} to serde, serde can pass permission {X} to one of its dependencies in turn. But serde can't pass permission {Q} to its dependency - since it doesn't have that capability itself.
Any libraries which use unsafe are sort of trusted to do everything. You might need to insist that any package which calls unsafe code is actively whitelisted by the cargo.toml file in the project root.
The goal is to restrict what included libraries can do. As you say, in languages like Rust, Go or Swift, the mechanism to do this would also need to work with statically linked code to work. And thats quite tricky, because there are no isolation boundaries between functions in executables.
It should still be possible to build something like this. It would just be inconvenient. In rust, swift and go you'd probably want to implement something like this at compile time.
In rust, I'd start by banning unsafe in dependencies. (Or whitelisting which projects are allowed to use unsafe code.) Then add special annotations on all the methods in the standard library which need special permissions to run. For example, File::open, fork, exec, networking, and so on. In cargo.toml, add a way to specify which permissions your child libraries get. "Import serde, but give it no OS permissions". When you compile your program, the compiler can look at the call tree of each function to see what actually gets called, and make sure the permissions match up. If you call a function in serde which in turn calls File::open (directly or indirectly), and you didn't explicitly allow that, the program should fail to compile.
It should be fine for serde to contain some utility function that calls the banned File::open, so long as the utility function isn't called.
Permissions should be in a tree. As you get further out in the dependency tree, libraries get fewer permissions. If I pass permissions {X,Y} to serde, serde can pass permission {X} to one of its dependencies in turn. But serde can't pass permission {Q} to its dependency - since it doesn't have that capability itself.
Any libraries which use unsafe are sort of trusted to do everything. You might need to insist that any package which calls unsafe code is actively whitelisted by the cargo.toml file in the project root.
>It should still be possible to build something like this. It would just be inconvenient.
Inconvenient is quite the understatement. Designing and implementing something like this for each and every language compiler/runtime requires hugely more effort than doing it on the OS level. The likelihood of mistakes is also far greater.
Perhaps it's worth exploring whether it can be done on the LLVM level so that at least some languages can share an implementation.
Inconvenient is quite the understatement. Designing and implementing something like this for each and every language compiler/runtime requires hugely more effort than doing it on the OS level. The likelihood of mistakes is also far greater.
Perhaps it's worth exploring whether it can be done on the LLVM level so that at least some languages can share an implementation.
Do you understand how ifuncs work? They are in the address space in the application that they run in. liblzma is resolving its own pointers!
if I got it right, the attack uses glibc IFUNC mechanism to patch sshd (and only sshd) to directly run some code in liblzma when sshd verifies logins.
so the problem is IFUNC mechanism, which has its valid uses but can be EASILY misused for any sort of attacks
so the problem is IFUNC mechanism, which has its valid uses but can be EASILY misused for any sort of attacks
Honestly, I don't have a lot of hope that we can fix this problem for C on linux. There's just so much historical cruft in present, spread between autotools, configure, make, glibc, gcc and C itself that would need to be modified to support capabilities.
The rule we need is "If I pull in library X with some capability set, then X can't do anything not explicitly allowed by the passed set of capabilities". The problem in C is that there is currently no straightforward way to firewall off different parts of a linux process from each other. And dynamic linking on linux is done by gluing together compiled artifacts - with no way to check or understand what assembly instructions any of those parts contain.
I see two ways to solve this generally:
- Statically - ie at compile time, the compiler annotates every method with a set of permissions it (recursively) requires. The program fails to compile if a method is called which requires permissions that the caller does not pass it. In rust for example, I could imagine cargo enforcing this for rust programs. But I think it would require some changes to the C language itself if we want to add capabilities there. Maybe some compiler extensions would be enough - but probably not given a C program could obfuscate which functions call which other functions.
- Dynamically. In this case, every linux system call is replaced with a new version which takes a capability object as a parameter. When the program starts, it is given a capability by the OS and it can then use that to make child capabilities passed to different libraries. I could imagine this working in python or javascript. But for this to work in C, we need to stop libraries from just scanning the process's memory and stealing capabilities from elsewhere in the program.
The rule we need is "If I pull in library X with some capability set, then X can't do anything not explicitly allowed by the passed set of capabilities". The problem in C is that there is currently no straightforward way to firewall off different parts of a linux process from each other. And dynamic linking on linux is done by gluing together compiled artifacts - with no way to check or understand what assembly instructions any of those parts contain.
I see two ways to solve this generally:
- Statically - ie at compile time, the compiler annotates every method with a set of permissions it (recursively) requires. The program fails to compile if a method is called which requires permissions that the caller does not pass it. In rust for example, I could imagine cargo enforcing this for rust programs. But I think it would require some changes to the C language itself if we want to add capabilities there. Maybe some compiler extensions would be enough - but probably not given a C program could obfuscate which functions call which other functions.
- Dynamically. In this case, every linux system call is replaced with a new version which takes a capability object as a parameter. When the program starts, it is given a capability by the OS and it can then use that to make child capabilities passed to different libraries. I could imagine this working in python or javascript. But for this to work in C, we need to stop libraries from just scanning the process's memory and stealing capabilities from elsewhere in the program.
Or take the Chrome / original Go approach: load that code in a different process, use some kind of RPC. With all the context switch penalty... sigh, I think it is the only way, as the MMU permissions work at a page level.
Firefox also has its solution of compiling dependencies to wasm, then compiling the wasm back into C code and linking that. It’s super weird, but the effect is that each dependency ends up isolated in bounds checked memory. No context switch penalty, but instead the code runs significantly slower.
A process can do little to defend itself from a library it's using which has full access to its same memory. There is no security boundary there. This kind of backdoor doesn't hinge on IFUNC's existence.
The problem is that the attacker has code execution in sshd, not ifuncs
Assume 3% of the population is malicious.
Enough to be cautious, enough to think about how to catch bad actors, not so much as to close yourself off and become a paranoid hermit.
Enough to be cautious, enough to think about how to catch bad actors, not so much as to close yourself off and become a paranoid hermit.
呵呵。我从来没有真正考虑过它是一个百分比。
在人生的不同阶段，我曾邪恶、精彩、冷漠。
我认识一些为了金钱、名誉和无聊而做类似事情的人。
我认为，考虑到背景、激励、机会和资源，大多数人都有可能从不愿入伍转入入伍。
事实证明，在合规性方面，杠杆是最大的杠杆。
在人生的不同阶段，我曾邪恶、精彩、冷漠。
我认识一些为了金钱、名誉和无聊而做类似事情的人。
我认为，考虑到背景、激励、机会和资源，大多数人都有可能从不愿入伍转入入伍。
事实证明，在合规性方面，杠杆是最大的杠杆。
We live in a time of populous, wealthy dictatorships that have computer-science expertise are openly hostile to the US and Canada.
North America is only about 5% of the world's population. [1] (We can assume that malicious actors are in North America, too, but this helps to adjust our perspective.)
The percentage of maliciousness on the Internet is much higher.
[1] _ See continental subregions. https://en.wikipedia.org/wiki/List_of_continents_and_contine...
North America is only about 5% of the world's population. [1] (We can assume that malicious actors are in North America, too, but this helps to adjust our perspective.)
The percentage of maliciousness on the Internet is much higher.
[1] _ See continental subregions. https://en.wikipedia.org/wiki/List_of_continents_and_contine...
tomthehero(1)
Huh? The empirical evidence we have - thanks to Snowden leaks - paints a different picture. NSA is the biggest malicious actor with nearly unlimited resources at hand. They even insert hardware backdoors and intercept shipment to do that.
> NSA is the biggest malicious actor
I'm curious, how do you rank CN, RU, and IR?
I'm curious, how do you rank CN, RU, and IR?
They are all active players, but no where close to the top dog.
That doesn't mean that the entire population of those countries is actively hostile to you.
The US government itself is openly hostile to the US (as well as to the rest of the world).
> The percentage of maliciousness on the Internet is much higher.
A baseless assumption.
> The percentage of maliciousness on the Internet is much higher.
A baseless assumption.
Threat actors create personas. We will need strong social trust to protect our important projects and dependencies.
> We, particularly those us who work on critical infrastructure or software
We should also be asking ourselves if we are working on critical infrastructure. Lasse Collin probably did not consider liblzma being loaded by sshd when vetting the new maintainer. Did the xz project ever agree to this responsibility?
We should also be asking ourselfs if each dependency of critical infrastructure is worth the risk. sshd linking libsystemd just to write a few bytes into an open fd is absurd. libsystemd pulling in liblzma because hey it also does compressed logging is absurd. Yet this kind of absurd dependency bloat is everywhere.
We should also be asking ourselves if we are working on critical infrastructure. Lasse Collin probably did not consider liblzma being loaded by sshd when vetting the new maintainer. Did the xz project ever agree to this responsibility?
We should also be asking ourselfs if each dependency of critical infrastructure is worth the risk. sshd linking libsystemd just to write a few bytes into an open fd is absurd. libsystemd pulling in liblzma because hey it also does compressed logging is absurd. Yet this kind of absurd dependency bloat is everywhere.
> How many of people like this one exist?
I guess every 3 letter agency has at least one. You can do the math. They havent't learned anything after Solar Winds.
I guess every 3 letter agency has at least one. You can do the math. They havent't learned anything after Solar Winds.
Security Researchers: Is this request-for-private-disclosure + "90-days before public" reasonable?
It's a SEVERE issue, to my mind, and 90 days seems too long to me.
It's a SEVERE issue, to my mind, and 90 days seems too long to me.
Whether its reasonable is debatable, but that type of time frame is pretty normal for things that aren't being actively exploited.
This situation is perhaps a little different as its not an accidental bug waiting to be discovered but an intentionally placed exploit. We know that a malicious person already knows about it.
This situation is perhaps a little different as its not an accidental bug waiting to be discovered but an intentionally placed exploit. We know that a malicious person already knows about it.
If you were following Google Project Zero's policy (which many researchers do), any in-the-wild exploits would trigger an immediate reveal.
Detecting a security issue is one thing. Detecting a malicious payload is something completely different. The latter has intent to exploit and must be addressed immediately. The former has at least some chance of noone knowing about it.
In this particular case, there is a strong reason to expect exploitation in the wild to already be occurring (because it's an intentional backdoor) and this would change the risk calculus around disclosure timelines.
But in the general case, it's normal for 90 days to be given for the coordinated patching of even very severe vulnerabilities -- you are giving time not just to the project maintainers, but to the users of the software to finish updating their systems to a new fixed release, before enough detail to easily weaponize the vulnerability is shared. Google Project Zero is an example of a team with many critical impact findings using a 90-day timeline.
But in the general case, it's normal for 90 days to be given for the coordinated patching of even very severe vulnerabilities -- you are giving time not just to the project maintainers, but to the users of the software to finish updating their systems to a new fixed release, before enough detail to easily weaponize the vulnerability is shared. Google Project Zero is an example of a team with many critical impact findings using a 90-day timeline.
As someone in security who doesn't work at a major place that get invited to the nice pre-notification notifications, I hate this practice.
My customers and business are not any less important or valuable than anyone else's, and I should not be left being potentially exploited, and my customers harmed, for 90 more days while the big guys get to patch their systems (thinking of e.g. Log4J, where Amazon, Meta, Google, and others were told privately how to fix their systems, before others were even though the fix was simple).
Likewise, as a customer I should get to know as soon as someone's software is found vulnerable, so I can then make the choice whether to continue to subject myself to the risk of continuing to use it until it gets patched.
My customers and business are not any less important or valuable than anyone else's, and I should not be left being potentially exploited, and my customers harmed, for 90 more days while the big guys get to patch their systems (thinking of e.g. Log4J, where Amazon, Meta, Google, and others were told privately how to fix their systems, before others were even though the fix was simple).
Likewise, as a customer I should get to know as soon as someone's software is found vulnerable, so I can then make the choice whether to continue to subject myself to the risk of continuing to use it until it gets patched.
OpenSSL's "notification of an upcoming critical release" is public, not private.
You do get to know that the vulnerability exists quickly, and you could choose to stop using OpenSSL altogether (among other mitigations) once that email goes out.
You do get to know that the vulnerability exists quickly, and you could choose to stop using OpenSSL altogether (among other mitigations) once that email goes out.
if your system has already been compromised at the root level, it does not matter in the least bit
Well if you assume everyone has already been exploited, disclosing quickly vs slowly won't prevent that.
Also, if something is being actively exploited, usually there's no or very little embargo.
Also, if something is being actively exploited, usually there's no or very little embargo.
I empathize with this as I've been in the same boat, but all entities are not equal when performing triage.
Being in a similar boat, I heartily agree.
But I don't want anyone else to get notified immediately because the odds that somebody will start exploiting people before a patch is available is pretty high. Since I can't have both, I will choose the 90 days for the project to get patches done and all the packagers to include them and make them available, so that by the time it's public knowledge I'm already patched.
I think this is a Tragedy of the Commons type of problem.
Caveat: This assume the vuln is found by a white hat. If it's being exploited already or is known to others, then I fully agree the disclosure time should be eliminated and it's BS for the big companies to get more time than us.
But I don't want anyone else to get notified immediately because the odds that somebody will start exploiting people before a patch is available is pretty high. Since I can't have both, I will choose the 90 days for the project to get patches done and all the packagers to include them and make them available, so that by the time it's public knowledge I'm already patched.
I think this is a Tragedy of the Commons type of problem.
Caveat: This assume the vuln is found by a white hat. If it's being exploited already or is known to others, then I fully agree the disclosure time should be eliminated and it's BS for the big companies to get more time than us.
Yeah I worked in FAANG when we got the advance notice of a number of CVEs. Personally I think it's shady, I don't care how big Amazon or Google is, they shouldn't get special privileges because they are a large corporation.
I don't think the rationale is that they are a large corporation or have lots of money. It's that they have many, many, many more users that would be affected than most companies have.
I imagine they also have significant resources to contribute to dealing with breaches - eg, analysing past cookouts by the bad actor, designing mitigations, etc.
> My ... business are not any less ... valuable than anyone else's,
Plainly untrue. The reason they keep distribution minimal is to maximise the chance of keeping the vuln secret. Your business is plainly less valuable than google, than walmart, than godaddy, than BoA. Maybe you're some big cheese with a big reputation to keep, but seeing as you're feeling excluded, I guess these orgs have no more reason to trust you than they have to trust me, or hundreds of thousands of others who want to know. If they let you in, they'd let all the others in, and odds are greatly increased that now your customers are at risk from something one of these others has worked out, and either blabbed about or has themselves a reason to exploit it.
Similarly plainly, by disclosing to 100 major companies, they protect a vast breadth of consumers/customer-businesses of these major companies at a risk of 10,000,000/100 (or even less, given they may have more valuable reputation to keep). Changing that risk to 12,000,000/10,000 is, well, a risk they don't feel is worth taking.
Plainly untrue. The reason they keep distribution minimal is to maximise the chance of keeping the vuln secret. Your business is plainly less valuable than google, than walmart, than godaddy, than BoA. Maybe you're some big cheese with a big reputation to keep, but seeing as you're feeling excluded, I guess these orgs have no more reason to trust you than they have to trust me, or hundreds of thousands of others who want to know. If they let you in, they'd let all the others in, and odds are greatly increased that now your customers are at risk from something one of these others has worked out, and either blabbed about or has themselves a reason to exploit it.
Similarly plainly, by disclosing to 100 major companies, they protect a vast breadth of consumers/customer-businesses of these major companies at a risk of 10,000,000/100 (or even less, given they may have more valuable reputation to keep). Changing that risk to 12,000,000/10,000 is, well, a risk they don't feel is worth taking.
> Your business is plainly less valuable than google, than walmart, than godaddy, than BoA.
The company I work for has a market cap roughly 5x that of goDaddy and we're responsible for network connected security systems that potentially control whether a person can physically access your home, school, or business. We were never notified of this until this HN thread.
If your BofA account gets hacked you lose money. If your GoDaddy account gets hacked you lose your domain. If Walmart gets hacked they lose... What money and have logistics issues for a while?
Thankfully my company's products have additional safeguards and this isn't a breach for us. But what if it was? Our customers can literally lose their lives if someone cracks the security and finds a way to remotely open all the locks in their home or business.
Don't tell me that some search engine profits or someone's emails history is "more valuable" than 2000 schoolchildren's lives.
How about you give copies of the keys to your apartment and a card containing your address to 50 random people on the streets and see if you still feel that having your Gmail account hacked is more valuable.
The company I work for has a market cap roughly 5x that of goDaddy and we're responsible for network connected security systems that potentially control whether a person can physically access your home, school, or business. We were never notified of this until this HN thread.
If your BofA account gets hacked you lose money. If your GoDaddy account gets hacked you lose your domain. If Walmart gets hacked they lose... What money and have logistics issues for a while?
Thankfully my company's products have additional safeguards and this isn't a breach for us. But what if it was? Our customers can literally lose their lives if someone cracks the security and finds a way to remotely open all the locks in their home or business.
Don't tell me that some search engine profits or someone's emails history is "more valuable" than 2000 schoolchildren's lives.
How about you give copies of the keys to your apartment and a card containing your address to 50 random people on the streets and see if you still feel that having your Gmail account hacked is more valuable.
Sorry, but that's not a serious risk analysis. The average person would be hurt a lot more by a godaddy breach by a state actor than by a breach of your service by a state actor.
I think from an exposure point of view, I'm less likely to worry about the software side of my physical security being exploited that the actual hardware side.
None of the points you make are relevant since I have yet to see any software based entry product whose software security can be concidered more than lackluster at best, maybe your company is better since you didn't mention a name I can't say otherwise.
What I'm saying is your customers are more likely to have their doors physically broken than remotely opened by software and you are here on about life and death because of a vuln in xz?
If your companies market cap is as high as you say and they are as security aware as you say why aren't they employing security researchers and actively on the forefront of finding vulns and reporting them? That would get them an invite to the party.
None of the points you make are relevant since I have yet to see any software based entry product whose software security can be concidered more than lackluster at best, maybe your company is better since you didn't mention a name I can't say otherwise.
What I'm saying is your customers are more likely to have their doors physically broken than remotely opened by software and you are here on about life and death because of a vuln in xz?
If your companies market cap is as high as you say and they are as security aware as you say why aren't they employing security researchers and actively on the forefront of finding vulns and reporting them? That would get them an invite to the party.
Man if it was ever appropriate to tell someone to touch grass this would be it.
The think of the children part is a nice touch as well. 10/10 copypasta would repost.
The think of the children part is a nice touch as well. 10/10 copypasta would repost.
> Your business is plainly less valuable than google, than walmart, than godaddy, than BoA.
Keep in mind it's the EROI not market cap.
A company is worth attacking if their reward:effort ratio is right. Smaller companies have a much lower effort required.
Keep in mind it's the EROI not market cap.
A company is worth attacking if their reward:effort ratio is right. Smaller companies have a much lower effort required.
[deleted]
> My customers and business are not any less important or valuable than anyone else's
Of course they are. If Red Hat has a million times more customers than you do then they are collectively more valuable almost by definition.
Of course they are. If Red Hat has a million times more customers than you do then they are collectively more valuable almost by definition.
If OP is managing something that is critical to life - think fire suppression controllers, or computers that are connected to medical equipment, I think it becomes very difficult to compare that against financial assets.
Such systems should be airgapped…
I can think of two approaches for such companies:
a. Use commercial OS vendors who will push out fixes.
b. Set up a Continuous Integration process where everything is open source and is built from the ground up, with some reliance on open source platforms such as distros.
One needs different types of competence and IT Operational readiness in each approach.
a. Use commercial OS vendors who will push out fixes.
b. Set up a Continuous Integration process where everything is open source and is built from the ground up, with some reliance on open source platforms such as distros.
One needs different types of competence and IT Operational readiness in each approach.
> b. Set up a Continuous Integration process where everything is open source and is built from the ground up, with some reliance on open source platforms such as distros.
How would that have prevented this backdoor?
How would that have prevented this backdoor?
At a certain scale, "economic" systems become critical to life. Someone who has sufficiently compromised a systemically-important bank can do things that would result in riots breaking out on the street all over a country.
Something that is critical to life should not be connected to Internet.
And yet it seems like every new car is.
Sshhh now you are starting to talk like a rightwinger. Alex Jones has been saying this for a long time ;)
You could use the EPA dollar to life conversion ratio.
Though anything actually potentially lethal shouldn't really have a standard Internet connection. E.g. nuclear power plants, trains, planes controls, heavy industrial equipment, nuclear weapons...
Though anything actually potentially lethal shouldn't really have a standard Internet connection. E.g. nuclear power plants, trains, planes controls, heavy industrial equipment, nuclear weapons...
In that case OP should not design systems were a sshd compromise can have a life-threatening impact. Just because it's easier for everything to be controlled from the cloud doesn't mean that others need to feel sympathy when that turnes out to be as bad of an idea as everyone else has said.
> My customers and business are not any less important or valuable than anyone else's
Hate to break it to you but yes they are.
Hate to break it to you but yes they are.
> but to the users of the software to finish updating their systems to a new fixed release,
Is there "a new fixed release" ?
Is there "a new fixed release" ?
I think you have to take the credibility of the maintainer into account.
If it's a large company, made of people with names and faces, with a lot to lose by hacking its users, they're unlikely to abuse private disclosure. If it's some tiny library, the maintainers might be in on it.
Also, if there's evidence of exploitation in the wild, the embargo is a gift to the attacker. The existence of a vulnerability in that case should be announced, even if the specifics have to be kept under embargo.
If it's a large company, made of people with names and faces, with a lot to lose by hacking its users, they're unlikely to abuse private disclosure. If it's some tiny library, the maintainers might be in on it.
Also, if there's evidence of exploitation in the wild, the embargo is a gift to the attacker. The existence of a vulnerability in that case should be announced, even if the specifics have to be kept under embargo.
In this case the maintainer is the one who deliberately introduced the backdoor. As Andres Freund puts it deadpan, "Given the apparent upstream involvement I have not reported an upstream bug."
imho it depends on the vuln. I've given a vendor over a year, because it was a very low risk vuln. This isn't a vuln though - this is an attack.
> imho it depends on the vuln. I've given a vendor over a year, because it was a very low risk vuln.
But why? A year is a ridiculous time for fixing a vulnerability even a minor one. If a vendor is taking that long its because they don't prioritize security at all and are just dragging their feet.
But why? A year is a ridiculous time for fixing a vulnerability even a minor one. If a vendor is taking that long its because they don't prioritize security at all and are just dragging their feet.
I've always laughed my ass off at the idea of a disclosure window. It takes less than a day to find RCE that grants root privileges on devices that I've bothered to look at. Why on earth would I bother spending months of my time trying to convince someone to fix something?
The fraudulent author must have enjoyed the 'in joke' -- He's the one create vulnerabilities..
Honestly it seems like a state-based actor hoping to get whatever high value target compromised before it's made public. Reporting privately buys them more time, and allows them to let handlers know when the jig is up.
A couple of years ago I wrote a Go library that wraps the xz C code and allows you to do xz compression in Go: https://github.com/jamespfennell/xz
About a week ago I received the first PR on that repo, to upgrade to 5.6.1. I thought it was odd to get such a random PR...it's not the same GitHub account as upstream though.
About a week ago I received the first PR on that repo, to upgrade to 5.6.1. I thought it was odd to get such a random PR...it's not the same GitHub account as upstream though.
> 它与上游的 GitHub 帐户不同
这是很有价值的信息，也表明这可能只是冰山一角。
这是很有价值的信息，也表明这可能只是冰山一角。
我不想对此进行过多解读，但根据其 Linkedin 的说法，提交 PR 的人（据称）似乎自去年 12 月起就在 1Password 工作。 （他的 Linkedin 页面有一个指向制作 PR 的 Github 个人资料的链接）。
是的，GitHub 帐户看起来真的非常合法。也许它已经被泄露了？
What looks legit about a gmail address and some stock art for a profile?
[Deleted per below]
He was just (50 minutes ago) removed from the oss fuzz repo.
I hope this also (at least temporarily until verification of 'bad/good') remove him from the org?
I hope this also (at least temporarily until verification of 'bad/good') remove him from the org?
Plus the README.md that is just a rickroll
The 2 GMail accounts are 85% / mainly associated with XZ work, since 2021, per searching for them explicitly via Google.
The PR's two commits are signed by a key that was also used to sign previous commits belonging to that author.
等等，你是说 https://github.com/jaredallard 和这个 XZ 后门附属的账户共享 PGP 密钥吗？ 或者其他什么？
不，该帐户创建了 PR 并且他们的提交已签署 [1]。看看他们的其他存储库，例如他们在 Rust 中完成了 AoC 2023 并发布了它，该存储库中的提交由相同的密钥签名。所以这不仅仅是 GitHub 帐户的泄露。
我发现这方面是一个异常值，其他攻击者帐户都被删除了。所以这对我来说不太有意义。
[1] https://github.com/jamespfennell/xz/pull/2/commits
我发现这方面是一个异常值，其他攻击者帐户都被删除了。所以这对我来说不太有意义。
[1] https://github.com/jamespfennell/xz/pull/2/commits
If I were trying to compromise supply chains, getting into someplace like 1Password would be high up on the list.
Poor guy, he's probably going to get the third degree now.
Poor guy, he's probably going to get the third degree now.
They're definitely a real person. I know cause that "1Password employee since December" is a person I know IRL and worked with for years at their prior employer. They're not a no-name person or a fake identity just FYI. Please don't be witch hunting; this genuinely looks like an unfortunate case where Jared was merely proactively doing their job by trying to get an externally maintained golang bindings of XZ to the latest version of XZ. Jared's pretty fantastic to work with and is definitely the type of person to be filing PRs on external tools to get them to update dependencies. I think the timing is comically bad, but I can vouch for Jared.
https://github.com/jamespfennell/xz/pull/2
https://github.com/jamespfennell/xz/pull/2
greatjack613(1)
[deleted]
As a bit of an aside, I would never accept a PR like this, and would always update $large_vendored_dependency myself. This is unreviewable, and trivial to insert any backdoor (unless you go through the motions of updating it yourself and diffing, at which point the PR becomes superfluous). I'd be wary even from a well-known author unless I knew them personally on some level (real-life or via internet). Not that I wouldn't trust them, but people's machines or accounts can get compromised, people can have psychotic episodes, things like that. At the very least I'd like to have some out-of-band "is this really you?" signal.
This is how I once inserted a joke in one of our (private) repos that would randomly send cryptic messages to our chat channel. This was pretty harmless and just a joke (there's some context that made it funny), but it took them years to find it – and that was only because I told them after I quit.
That said, looking at the GitHub account I'd be surprised if there's anything nefarious going on here. Probably just someone using your repo, seeing it's outdated, and updating it.
This is how I once inserted a joke in one of our (private) repos that would randomly send cryptic messages to our chat channel. This was pretty harmless and just a joke (there's some context that made it funny), but it took them years to find it – and that was only because I told them after I quit.
That said, looking at the GitHub account I'd be surprised if there's anything nefarious going on here. Probably just someone using your repo, seeing it's outdated, and updating it.
[deleted]
In this case, the project is using Git submodules for its vendored dependencies, so you can trivially cryptographically verify that they have vendored the correct dependency just by checking the commit hash. It looks really crazy on Github but in most git clients it will just display the commit hash change.
The backdoor (test binary blob and autoconf) is not part of the pull request.
[deleted]
There was also a bug report in Debian which requested updating xz-utils to 5.6.1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708
That's the same Hans Jansen mentioned here: https://boehs.org/node/everything-i-know-about-the-xz-backdo...
IMO your prior on this should be that it's most likely just someone innocently updating a dependency.
大家好，我是该公关的作者。刚刚发布到 Github 并附有其他上下文：https://github.com/jamespfennell/xz/pull/2#issuecomment-2027...
That sucks to have people write mails to your employer...
老实说，如果不是因为我的 Github 通知简直一团糟，我可能不会注意到 PR 上的评论。值得庆幸的是，我的雇主在整个过程中都给予了大力支持：D
I appreciated your detailed update!
更新内容带来的多巴胺刺激应该会结束，它应该被视为添加潜在的新错误或漏洞，除非更新修复了 CVE。此外，Github 需要删除 PR 中的绿色和复选标记，以防止这些多巴胺陷阱覆盖任何批判性思维
Counterpoint: if you wait to keep things up to date until there's a CVE, there's a higher likelihood that things will break doing such a massive upgrade, and this may slow down a very time-sensitive CVE response. Allowing people to feel rewarded for keeping things up to date is not inherently a bad thing. As with all things, the balance point will vary from project to project!
Exactly. You don’t want to be bleeding edge (churn, bugs) but in general you usually don’t want to be on the oldest supported version either (let alone unsupported).
Risk/reward depends on the usecase of course. For a startup I’d be on the .1 version of the newest major version (never .0) if there are new features I want. For enterprise, probably the oldest LTS I can get away with.
Risk/reward depends on the usecase of course. For a startup I’d be on the .1 version of the newest major version (never .0) if there are new features I want. For enterprise, probably the oldest LTS I can get away with.
I strongly disagree. If you don’t update your dependencies then it’s easy to lose the institutional knowledge of how to update them, and who actually owns that obscure area of your code base that depends on them. Then you get a real CVE and have to work out everything in a hurry.
If you have a large code base and organisation then keep doing those upgrades so it won’t be a problem when it really matters. If it’s painful, or touches too many areas of the code you’ll be forced to refactor things so that ceases to be a problem, and you might even manage to contain things so well that you can swap implementations relatively easily when needed.
If you have a large code base and organisation then keep doing those upgrades so it won’t be a problem when it really matters. If it’s painful, or touches too many areas of the code you’ll be forced to refactor things so that ceases to be a problem, and you might even manage to contain things so well that you can swap implementations relatively easily when needed.
[deleted]
Internet detectives at work in this thread!
Is the solution against such attacks in the future only to scrutinize more, or are there other reasonable options in terms of hardening?
The lesson here seems to not depend on tools written in languages that have complex, obscure build systems and no one is either able or interested to read. Using tools rewritten in Rust, Go or any other languege which resolves dependencies within project seems the only way to do hardening here.
Once somebody actually does this people are gonna complain the same as always: "The sole purpose of your project is to rewrite perfectly fine stuff in Rust for the sake of it" or something along these lines.
I agree there's safer languages than C, but nobody reads the 50,000 lines changed when you update the vendoring in a random golang project. It would be easy to introduce something there that nobody notices too.
It is generally harder to introduce vulnerabilities in readable language even more when it is memory safe. Sure life is not perfect and bad actors would have found a ways to inject vulnerabilities also in Rust, Go codebase. The benefit of modern languages is that there is one way to build things and the source code is the only thing that needs to be auditted.
this backdoor had nothing at all to do with memory safety.
Wouldn't a supply chain attack like this be much worse with Rust and Cargo because of the fact it's not just a single dynamic library that needs to be reinstalled system-wise, but, instead, every binary would require a new release?
It would mean rebuilding more packages. I don't think that's meaningfully "much worse", package mangers are perfectly capable of rebuilding the world and the end-user fix is the same "pacman -Syu"/"apt-get update && apt-get upgrade"/...
On the flip side the elegant/readable build system means that the place this exploit was hidden wouldn't exist. Though I wouldn't confidently say that 'no hiding places exist' (especially with the parts of the ecosystem that wrap dependencies in other languages).
On the flip side the elegant/readable build system means that the place this exploit was hidden wouldn't exist. Though I wouldn't confidently say that 'no hiding places exist' (especially with the parts of the ecosystem that wrap dependencies in other languages).
It's much worse because it requires repackaging every affected system package instead of a single library. Knowing which packages are affected is difficult because that information isn't exposed to the larger system package manager. After all, it's all managed by the build system.
In the era of modern CI and build infrastructure, I don't really think that's materially an issue.
Those CI and build infrastructures rely on the Debian and RedHat being able to build system packages.
How would an automated CI or build infrastructure stop this attack? It was stopped because the competent package maintainer noticed a performance regression.
In this case, this imagined build system would have to track every rust library used in every package to know which packages to perform an emergency release for.
How would an automated CI or build infrastructure stop this attack? It was stopped because the competent package maintainer noticed a performance regression.
In this case, this imagined build system would have to track every rust library used in every package to know which packages to perform an emergency release for.
I... don't see your point. Tracking the dependencies a static binary is built with is already a feature for build systems, just maybe not the ones Debian and RH are using now, but I imagine they would if they were shipping static binaries.
Rust isn't really the point here, it's the age old static vs dynamic linking argument. Rust (or rather, Cargo) already tracks which version of a dependency a library depends on (or a pattern to resolve one), but it's besides the point.
Rust isn't really the point here, it's the age old static vs dynamic linking argument. Rust (or rather, Cargo) already tracks which version of a dependency a library depends on (or a pattern to resolve one), but it's besides the point.
Rust is the issue here because it doesn't give you much of an option. And that option is the wrong one if you need to do an emergency upgrade of a particular library system-wide.
It's really not, it's not hard to do a reverse search of [broken lib] <= depends on <= [rust application] and then rebuild everything that matches. You might have to rebuild more, but that's not really hard with modern build infrastructure.
Not to mention if you have a Rust application that depends on C libraries, it already dynamically links on most platforms. You only need to rebuild if a Rust crate needs to be updated.
Not to mention if you have a Rust application that depends on C libraries, it already dynamically links on most platforms. You only need to rebuild if a Rust crate needs to be updated.
> imagined
Cargo already has this information for every project it builds. That other systems do not is their issue, but it’s not a theoretical design.
Cargo already has this information for every project it builds. That other systems do not is their issue, but it’s not a theoretical design.
So, I know that librustxz has been compromised. I'm Debian. I must dive into each rust binary I distribute as part of my system and inspect their Cargo.toml files. Then what? Do I fork each one, bump the version, hope it doesn't break everything, and then push an emergency release!??!
> I must dive into each rust binary I distribute as part of my system and inspect their Cargo.toml
A few things:
1. It'd be Cargo.lock
2. Debian, in particular, processes Cargo's output here and makes individual debs. So they've taken advantage of this to already know via their regular package manager tooling.
3. You wouldn't dive into and look through these by hand, you'd have it as a first-class concept. "Which packages use this package" should be table stakes for a package manager.
> Then what? Do I fork each one, bump the version, hope it doesn't break everything, and then push an emergency release!??!
The exact same thing you do in this current situation? It depends on what the issue is. Cargo isn't magic.
The point is just that "which libraries does the binary depend on" isn't a problem with actual tooling.
People already run tools like cargo-vet in CI to catch versions of packages that may have issues they care about.
A few things:
1. It'd be Cargo.lock
2. Debian, in particular, processes Cargo's output here and makes individual debs. So they've taken advantage of this to already know via their regular package manager tooling.
3. You wouldn't dive into and look through these by hand, you'd have it as a first-class concept. "Which packages use this package" should be table stakes for a package manager.
> Then what? Do I fork each one, bump the version, hope it doesn't break everything, and then push an emergency release!??!
The exact same thing you do in this current situation? It depends on what the issue is. Cargo isn't magic.
The point is just that "which libraries does the binary depend on" isn't a problem with actual tooling.
People already run tools like cargo-vet in CI to catch versions of packages that may have issues they care about.
> The exact same thing you do in this current situation? It depends on what the issue is. Cargo isn't magic.
False. In the current situation, you just release a new shared library that is used system-wide.
False. In the current situation, you just release a new shared library that is used system-wide.
Okay, so the analogous situation here is that you release a new version of the library, and rebuild. Done.
This seems to be an orthogonal issue. Rust could build the same dynamic library with cargo which could then be distributed. The diference is that there would be a single way to build things.
Most Rust libraries are not dynamically linked; instead, versions are pinned and included statically during the build process. This is touted as a feature.
Only a few projects are built as system-wide libraries that expose a C-compatible abi interface; rsvg comes to mind.
Only a few projects are built as system-wide libraries that expose a C-compatible abi interface; rsvg comes to mind.
据我所知，任何 Rust 开发人员都没有将其吹捧为一项功能。 Rust ABI 只是仍在稳定。 请参阅：https://github.com/rust-lang/rust/pull/105586
我并不完全确定这个漏洞，但似乎需要修改一个二进制文件才能使该漏洞发挥作用[1]，该漏洞后来被构建系统拾取。
https://github.com/tukaani-project/xz/commit/6e636819e8f0703...
https://github.com/tukaani-project/xz/commit/6e636819e8f0703...
The binary was an xz test file that contained a script that patched the c-code.
People are going to be upset with this perspective but I completely agree. The whole autoconf set of tools is a complete disaster.
You don't need a complex obscure build system for most C code. There's a lot of historical baggage here, but many projects (including xz, I suspect) can get away with a fairly straight-forward Makefile. Double so when using some GNU make extensions.
Thanks for that post, I wish people stopped pushing ever so more complicated build systems, opaque, non-backward compatible between their own versions when a 2 pages Makefile would work just fine, and still work in 20 years time.
Rust is the worst in terms of build system transparency. Ever heard of build.rs? You can hide backdoors in any crate, or in any crate's build.rs, or the same recursively.
Most build systems are turing-complete. Rust, at least, drastically reduces the need for custom build scripts (most of my projects have empty build.rs files or lack one entirely), and build.rs being in the same language as the rest of the codebase aids transparency immensely.
That doesn't make build.rs any less of a juicy target for a supply chain attack.
Arbitrary code downloaded from the internet and run at build time? That's a nightmare scenario for auditing, much worse than anything Autotools or CMake can offer.
Arbitrary code downloaded from the internet and run at build time? That's a nightmare scenario for auditing, much worse than anything Autotools or CMake can offer.
You're not wrong about arbitrary code execution. It's just that your statement applies to most of the packages on any linux distribution, Autotools and Cmake included, regardless of language. Many moreso than Rust due to the aforementioned features of Cargo and build.rs not requiring me to be an expert in a second language just to audit it.
Packages in a Linux distro are not built on my machine, they are built by the distro in a sandbox. Every time I type "cargo build" I am potentially running arbitrary code downloaded from the internet. Every time I type "make" in an Autotools program only my code runs.
> not requiring me to be an expert in another language just to audit it.
Do you do that every time your Cargo.lock changes?
> not requiring me to be an expert in another language just to audit it.
Do you do that every time your Cargo.lock changes?
> Every time I type "make" in an Autotools program only my code runs.
Says who? Make is just as good at calling arbitrary code as Cargo. Including code that reaches out over the network. Have you audited every single makefile to ensure that isn't the case?
Says who? Make is just as good at calling arbitrary code as Cargo. Including code that reaches out over the network. Have you audited every single makefile to ensure that isn't the case?
I am talking about my makefiles. They don't automatically build dependencies that I have no control on.
Whereas building my crate can run code locally that no one has ever audited.
Whereas building my crate can run code locally that no one has ever audited.
So... you're complaining about what could happen in a Rust build if you include a library without examining that library first? How do you think that is different from doing the same in any other language?
The difference is that in another language the build step is delegated to someone else who has packaged the code, and every version has presumably gone through some kind of audit. With Rust I have no idea what new transitive dependencies could be included any time I update one of my dependencies, and what code could be triggered just by building my program without even running it.
Again, we're not talking about the dependencies that I choose, but the whole transitive closure of dependencies, including the most low-level. Did you examine serde the first time you used a dependency that used it? serde did have in the past a slightly sketchy case of using a pre-built binary. Or the whole dependency tree of Bevy?
I mean, Rust has many advantages but the cargo supply chain story is an absolute disaster---not that it's alone, pypi or nodejs or Ruby gems are the same.
Again, we're not talking about the dependencies that I choose, but the whole transitive closure of dependencies, including the most low-level. Did you examine serde the first time you used a dependency that used it? serde did have in the past a slightly sketchy case of using a pre-built binary. Or the whole dependency tree of Bevy?
I mean, Rust has many advantages but the cargo supply chain story is an absolute disaster---not that it's alone, pypi or nodejs or Ruby gems are the same.
> The difference is that in another language the build step is delegated to someone else who has packaged the code
Fedora packages a large number of Rust libraries, just as you describe. Nothing prevents you from using the packaged libraries if you prefer them.
You may find helpful information here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Ru...
Fedora packages a large number of Rust libraries, just as you describe. Nothing prevents you from using the packaged libraries if you prefer them.
You may find helpful information here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Ru...
seems trivial for a configure script to call curl/wget somewhere in the depths of it, no?
Exactly. And at least Cargo will refuse to download a crate which has been yanked. So any crate which has been discovered to be compromised can be yanked, preventing further damage even when someone has already downloaded something which depends on it.
Building packages with up-to-date dependencies is also vastly preferable to building against ancient copies of libraries vendored into a codebase at some point in the past, a situation I see far too often in C/C++ codebases.
Building packages with up-to-date dependencies is also vastly preferable to building against ancient copies of libraries vendored into a codebase at some point in the past, a situation I see far too often in C/C++ codebases.
Debian’s rules files often deliberately sinkhole the entire network during the build. It’s not the worst idea.
I wonder if you could do it inside the config script without the network.
Is this really the lesson here? We are talking about a maintainer here, who had access to signing keys and a full access to the repository. Deb packages which were distributed are also different than the source code. Do you honestly believe that the (arguably awful) autotools syntax is the single root cause of this mess, Rust will save us from everything, and this is what we should take away from this situation?
I call bullshit.
The fundamental problem here was a violation of chain of trust. Open source is only about the source being open. But if users are just downloading blobs with prebuilt binaries or even _pre-generated scripts_ that aren't in the original source, there is nothing a less-obscure build system will save you from as you are putting your entire security on the chain of trust being maintained.
The fundamental problem here was a violation of chain of trust. Open source is only about the source being open. But if users are just downloading blobs with prebuilt binaries or even _pre-generated scripts_ that aren't in the original source, there is nothing a less-obscure build system will save you from as you are putting your entire security on the chain of trust being maintained.
Am I crazy thinking libraries shouldn't be able to provide _other libraries'_ symbols without the other libraries' "permission"? What am I missing?
Imagine a more competent backdoor attempt on xz(1)—one that wouldn't have been noticed this quickly. xz is everywhere. They could pull off a "reflections on trusting trust": an xz which selectively modifies a tiny subset of the files it sees, like .tar.xz software tarballs underlying certain build processes. Not source code tarballs (someone might notice)—tarballs distributing pre-compiled binaries.
edit to add: Arch Linux' entire package system used to run on .tar.xz binaries (they switched to Zstd a few years ago [0]).
[0] https://news.ycombinator.com/item?id=19478171 ("Arch Linux propose changing compression method from xz to zstd (archlinux.org)")
edit to add: Arch Linux' entire package system used to run on .tar.xz binaries (they switched to Zstd a few years ago [0]).
[0] https://news.ycombinator.com/item?id=19478171 ("Arch Linux propose changing compression method from xz to zstd (archlinux.org)")
deb packages are xz compressed...
my freaking kernels/initrd are xz or zstd compressed!
... and Debian is very serious about it: https://fulda.social/@Ganneff/112184975950858403
A backdoored xz could also run payloads hidden inside other xz files, allowing targeted attacks.
The same authors have also contributed to Zstd
[deleted]
https://github.com/tukaani-project/tukaani-project.github.io...
> Note: GitHub automatically includes two archives Source code (zip) and Source code (tar.gz) in the releases. These archives cannot be disabled and should be ignored.
The author was thinking ahead! Latest commit hash for this repo: 8a3b5f28d00ebc2c1619c87a8c8975718f12e271
> Note: GitHub automatically includes two archives Source code (zip) and Source code (tar.gz) in the releases. These archives cannot be disabled and should be ignored.
The author was thinking ahead! Latest commit hash for this repo: 8a3b5f28d00ebc2c1619c87a8c8975718f12e271
长期以来，git 生成的 tarball 有一个令人烦恼的缺点——它们丢失了标签信息。但是，自 git 2.32（2021 年 6 月发布；大概在 2021 年 8 月他们在博客上发布时在 GitHub 上提供）开始，您可以使用 `$Format:%(describe)$` ...出于性能原因，每个存储库仅限一次。
Except this change was made in 2023, it is just scary how good this threat actor was.
顺便说一句，这不是唯一提供与 git 存储库不同的源 tarball 的项目，例如 libusb 也这样做（可能还有其他）：
- https://github.com/libusb/libusb/issues/1468#issuecomment-19...
- https://github.com/orgs/community/discussions/6003
- https://github.com/libusb/libusb/issues/1468#issuecomment-19...
- https://github.com/orgs/community/discussions/6003
It's very common in autoconf codebases because the idea is that you untar and then run `./configure ...` rather than `autoreconf -fi && ./configure ...`. But to do that either you have to commit `./configure` or you have to make a separate tarball (typically with `make dist`). I know because two projects I co-maintain do this.
Whats the problem of running “autoreconf -fi” though?
Very strange argument. It’s like saying our source release only contains a prebuilt binary, otherwise the user has to run “make”.
If that’s such a big hassle for your downstream consumers, maybe one should use something better than autoconf in the first place.
Very strange argument. It’s like saying our source release only contains a prebuilt binary, otherwise the user has to run “make”.
If that’s such a big hassle for your downstream consumers, maybe one should use something better than autoconf in the first place.
For running autoreconf you need to have autotools installed and even then it can fail.
I have autotools installed and despite that autoreconf fails for me on the xz git repository.
The idea of having configure as a convoluted shell script is that it runs everywhere without any additional. If it isn't committed to the repository you're burdening your consumers with having compilation dependencies installed that are not needed for running your software.
I have autotools installed and despite that autoreconf fails for me on the xz git repository.
The idea of having configure as a convoluted shell script is that it runs everywhere without any additional. If it isn't committed to the repository you're burdening your consumers with having compilation dependencies installed that are not needed for running your software.
Yes...For running gcc you need to have gcc installed.
You don’t need gcc to run the software. It’s not burdening anyone that gcc was needed to build the software.
It’s very standard practice to have development dependencies. Why should autoconf be treated exceptionally?
If they fail despite being available it’s either a sign of using a fragile tool or a badly maintained project. Both can be fixed without shipping a half-pre-compiled-half-source repo.
You don’t need gcc to run the software. It’s not burdening anyone that gcc was needed to build the software.
It’s very standard practice to have development dependencies. Why should autoconf be treated exceptionally?
If they fail despite being available it’s either a sign of using a fragile tool or a badly maintained project. Both can be fixed without shipping a half-pre-compiled-half-source repo.
The configure script is not a compilation artifact.
The more steps you add to get final product the more errors are possible. It's much easier for you as the project developer to generate the script so you should do it.
If it's easier for you to generate the binary, you should do it as well (reproducible binaries of course). That's why Windows binaries are often shipped. With Linux binaries this is much harder (even though there are solutions now). With OSX it depends if you have the newest CPU architecture or not.
The more steps you add to get final product the more errors are possible. It's much easier for you as the project developer to generate the script so you should do it.
If it's easier for you to generate the binary, you should do it as well (reproducible binaries of course). That's why Windows binaries are often shipped. With Linux binaries this is much harder (even though there are solutions now). With OSX it depends if you have the newest CPU architecture or not.
> If it's easier for you to generate the binary, you should do it as well (reproducible binaries of course).
I think that's the crux of what you're saying. But consider that if Fedora, Debian, etc. accepted released, built artifacts from upstreams then it would be even easier to introduce backdoors!
Fedora, Debian, Nix -all the distros- need to build from sources, preferably from sources taken from upstreams' version control repositories. Not that that would prevent backdoors -it wouldn't!- but that it would at least make it easier to investigate later as the sources would all be visible to the distros (assuming non-backdoored build tools).
I think that's the crux of what you're saying. But consider that if Fedora, Debian, etc. accepted released, built artifacts from upstreams then it would be even easier to introduce backdoors!
Fedora, Debian, Nix -all the distros- need to build from sources, preferably from sources taken from upstreams' version control repositories. Not that that would prevent backdoors -it wouldn't!- but that it would at least make it easier to investigate later as the sources would all be visible to the distros (assuming non-backdoored build tools).
Autotools are not backwards-compatible. Often only a specific version of autotools works. Only the generated configure is supposed to be portable.
It's also not the distribution model for an Autotools project. Project distributions would include a handwritten configure file that users would run: The usual `./configure && make && make install`. Since those configure scripts became more and more complex for supporting diverse combinations of compiler and OS, the idea of autotools was for maintainers to generate it. It was not meant to be executed by the user: https://en.wikipedia.org/wiki/GNU_Autotools#Usage
It's also not the distribution model for an Autotools project. Project distributions would include a handwritten configure file that users would run: The usual `./configure && make && make install`. Since those configure scripts became more and more complex for supporting diverse combinations of compiler and OS, the idea of autotools was for maintainers to generate it. It was not meant to be executed by the user: https://en.wikipedia.org/wiki/GNU_Autotools#Usage
这很常见，但却是完全错误的。 “发布”应该允许在不安装仅用于编译的依赖项的情况下构建项目。
不保证 Autotools 能够安装在任何系统上。例如，它们不在 GitHub Action 的 OSX 运行器上。
这也是用户体验的问题。 autoreconf 失败很常见。如果您不能让用户轻松实际使用您的项目，您就会失去一些。
不保证 Autotools 能够安装在任何系统上。例如，它们不在 GitHub Action 的 OSX 运行器上。
这也是用户体验的问题。 autoreconf 失败很常见。如果您不能让用户轻松实际使用您的项目，您就会失去一些。
> A "release" should allow to build the project without installing dependencies that are only there for compilation.
Like a compiler or some -devel packages?
Like a compiler or some -devel packages?
If the compiler is some customized or hard to build version then yes, they should be included.
The more steps you add to get to the final product the more likely it is to run into problems.
The more steps you add to get to the final product the more likely it is to run into problems.
> [...] A "release" should allow to build the project without installing dependencies that are only there for compilation.
Built artifacts shouldn't require build-time dependencies to be installed, yes, but we're talking about source distributions. Including `./configure` is just a way of reducing the configuration-/build-time dependencies for the user.
> Autotools are not guaranteed to be installed on any system. [...]
Which is why this is common practice.
> It's common but it's plain wrong.
Strong word. I'm not sure it's "plain wrong". We could just require that users have autoconf installed in order to build from sources, or we could commit `./configure` whenever we make a release, or we could continue this approach. (For some royal we.)
But stopping this practice won't prevent backdoors. I think a lot of people in this thread are focusing on this as if it was the source of all evils, but it's really not.
Built artifacts shouldn't require build-time dependencies to be installed, yes, but we're talking about source distributions. Including `./configure` is just a way of reducing the configuration-/build-time dependencies for the user.
> Autotools are not guaranteed to be installed on any system. [...]
Which is why this is common practice.
> It's common but it's plain wrong.
Strong word. I'm not sure it's "plain wrong". We could just require that users have autoconf installed in order to build from sources, or we could commit `./configure` whenever we make a release, or we could continue this approach. (For some royal we.)
But stopping this practice won't prevent backdoors. I think a lot of people in this thread are focusing on this as if it was the source of all evils, but it's really not.
I think the lesson here for packagers is that binary testdata should not be present while doing the build.
It is too easy to hide things in testdata.
It is too easy to hide things in testdata.
Nice idea, but then you just hide the attack in logo.png that gets embedded in the binary. Less useful for libraries, works plenty good for web/desktop/mobile.
This entire thread is above my pay grade, but isn’t minimizing the attack surface always a good thing?
It's all irrelevant. The attacker social engineered their way to being the lead maintainer for the project.
The problem with the parent's suggestion is you end up banning lots of useful techniques while not actually stopping hackers from installing back doors or adding security exploits. The basic problem is once an attacker can submit changes to a project, the attacker can do a lot of damage. The only real solution is to do very careful code reviews. Basically, having a malicious person get code into a project is always going to be a disaster. If they can get control of a project, it is going to be even worse.
> The only real solution is to do very careful code reviews.
Are there any projects that are well resourced enough to do this consistently, including all dependencies?
Are there any projects that are well resourced enough to do this consistently, including all dependencies?
A lot of eyes will be dissecting this specific exploit, and investigating this specific account, but how can we find the same kind of attack in a general way if it’s being used in other projects and using other contributor names?
Note that the malicious binary is fairly long and complex.
This attack can be stopped by disallowing any binary testdata or other non-source code to be on the build machines during a build.
You could imagine a simple process which checks out the code, then runs some kind of entropy checker over the code to check it is all unminified and uncompressed source code, before finally kicking off the build process.
autogenerated files would also not be allowed to be in the source repo - they're too long and could easily hide bad stuff. Instead the build process should generate the file during the build.
This attack can be stopped by disallowing any binary testdata or other non-source code to be on the build machines during a build.
You could imagine a simple process which checks out the code, then runs some kind of entropy checker over the code to check it is all unminified and uncompressed source code, before finally kicking off the build process.
autogenerated files would also not be allowed to be in the source repo - they're too long and could easily hide bad stuff. Instead the build process should generate the file during the build.
This requires a more comprehensive redesign of the build process. Most Linux distributions also run the tests of the project they're building as part of the build process.
The code that runs during testing should not be allowed to affect the package though. If this is possible, this is misdesigned.
Profile guided optimization is, unfortunately, wildly powerful. And it has a hard requirement that a casual link exists from test data (or production data!) to the build process.
1. Everything must be visible. A diff between the release tarball and tag should be unacceptable. It was hidden from the eyes to begin with.
2. Build systems should be simple and obvious. Potentially not even code. The inclusion was well hidden.
3. This was caught through runtime inspection. It should be possible to halt any Linux system at runtime, load debug symbols and map _everything_ back to the source code. If something can't map back then regard it as a potentially malicious blackbox.
There has been a strong focus and joint effort to make distributions reproducible. What we haven't managed though is prove that the project compromises only of freshly compiled content. Sorta like a build time / runtime "libre" proof.
This should exist for good debugging anyway.
It wouldn't hinder source code based backdoors or malicious vulnerable code. But it would detect a backdoor like this one.
Just an initial thought though, and probably hard to do, but not impossibly hard, especially for a default server environment.
2. Build systems should be simple and obvious. Potentially not even code. The inclusion was well hidden.
3. This was caught through runtime inspection. It should be possible to halt any Linux system at runtime, load debug symbols and map _everything_ back to the source code. If something can't map back then regard it as a potentially malicious blackbox.
There has been a strong focus and joint effort to make distributions reproducible. What we haven't managed though is prove that the project compromises only of freshly compiled content. Sorta like a build time / runtime "libre" proof.
This should exist for good debugging anyway.
It wouldn't hinder source code based backdoors or malicious vulnerable code. But it would detect a backdoor like this one.
Just an initial thought though, and probably hard to do, but not impossibly hard, especially for a default server environment.
More reproducible builds, maybe even across distributions? Builds based on specific commits (no tarballs like in this case), possibly signed (just for attribution, not for security per se)? Allow fewer unsafe/runtime modifications The way oss-fuzz ASAN was disabled should've been a warning on its own, if these issues weren't so common.
I'm not aware of any efforts towards it, but libraries should also probably be more confined to only provide intended functionality without being able to hook elsewhere?
I'm not aware of any efforts towards it, but libraries should also probably be more confined to only provide intended functionality without being able to hook elsewhere?
The Guix full source bootstrap is looking less paranoid as time goes on
I haven't looked at Guix but in the discussions around this exploit for NixOS they mentioned that regenerating autoshit for xz-utils would not be something they can/want to do because that would add a lot more dependencies to the bootstrap before other packages can be build. Kind of funny how a requirement for bootstrapped builds can add a requirement for trusting not-quite-binaries-but-also-not-really-source blobs.
Build-related fixes are only treating the symptoms, not the disease. The real fix would be better sandboxing and capability-based security[1] built into major OSes which make backdoors a lot less useful. Why does a compression library have the ability to "install an audit hook into the dynamic linker" or anything else that isn't compressing data? No amount of SBOMs, reproducible builds, code signing, or banning binaries will change the fact that one mistake anywhere in the stack has a huge blast radius.
[1]: https://en.wikipedia.org/wiki/Capability-based_security
[1]: https://en.wikipedia.org/wiki/Capability-based_security
That's why I always raise concerns about JEP 411 - removal of SecurityManager from Java without any replacement.
Just ban autotools
We should be able to produce a tar and a proof that tar was produced from a specific source code.
Quote from the article:
The verifiers can then easily check that the signature and indeed be convinced that the code was executed as it is claimed and source code wasn't tampered with.
The advantage of Zero-Knowledge technology in this case is that one doesn't need to repeat the computational steps themselves nor rely on a trusted party to do it for them (like automated build - that can also be compromised by the state actors). Just having the proof solves this trust problem mathematically: if you have the proof & the tar, you can quickly check source code that produced the tar wasn't modified.
Quote from the article:
That line is not in the upstream source of build-to-host, nor is build-to-host used by xz in git.
The verifiers can then easily check that the signature and indeed be convinced that the code was executed as it is claimed and source code wasn't tampered with.
The advantage of Zero-Knowledge technology in this case is that one doesn't need to repeat the computational steps themselves nor rely on a trusted party to do it for them (like automated build - that can also be compromised by the state actors). Just having the proof solves this trust problem mathematically: if you have the proof & the tar, you can quickly check source code that produced the tar wasn't modified.
I don’t think zero knowledge systems are practical at the moment. It will take over around 8 orders of magnitude more compute and memory to produce a ZKP proof of generic computation like compilation. Even 2 orders of magnitude is barely acceptable.
I've been told verifiable builds are possible already, I don't know how practical though:
twitter.com/stskeeps/status/1774019709739872599
twitter.com/stskeeps/status/1774019709739872599
It looks like the person who added the backdoor is in fact the current co-maintainer of the project (and the more active of the two): https://tukaani.org/about.html
让我想知道他是否是 github 组织的所有者，现在它发生了什么？
In various places they say Lasse Collin is not online right now, but he did make commits a week ago https://git.tukaani.org/?p=xz.git;a=summary
It's wild that this could have laid dormant for far longer if the exploit was better written-- if it didn't spike slow down logins or disturb valgrind.
[deleted]
Now consider that your average Linux distribution pulls in tens of thousands of packages, each of which can be similarly compromised. Pretty scary to think about.
The terrible desktop software security model of weak/essentially non-existent security boundaries at run and compile time makes this all the more spicy.
Computer security for billions runs on the simultaneous goodwill of many thousand contributors. Optimistically said it's actually a giant compliment to the programming community.
And this is not even talking about hardware backdoors that are a million times worse and basically undetectable when done well. The myriad ways to betray user trust at any level of computation make me dizzy...
Computer security for billions runs on the simultaneous goodwill of many thousand contributors. Optimistically said it's actually a giant compliment to the programming community.
And this is not even talking about hardware backdoors that are a million times worse and basically undetectable when done well. The myriad ways to betray user trust at any level of computation make me dizzy...
I have exactly 719 packages on my Gentoo box, just rebuilt everything as part of the profile 23 upgrade.
@为更新和安全问题编写 github 扫描程序的人（dependabot 等）
我们可以开始加入电子邮件黑名单和贡献者姓名（带有原因/讨论链接）吗？
我无法跟踪它们，也不希望它们出现在我的项目中。
可能不是很有帮助，因为创建新身份很容易，但我认为没有理由让他们更容易。
另外，我可能会以不同的方式对待对已知项目做出大量贡献的人而不是新帐户，所以它仍然有帮助。
我们可以开始加入电子邮件黑名单和贡献者姓名（带有原因/讨论链接）吗？
我无法跟踪它们，也不希望它们出现在我的项目中。
可能不是很有帮助，因为创建新身份很容易，但我认为没有理由让他们更容易。
另外，我可能会以不同的方式对待对已知项目做出大量贡献的人而不是新帐户，所以它仍然有帮助。
It takes a minute to create a new email address. And you can change or fake an email address on a git commit trivially. You, too, can writing code as anyone you want by just doing "git commit --author='Joe Biden <[email protected]>'". On the internet nobody knows you're Joe Biden.
您可以编写一个相当简单的 GitHub 操作来执行此操作：查看 PR，如果您出于某种原因不喜欢它，则拒绝/关闭它。 AFAIK 开源项目有免费的操作配额。
对于恶意代理来说，坚持使用同一封电子邮件进行多次利用可能并不明智。
对于恶意代理来说，坚持使用同一封电子邮件进行多次利用可能并不明智。
github already suspended the account
Unfortunately, this is how good bad actors work: with a very long-term point of view. There is no “harmless” project any more.
Probably a state actor. You can look far into the future when you’re working for the party.
And that long term perspective could be used constructively instead!
Which like, also wouldn't be totally weird if I found out that the xz or whatever library maintainer worked for the DoE as a researcher? I kind of expect governments to be funding this stuff.
From what I read on masto, the original maint had personal life breakdown, etc. Their interest in staying as primary maint is gone.
This is a very strong argument for FOSS to pick up the good habit of ditching/un-mainlining projects where they are sitting around for state actors to volunteer injecting commits to, and dep-stripping active projects from this cruft.
Who wants to maintain on a shitty compression format? Someone who is dephunting, it turns out.
Okay so your pirate-torrent person needs liblzma.so Offer it in the scary/oldware section of the package library that you need to hunt down the instructions to turn on. Let the users see that it's marked as obsolete, enterprises will see that it should go on the banlist.
This is a very strong argument for FOSS to pick up the good habit of ditching/un-mainlining projects where they are sitting around for state actors to volunteer injecting commits to, and dep-stripping active projects from this cruft.
Who wants to maintain on a shitty compression format? Someone who is dephunting, it turns out.
Okay so your pirate-torrent person needs liblzma.so Offer it in the scary/oldware section of the package library that you need to hunt down the instructions to turn on. Let the users see that it's marked as obsolete, enterprises will see that it should go on the banlist.
Um, what? This incident is turning into such a big deal because xz is deeply ingrained as a core dependency in the software ecosystem. It's not an obscure tool for "pirates."
Collin worked on XZ and its predecessor ~15 years. It seems that he did that for free, at least in recent times. Anyone will lose motivation to work for free over this period of time.
At the same time, XZ became a cornerstone of major Linxus distributions, being systemd dependency and loaded, in particular, as part of sshd. What could go wrong?
In hindsight, the commercial idea of Red Hat, utilizing the free work of thousands of developers working "just for fun", turned out to be not so brilliant.
At the same time, XZ became a cornerstone of major Linxus distributions, being systemd dependency and loaded, in particular, as part of sshd. What could go wrong?
In hindsight, the commercial idea of Red Hat, utilizing the free work of thousands of developers working "just for fun", turned out to be not so brilliant.
相反，这是一个很好的例子，说明了为什么“脆弱”的 OSS 项目已经成为关键组件，而原始开发人员已经放弃或失去了兴趣，应该将其移交给像 RedHat 这样可以指定付费开发人员的实体。重要的是要在一些隐秘的兰多走出阴影提供友好的帮助之前做到这一点，顺便说一下，他恰好是密码学和压缩专家。
该帖子中的许多评论似乎只见树木不见森林：这是一项为期多年的行动，针对的是一个频繁使用的项目的易受攻击的开发人员。
这不是某个独狼的杰作。执行此操作所需的专业知识以及研究和协调量需要数百个工时。罪魁祸首很可能有一名项目经理......
必须有人跟踪 OSS 开发人员以找出谁容易受到攻击（xz 维护者公开披露了职业倦怠/心理健康问题）；然后精心设计的陷阱就被设置了。
GitHub 上可见的几个用户名就像拔掉院子里长出的顽固杂草……直到你开始拔除它，你才意识到隐藏在表面之下的广泛现实。
这里隐含的目标是在生产 Debian 和 Red Hat EL 中添加后门。需要数年时间才能执行的事情。这不是一个人的工作。
该帖子中的许多评论似乎只见树木不见森林：这是一项为期多年的行动，针对的是一个频繁使用的项目的易受攻击的开发人员。
这不是某个独狼的杰作。执行此操作所需的专业知识以及研究和协调量需要数百个工时。罪魁祸首很可能有一名项目经理......
必须有人跟踪 OSS 开发人员以找出谁容易受到攻击（xz 维护者公开披露了职业倦怠/心理健康问题）；然后精心设计的陷阱就被设置了。
GitHub 上可见的几个用户名就像拔掉院子里长出的顽固杂草……直到你开始拔除它，你才意识到隐藏在表面之下的广泛现实。
这里隐含的目标是在生产 Debian 和 Red Hat EL 中添加后门。需要数年时间才能执行的事情。这不是一个人的工作。
I imagine it might be easier to just compromise a weakly protected account than to actual put in a 2 years long effort with real contributions. If we mandated MFA for all contributors who contribute to these really important projects then we can know with greater certainty if it was really a long con vs. a recently compromised account.
This seems like a great way to invest in supporting open source projects in meantime if these projects are being used by these actors. Just have to maintain an internal fork without the backdoors
Maybe someone can disrupt the open source funding problem by brokering exploit bounties /s
Maybe someone can disrupt the open source funding problem by brokering exploit bounties /s
github 已经为重要项目的成员强制要求 MFA
Doesn't it mandate it for everyone? I don't use it anymore and haven't logged in since forever, but I think I got a series of e-mails that it was being made mandatory.
It will soon. I think I have to sort it out before April 4. My passwords are already >20 random characters, so I wasn't going to do it until they told me to.
如果您使用 pass 来存储这些内容，请查看 pass-otp 和 browserpass，因为 GitHub 仍然允许 TOTP 用于 MFA。 pass-otp是基于oathtool的，所以如果你不使用pass，你也可以更手动地完成它。
My solution is far shittier than any of those.
它要求每个人都这样做。 我被 GitHub 拒之门外了，因为他妈的。
Why opposed to MFA? Source code is one of the most important assets in our realm.
Freedom is far more important.
But you can use any totp authenticator. The protocol is free and open.
It's more to make the point that "no means no." An act of protest.
(I have written a TOTP implementation myself. I do not have a GH account, and likely never will.)
(I have written a TOTP implementation myself. I do not have a GH account, and likely never will.)
It's ridiculous to say "no means no" about not wanting to use a password to get an account, right?
What makes TOTP different from a password in terms of use or refusal?
What makes TOTP different from a password in terms of use or refusal?
Browsers don't save the TOTP seed and auto fill it for you for one, making it much less user friendly than a password in practice.
The main problem I have with MFA is that it gets used too frequently for things that don't need that much protection, which from my perspective is basically anything other than making a transfer or trade in my bank/brokerage. Just user-hostile requiring of manual action, including finding my phone that I don't always keep on me.
It's also often used as a way to justify collecting a phone number, which I wouldn't even have if not for MFA.
The main problem I have with MFA is that it gets used too frequently for things that don't need that much protection, which from my perspective is basically anything other than making a transfer or trade in my bank/brokerage. Just user-hostile requiring of manual action, including finding my phone that I don't always keep on me.
It's also often used as a way to justify collecting a phone number, which I wouldn't even have if not for MFA.
They have the freedom to request whatever authentication method they want.
大多数人必须将他们的密码（通常是强大且唯一的，因为它是针对 github 的）同步到存储 MFA 令牌的同一设备，使其（几乎）完全毫无意义，但永久访问丢失的风险明显更高（取决于他们如何处理重置代码，如果被泄露，也会使 MFA 变得毫无意义。）（cookie 盗窃也使这一切变得毫无意义。）
更糟糕的是，人们认为自己受到了更多保护，但实际上并非如此。
更糟糕的是，人们认为自己受到了更多保护，但实际上并非如此。
Bringing everyone up to the level of "strong and unique password" sounds like a huge benefit. Even if your "generally" is true, which I doubt, that leaves a lot of gaps.
Doesn't help that a lot of companies still just allow anyone with access to the phone number to gain access to the account (via customer support or automated SMS-based account recovery).
It's inconvenient, SMS 2FA is arguably security theater, and redundant with a real password manager. Hopefully Passkeys kills 2FA for most services.
SMS 2FA is the devil. It’s the reason I haven’t swapped phone numbers even though I get 10-15 spam texts a day. The spam blocking apps don’t help and intrude on my privacy.
我的源代码对其他人来说很重要，但对我来说却不重要。我有备份。但 2FA 让我很恼火。
使用 2FA 时很容易永久丢失帐户。如果我丢失了设备，我的帐户将永远消失。
来自 github 的令牌永远不会过期，并且可以通过 API 执行所有操作，而无需接触 2FA，因此它不是那么安全。
使用 2FA 时很容易永久丢失帐户。如果我丢失了设备，我的帐户将永远消失。
来自 github 的令牌永远不会过期，并且可以通过 API 执行所有操作，而无需接触 2FA，因此它不是那么安全。
"If I lose my device my account is gone for good."
Incorrect, unless you choose not to record your seeds anywhere else, which is not a 2fa problem.
2fa is in the end nothing more than a 2nd password that just isn't sent over the wire when used.
You can store a totp seed exactly the same as a password, in any form you want, anywhere you want, and use on a brand new device at any time.
Incorrect, unless you choose not to record your seeds anywhere else, which is not a 2fa problem.
2fa is in the end nothing more than a 2nd password that just isn't sent over the wire when used.
You can store a totp seed exactly the same as a password, in any form you want, anywhere you want, and use on a brand new device at any time.
> Incorrect, unless you choose not to record your seeds anywhere else, which is not a 2fa problem.
You know google authenticator app introduced a backup feature less than 1 year ago right?
You know phones break all the time right?
You know google authenticator app introduced a backup feature less than 1 year ago right?
You know phones break all the time right?
You know google authenticator doesn't matter right? You know you could always copy your totp seeds since day one regardless of which auth app or it's features or limits right? You know that a broken device does not matter at all, because you have other copies of your seeds just like the passwords, right?
When I said they are just another password, I was neither lying nor in error. I presume you can think of all the infinite ways that you would keep copies of a password so that when your phone or laptop with keepassxc on it breaks, you still have other copies you can use. Well when I say just like a password, that's what I mean. It's just another secret you can keep anywhere, copy 50 times in different password managers or encrypted files, print on paper and stick in a safe, whatever.
Even if some particular auth app does not provide any sort of manual export function (I think google auth did have an export function even before the recent cloud backup, but let's assume it didn't), you can still just save the original number the first time you get it from a qr code or a link. You just had to know that that's what those qr codes are doing. They aren't single-use, they are nothing more than a random secret which you can keep andbcopy and re-use forever, exactly the same as a password. You can copy that number into any password manager or plain file or whatever you want just like a password, and then use it to set up the same totp on 20 different apps on 20 different devices, all working at the same time, all generating valid totp codes at the same time, destroy them all, buy a new phone, retrieve any one of your backup keepass files or printouts, and enter them into a fresh app on a fresh phone and get all your totp fully working again. You are no more locked out than by having to reinstall a password manager app and access some copy of your password db to regain the ordinary passwords.
The only difference from a password is, the secret is not sent over the wire when you use it, something derived from it is.
Google authenticators particular built in cloud copy, or lack of, doesn't matter at all, and frankly I would not actually use that particular feature or that particular app. There are lots of totp apps on all platforms and they all work the same way, you enter the secret give it a name like your bank or whatever, select which algorithm (it's always the default, you never have to select anything) and instantly the app starts generating valid totp codes for that account the same as your lost device.
Aside from saving the actual seed, let's say you don't have the original qr code any more (you didn't print it or screenshot it or right-click save image?) there is yet another emergency recovery which is the 10 or 12 recovery passwords that every site gives you when you first set up totp. You were told to keep those. They are special single-use passwords that get you in without totp, but each one can only be used once. So, you are a complete space case and somehow don't have any other copiesbof your seeds in any form, including not even simple printouts or screenshots of the original qr code, STILL no problem. You just burn one of your 12 single-use emergency codes, log in, disable and re-enable totp on that site, get a new qr code and a new set of emergency codes. Your old totp seed and old emergency codes no longer work so thow those out. This time, not only keep the emergency codes, also keep the qr code, or more practical, just keep the seed value in the qr code. It's right there in the url in the qr code. Sometimes they even display the seed value itself in plain text so that you can cut & paste it somewhere, like into a field in keepass etc.
In fact keepass apps on all platforms also will not only store the seed value but display the current totp for it just like a totp app does. But a totp app is a more convenient.
And for proper security, you technically shouldn't store both the password and the totp seed for an account in the same place, so that if someone gains access to one, they don't gain access to both. That's inconvenient but has to be said just for full correctness.
I think most sites do a completely terrible job of conveying just what totp is when you're setting it up. They tell you to scan a qr code but they kind of hide what that actually is. They DO all explain about the emergency codes but really those emergency codes are kind of stupid. If you can preserve a copy of the emergency codes, then you can just as easily preserve a copy of the seed value itself exactly the same way, and then, what's the point of a hanful of single-use emergency passwords when you can just have your normal fully functional totp seed?
Maybe one use for the emergency passwords is you could give them to different loved ones instead of your actual seed value?
Anyway if they just explained how totp basically works, and told you to keep your seed value instead of some weird emergency passwords, you wouldn't be screwed when a device breaks, and you would know it and not be worried about it.
Now, if, because of that crappy way sites obscure the process, you currently don't have your seeds in any re-usable form, and also don't have your emergency codes, well then you will be F'd when your phone breaks.
But that is fixable. Right now while it works you can log in to each totp-enabled account, and disable & reenable totp to generate new seeds, and take copies of them this time. Set them up on some other device just to see that they work. Then you will no longer have to worry about that.
When I said they are just another password, I was neither lying nor in error. I presume you can think of all the infinite ways that you would keep copies of a password so that when your phone or laptop with keepassxc on it breaks, you still have other copies you can use. Well when I say just like a password, that's what I mean. It's just another secret you can keep anywhere, copy 50 times in different password managers or encrypted files, print on paper and stick in a safe, whatever.
Even if some particular auth app does not provide any sort of manual export function (I think google auth did have an export function even before the recent cloud backup, but let's assume it didn't), you can still just save the original number the first time you get it from a qr code or a link. You just had to know that that's what those qr codes are doing. They aren't single-use, they are nothing more than a random secret which you can keep andbcopy and re-use forever, exactly the same as a password. You can copy that number into any password manager or plain file or whatever you want just like a password, and then use it to set up the same totp on 20 different apps on 20 different devices, all working at the same time, all generating valid totp codes at the same time, destroy them all, buy a new phone, retrieve any one of your backup keepass files or printouts, and enter them into a fresh app on a fresh phone and get all your totp fully working again. You are no more locked out than by having to reinstall a password manager app and access some copy of your password db to regain the ordinary passwords.
The only difference from a password is, the secret is not sent over the wire when you use it, something derived from it is.
Google authenticators particular built in cloud copy, or lack of, doesn't matter at all, and frankly I would not actually use that particular feature or that particular app. There are lots of totp apps on all platforms and they all work the same way, you enter the secret give it a name like your bank or whatever, select which algorithm (it's always the default, you never have to select anything) and instantly the app starts generating valid totp codes for that account the same as your lost device.
Aside from saving the actual seed, let's say you don't have the original qr code any more (you didn't print it or screenshot it or right-click save image?) there is yet another emergency recovery which is the 10 or 12 recovery passwords that every site gives you when you first set up totp. You were told to keep those. They are special single-use passwords that get you in without totp, but each one can only be used once. So, you are a complete space case and somehow don't have any other copiesbof your seeds in any form, including not even simple printouts or screenshots of the original qr code, STILL no problem. You just burn one of your 12 single-use emergency codes, log in, disable and re-enable totp on that site, get a new qr code and a new set of emergency codes. Your old totp seed and old emergency codes no longer work so thow those out. This time, not only keep the emergency codes, also keep the qr code, or more practical, just keep the seed value in the qr code. It's right there in the url in the qr code. Sometimes they even display the seed value itself in plain text so that you can cut & paste it somewhere, like into a field in keepass etc.
In fact keepass apps on all platforms also will not only store the seed value but display the current totp for it just like a totp app does. But a totp app is a more convenient.
And for proper security, you technically shouldn't store both the password and the totp seed for an account in the same place, so that if someone gains access to one, they don't gain access to both. That's inconvenient but has to be said just for full correctness.
I think most sites do a completely terrible job of conveying just what totp is when you're setting it up. They tell you to scan a qr code but they kind of hide what that actually is. They DO all explain about the emergency codes but really those emergency codes are kind of stupid. If you can preserve a copy of the emergency codes, then you can just as easily preserve a copy of the seed value itself exactly the same way, and then, what's the point of a hanful of single-use emergency passwords when you can just have your normal fully functional totp seed?
Maybe one use for the emergency passwords is you could give them to different loved ones instead of your actual seed value?
Anyway if they just explained how totp basically works, and told you to keep your seed value instead of some weird emergency passwords, you wouldn't be screwed when a device breaks, and you would know it and not be worried about it.
Now, if, because of that crappy way sites obscure the process, you currently don't have your seeds in any re-usable form, and also don't have your emergency codes, well then you will be F'd when your phone breaks.
But that is fixable. Right now while it works you can log in to each totp-enabled account, and disable & reenable totp to generate new seeds, and take copies of them this time. Set them up on some other device just to see that they work. Then you will no longer have to worry about that.
> since day one
But if you forgot to do it on day one, you can't do it on day two because there is no way of getting them out other than rooting the phone.
Giving how your premise was wrong, I won't bother to read that novel you wrote. I'll just assume it's all derived from the wrong premise.
But if you forgot to do it on day one, you can't do it on day two because there is no way of getting them out other than rooting the phone.
Giving how your premise was wrong, I won't bother to read that novel you wrote. I'll just assume it's all derived from the wrong premise.
My original statement was only that this is not a 2fa problem, which was and still is true.
The fact that you did not know this does not change this fact.
I acknowledged that web sites don't explain this well, even actively hide it. So it's understandable not to know this.
But I also reminded that this doesn't actually matter because you WERE also given emergency recovery passwords, and told to keep them, and told why, and how important they were.
You were never at risk of being locked out from a broken device EVEN THOUGH you didn't know about saving the seed values, UNLESS you also discarded the emergency codes, which is not a 2fa problem, it's an "I didn't follow directions" problem.
And even if all of that happened, you can still, right now, go retroactively fix it all, and get all new seed values and save them this time, as long long as your one special device happens to be working right now. It doesn't matter what features google authenticator has today, or had a year ago. It's completely and utterly irrelevant.
My premis remains correct and applicable. Your statement that 2fa places you at at risk was incorrect. You may possibly be at risk, but if so you did that to yourself, 2fa did not do that to you.
The fact that you did not know this does not change this fact.
I acknowledged that web sites don't explain this well, even actively hide it. So it's understandable not to know this.
But I also reminded that this doesn't actually matter because you WERE also given emergency recovery passwords, and told to keep them, and told why, and how important they were.
You were never at risk of being locked out from a broken device EVEN THOUGH you didn't know about saving the seed values, UNLESS you also discarded the emergency codes, which is not a 2fa problem, it's an "I didn't follow directions" problem.
And even if all of that happened, you can still, right now, go retroactively fix it all, and get all new seed values and save them this time, as long long as your one special device happens to be working right now. It doesn't matter what features google authenticator has today, or had a year ago. It's completely and utterly irrelevant.
My premis remains correct and applicable. Your statement that 2fa places you at at risk was incorrect. You may possibly be at risk, but if so you did that to yourself, 2fa did not do that to you.
My original, correct, message was perfectly short.
You don't like long full detailed explainations, and you ignore short explainations. Pick a lane!
A friend of mine a long time ago used to have a humorous classification system, that people fell into 3 groups: The clued, The clue-able, The clue-proof.
Some people already understand a thing. Some people do not understand a thing, but CAN understand it. Some people exist in a force bubble of their own intention that actively repels understanding.
You don't like long full detailed explainations, and you ignore short explainations. Pick a lane!
A friend of mine a long time ago used to have a humorous classification system, that people fell into 3 groups: The clued, The clue-able, The clue-proof.
Some people already understand a thing. Some people do not understand a thing, but CAN understand it. Some people exist in a force bubble of their own intention that actively repels understanding.
> Why opposed to MFA? Source code is one of the most important assets in our realm.
Because if you don't use weak passwords MFA doesn't add value. I do recommend MFA for most people because for most people their password is the name of their dog (which I can look up on social media) followed by "1!" to satisfy the silly number and special character rules. So yes please use MFA.
But if your (like my) passwords are 128+bits out of /dev/random, MFA isn't adding value.
Because if you don't use weak passwords MFA doesn't add value. I do recommend MFA for most people because for most people their password is the name of their dog (which I can look up on social media) followed by "1!" to satisfy the silly number and special character rules. So yes please use MFA.
But if your (like my) passwords are 128+bits out of /dev/random, MFA isn't adding value.
The slogan is "something you know and something you have", right?
I don't have strong opinions about making it mandatory, but I turned on 2FA for all accounts of importance years ago. I use a password manager, which means everything I "know" could conceivably get popped with one exploit.
It's not that much friction to pull out (or find) my phone and authenticate. It only gets annoying when I switch phones, but I have a habit of only doing that every four years or so.
You sound like you know what you're doing, that's fine, but I don't think it's true that MFA doesn't add security on average.
I don't have strong opinions about making it mandatory, but I turned on 2FA for all accounts of importance years ago. I use a password manager, which means everything I "know" could conceivably get popped with one exploit.
It's not that much friction to pull out (or find) my phone and authenticate. It only gets annoying when I switch phones, but I have a habit of only doing that every four years or so.
You sound like you know what you're doing, that's fine, but I don't think it's true that MFA doesn't add security on average.
> It only gets annoying when I switch phones
Right. I don't ever want to tie login to a phone because phones are pretty disposable.
> I don't think it's true that MFA doesn't add security on average
You're right! On average it's better, because most people have bad password and/or reuse them in more than one place. So yes MFA is better.
But if your password is already impossible to guess (as 128+ random bits are) then tacking on a few more bytes of entropy (the TOTP seed) doesn't do much.
Right. I don't ever want to tie login to a phone because phones are pretty disposable.
> I don't think it's true that MFA doesn't add security on average
You're right! On average it's better, because most people have bad password and/or reuse them in more than one place. So yes MFA is better.
But if your password is already impossible to guess (as 128+ random bits are) then tacking on a few more bytes of entropy (the TOTP seed) doesn't do much.
Those few bits are the difference between a keylogged password holder waltzing in and an automated monitor noticing that someone is failing the token check and locking the account before any damage occurs.
I think your missing parents point, both are just preshared keys, one has some additional fuzz around it so that the user in theory isn't themselves typing the same second key in all the time, but much of that security is in keeping the second secret in a little keychain device that cannot itself leak the secret. Once people put the seeds in their password managers/phones/etc its just more data to steal.
Plus, the server/provider side remains a huge weak point too. And the effort of enrolling/giving the user the initial seed is suspect.
This is why the FIDO/hardware passkeys/etc are so much better because is basically hardware enforced two way public key auth, done correctly there isn't any way to leak the private keys and its hard has hell to MITM. Which is why loss of the hw is so catastrophic. Most every other MFA scheme is just a bit of extra theater.
Plus, the server/provider side remains a huge weak point too. And the effort of enrolling/giving the user the initial seed is suspect.
This is why the FIDO/hardware passkeys/etc are so much better because is basically hardware enforced two way public key auth, done correctly there isn't any way to leak the private keys and its hard has hell to MITM. Which is why loss of the hw is so catastrophic. Most every other MFA scheme is just a bit of extra theater.
> both are just preshared keys
Exactly, that's it. Two parties have a shared secret of, say 16 bytes total, upon which authentication depends.
They could have a one byte long password but a 15 byte long shared secret used to compute the MFA code. The password is useless but the MFA seed is unguessable. Maybe have no password at all (zero length) and 16 byte seed. Or go the other way and a 16 byte password and zero seed. In terms of an attacker brute forcing the keyspace, it's always the same, 16 bytes.
We're basically saying (and as a generalization, this is true) that the password part is useless since people will just keep using their pets name, so let's put the strenght on the seed side. Fair enough, that's true.
But if you're willing to use a strong unique password then there's no real need.
(As to keyloggers, that's true, but not very interesting. If my machine is already compromised to the level that it has malicious code running logging all my input, it can steal both the passwords and the TOTP seeds and all the website content and filesystem content and so on. Game's over already.)
> This is why the FIDO/hardware passkeys/etc are so much better
Technically that's true. But in practice, we now have a few megacorporations trying to own your authentication flow in a way that introduces denial of service possibilities. I must control my authentication access, not cede control of it to a faceless corporation with no reachable support. I'd rather go back to using password123 everywhere.
Exactly, that's it. Two parties have a shared secret of, say 16 bytes total, upon which authentication depends.
They could have a one byte long password but a 15 byte long shared secret used to compute the MFA code. The password is useless but the MFA seed is unguessable. Maybe have no password at all (zero length) and 16 byte seed. Or go the other way and a 16 byte password and zero seed. In terms of an attacker brute forcing the keyspace, it's always the same, 16 bytes.
We're basically saying (and as a generalization, this is true) that the password part is useless since people will just keep using their pets name, so let's put the strenght on the seed side. Fair enough, that's true.
But if you're willing to use a strong unique password then there's no real need.
(As to keyloggers, that's true, but not very interesting. If my machine is already compromised to the level that it has malicious code running logging all my input, it can steal both the passwords and the TOTP seeds and all the website content and filesystem content and so on. Game's over already.)
> This is why the FIDO/hardware passkeys/etc are so much better
Technically that's true. But in practice, we now have a few megacorporations trying to own your authentication flow in a way that introduces denial of service possibilities. I must control my authentication access, not cede control of it to a faceless corporation with no reachable support. I'd rather go back to using password123 everywhere.
Sure it is. If your system ever gets keylogged and somebody gets your password you are compromised
With MFA even if somebody has your password if they don't have your physical authenticator too then you're relatively safe.
With MFA even if somebody has your password if they don't have your physical authenticator too then you're relatively safe.
If you have a keylogger, they can also just take your session cookie/auth tokens or run arbitrary commands while you're logged in. MFA does nothing if you're logging into a service on a compromised device.
Session keys expire and can be scoped to do anything except reset password, export data, etc…that’s why you’ll sometimes be asked to login again on some websites.
If you're on a service on a compromised device, you have effectively logged into a phishing site. They can pop-up that same re-login page on you to authorize whatever action they're doing behind the scenes whenever they need to. They can pretend to be acting wonky with a "your session expired log in again" page, etc.
This is part of why MFA just to log in is a bad idea. It's much more sensible if you use it only for sensitive actions (e.g. changing password, authorizing a large transaction, etc.) that the user almost never does. But you need everyone to treat it that way, or users will think it's just normal to be asked to approve all the time.
This is part of why MFA just to log in is a bad idea. It's much more sensible if you use it only for sensitive actions (e.g. changing password, authorizing a large transaction, etc.) that the user almost never does. But you need everyone to treat it that way, or users will think it's just normal to be asked to approve all the time.
一些 USB 密钥上有一个 LCD 屏幕，可以防止这种情况发生。您可以包含插入密钥的计算机，但无法包含密钥。如果您看到计算机屏幕上显示的消息与密钥上显示的消息不同，则表示您拒绝了身份验证请求。
Keyloggers can be physically attached to your keyboard. There could also be a vulnerability in the encryption of wireles keyboards. Certificate-based MFA is also phishing resistant, unlike long, random, unique passwords.
There are plenty of scenarios where MFA is more secure than just a strong password.
There are plenty of scenarios where MFA is more secure than just a strong password.
But password managers typically don't send keyboard commands to fill in a password, so a physical device would be useless.
> There are plenty of scenarios where MFA is more secure than just a strong password.
And how realistic are they? Or are they just highly specific scenarios where all the stars must align, and are almost never going to happen?
> There are plenty of scenarios where MFA is more secure than just a strong password.
And how realistic are they? Or are they just highly specific scenarios where all the stars must align, and are almost never going to happen?
I don't think phishing is such an obscure scenario.
The point is also that you as an individual can make choices and assess risk. As a large service provider, you will always have people who reuse passwords, store them unencrypted, fall for phishing, etc. There is a percentage of users that will get their account compromised because of bad password handling which will cost you, and by enforcing MFA you can decrease that percentage, and if you mandate yubikeys or something similar the percentage will go to zero.
The point is also that you as an individual can make choices and assess risk. As a large service provider, you will always have people who reuse passwords, store them unencrypted, fall for phishing, etc. There is a percentage of users that will get their account compromised because of bad password handling which will cost you, and by enforcing MFA you can decrease that percentage, and if you mandate yubikeys or something similar the percentage will go to zero.
These scenarios are getting into some Mission Impossible level threats.
Most people use their phones most of the time now, meaning the MFA device is the same device they're using.
Of the people who aren't using a phone, how many are using a laptop with a built in keyboard? It's pretty obvious if you have a USB dongle hanging off your laptop.
If you're using a desktop, it's going to be in a relatively secure environment. Bluetooth probably doesn't even reach outside. No one's breaking into my house to plant a keylogger. And a wireless keyboard seems kind of niche for a desktop. It's not going to move, so you're just introducing latency, dropouts, and batteries into a place where they're not needed.
Long, random, unique passwords are phishing resistant. I don't know my passwords to most sites. My web browser generates and stores them, and only uses them if it's on the right site. This has been built in functionality for years, and ironically it's sites like banks that are most likely to disable auto fill and require weak, manual passwords.
Most people use their phones most of the time now, meaning the MFA device is the same device they're using.
Of the people who aren't using a phone, how many are using a laptop with a built in keyboard? It's pretty obvious if you have a USB dongle hanging off your laptop.
If you're using a desktop, it's going to be in a relatively secure environment. Bluetooth probably doesn't even reach outside. No one's breaking into my house to plant a keylogger. And a wireless keyboard seems kind of niche for a desktop. It's not going to move, so you're just introducing latency, dropouts, and batteries into a place where they're not needed.
Long, random, unique passwords are phishing resistant. I don't know my passwords to most sites. My web browser generates and stores them, and only uses them if it's on the right site. This has been built in functionality for years, and ironically it's sites like banks that are most likely to disable auto fill and require weak, manual passwords.
我的意思是，两者可以同时成立。我必须承认，我只在被迫时才使用 MFA，因为我也相信我的强密码已经足够好了。但我仍然承认 MFA 进一步提高了安全性，特别是我可以理解为什么某些服务将其作为一项要求，因为它们无法控制用户如何选择和使用密码，任何用户泄露都会带来实际成本，无论是对他们而言（如信用卡公司或银行），还是对社会（如 PyPI、Github 等）而言，都是成本。
These days I wonder about all the cameras in a modern environment and "keylogging" from another device filming the user typing.
Haha yes they do. Everyone stores their 2fa in 1Password so once that’s stolen by a key longer they’re fucked.
> But if your (like my) passwords are 128+bits out of /dev/random, MFA isn't adding value.
no. a second factor of authentication is completely orthogonal to password complexity.
no. a second factor of authentication is completely orthogonal to password complexity.
Your password is useless when it comes to hardware keyloggers.
We run yearly tests to see if people check for "extra hardware". Needles to say we have a very high failure rate.
It's hard to get a software keylooger installed on a corp. machine. It's easy to get physical access to the office or even their homes and install keyloggers all over the place and download the data via BT.
It's hard to get a software keylooger installed on a corp. machine. It's easy to get physical access to the office or even their homes and install keyloggers all over the place and download the data via BT.
> Your password is useless when it comes to hardware keyloggers.
You are of course correct.
This is where threat modeling comes in. To really say if something is more secure or less secure or a wash, threat modeling needs to be done, carefully considering which threats you want to cover and not cover.
I this thread I'm talking from the perspective of an average individual with a personal machine and who is not interesting enough to be targeted by corporate espionage or worse.
Thus, the threat of operatives breaking into my house and installing hardware keyloggers on my machines is not part of my threat model. I don't care about that at all, for my personal use.
For sensitive company machines or known CxOs and such, yes, but that's a whole different discussion and threat model exercise.
You are of course correct.
This is where threat modeling comes in. To really say if something is more secure or less secure or a wash, threat modeling needs to be done, carefully considering which threats you want to cover and not cover.
I this thread I'm talking from the perspective of an average individual with a personal machine and who is not interesting enough to be targeted by corporate espionage or worse.
Thus, the threat of operatives breaking into my house and installing hardware keyloggers on my machines is not part of my threat model. I don't care about that at all, for my personal use.
For sensitive company machines or known CxOs and such, yes, but that's a whole different discussion and threat model exercise.
[deleted]
[deleted]
Which helps with some kinds of threats, but not all. It keeps someone from pretending to be the maintainer -- but if an actual maintainer is compromised, coerced, or just bad from the start and biding their time, they can still do whatever they want with full access rights.
You probably should have replied that to the GP, not me. I only clarified that what they were suggesting already is the case.
I find it funny how MFA is treated as if it would make account takeover suddenly impossible. It's just a bit more work, isn't it? And a big loss in convenience.
I'd much rather see passwords entirely replaced by key-based authentication. That would improve security. Adding 2FA to my password is just patching a fundamentally broken system.
I'd much rather see passwords entirely replaced by key-based authentication. That would improve security. Adding 2FA to my password is just patching a fundamentally broken system.
yeah someone replied to one of my comments about adding MFA that an attacker can get around all that simply by buying the account from the author. I was way too narrowly focused on the technical aspects and was completely blind to other avenues like social engineering, etc.
All very fair points.
All very fair points.
Customer service at one of my banks has an official policy of sending me a verification code via email that I then read to them over the phone, and that's not even close to the most "wrong" 2FA implementation I've ever seen. Somehow that institution knows what a YubiKey is, but several major banks don't.
Financial institutions are very slow to adopt new tech. Especially tech that will inevitably cost $$$ in support hours when users start locking themselves out of their accounts. There is little to no advantage to being the first bank to implement YubiKey 2FA. To a risk-averse org, the non-zero chance of a botched rollout or displeased customers outweighs any potential benefit.
They're pretty terrible when they do.
For the longest time the max password size was 8 characters and the csr knew what your password was.
Heck I've had Chase security tell me they'd call me back.. dude that's exactly how people get compromised.
For the longest time the max password size was 8 characters and the csr knew what your password was.
Heck I've had Chase security tell me they'd call me back.. dude that's exactly how people get compromised.
A friensd bank, hopefully not the one i use, only allow a password off 6 digits. Yes You read it right, 6 fucking digits to login, i hace him the asvice to run away from that shitty bank
Did this bank start out as a "telephone bank"? One of the largest German consumer banks still does this because they were the first "direct bank" without locations and typing in digits on the telephone pad was the most secure way of authenticating without telling the "bank teller" your password. So it was actually a good security measure but it is apparently too complicated to update their backend to modern standards.
They do require 2FA, though.
They do require 2FA, though.
DiBa?
Exactly. 8 character password in the 2010s as the only factor was fine. It was only my money we're talking about.
Now I have to wait for an SMS. Great...
Now I have to wait for an SMS. Great...
SMS is fine on most countries. It’s just America is dumb and allows number transfers to anyone.
Its also been a problem in Australia, Optus (2nd biggest teleco) used to allow number porting or activating sim against an existing account with a bare minimum of detail - Like a name, address and date of birth. If you had those details of a target you could clone their SIM and crack any SMS based MFA.
Number transfers in other countries is also mostly just a question of a bit of social engineering.
No. Most require some form of identification or matching identification between mobile providers.
I recently had an issue with a sim card and went to phone store that gave me a new one and disabled the old. They're supposed to ask for ID, but often doesn't bother. This is true for pretty much every country. Phone 2FA is simply completely insecure.
If the ID matching is done by humans, you can use social engineering on it.
See the sibling comment.
See the sibling comment.
SMS is not E2E encrypted, so for all intents is just a plain text message that can/has been snooped. Might as well just send a plaintext emails as well.
Nope, I read The Register (UK based) and they've had scandals from celebrities having their confidential SMS messages leaked; SMS spoofing; I think they even have SIM cloning going on every now and then in UK and some European countries. (since The Register is a tech site, my recollection is some carriers took technical measures to prevent these issues while quite a few didn't.)
I don't think it's a thing that happens that often in UK etc.; but, it doesn't happen that frequently in the US either. It's just a thing that can potentially happen.
I don't think it's a thing that happens that often in UK etc.; but, it doesn't happen that frequently in the US either. It's just a thing that can potentially happen.
UK has plenty of other problems to solve first with identity thief.
...where identity is proved by utility bills instead of government issued id
How else do you prove you live some place?
“I pay the bills there” is barely better than nothing, though. We do this in Canada too. It is what I used for a driver’s license one renewal.
“I pay the bills there” is barely better than nothing, though. We do this in Canada too. It is what I used for a driver’s license one renewal.
我不知道其他部分，但在法国短信简直是狗屎。尽管我知道自己的接待效果很好，但我经常收不到它们。
前几天，当我使用手机的移动数据进行电话会议时，就发生了这种情况，音频和视频完美。
几周前，有一些商店发送短信通知你工作已经完成，当我抱怨没有收到他们的消息时，这通常是碰运气的。
前几天，当我使用手机的移动数据进行电话会议时，就发生了这种情况，音频和视频完美。
几周前，有一些商店发送短信通知你工作已经完成，当我抱怨没有收到他们的消息时，这通常是碰运气的。
Many single radio phones can either receive sms/calls, or transmit data.
My relative owns such a device and cannot use internet during calls or receive/make calls during streaming like YT video playback.
In my case this is an iPhone 14 pro. I'm pretty sure I can receive calls while using data, since I often look things up on the internet while talking to my parents.
And, by the way, the SMS in question never arrived. I don't know if there's some kind of timeout happening, and the network gives up after a while. Some 15 years ago I remember getting texts after an hour or two if I only had spotty reception. This may of course have changed in the meantime, plus this is a different provider.
And, by the way, the SMS in question never arrived. I don't know if there's some kind of timeout happening, and the network gives up after a while. Some 15 years ago I remember getting texts after an hour or two if I only had spotty reception. This may of course have changed in the meantime, plus this is a different provider.
SS7 is a global issue, and so is social engineering to get a number transferred or SIM card transferred.
https://hitcon.org/2015/CMT/download/day1-d-r0.pdf
https://hitcon.org/2015/CMT/download/day1-d-r0.pdf
Uh many banks provide MFA. And secure with hardware keys. It’s just that your level of assets doesn’t warrant that kind of protection.
Source: worked at all the major banks, all the wealthy clients use hardware MFA
Source: worked at all the major banks, all the wealthy clients use hardware MFA
They’re a bank. If they can secure their portals with hardware keys, at least allow customers to onboard their own keys.
My bank gave me an hardware token to protect my 5k€ account.
Get better banks people :)
Get better banks people :)
I meant to say in the us. You know how backwards we are here :)
The bank I used in The Netherlands provides a MFA device as well. The device requires an ATM card as well to generate a random number.
This is the default for all their customers, wealthy or not.
https://www.abnamro.nl/en/commercialbanking/internetbanking/...
This is the default for all their customers, wealthy or not.
https://www.abnamro.nl/en/commercialbanking/internetbanking/...
I meant to say in the us :)
> There is little to no advantage to being the first bank to implement YubiKey 2FA
Ideally they’d just implement passkeys (webauthn/fido). More secure, and it works with iOS, android, 1password, and yubikeys
Ideally they’d just implement passkeys (webauthn/fido). More secure, and it works with iOS, android, 1password, and yubikeys
I'm security consultant in the financial industry. I've literally been involved in the decision making on this at a bank. Banks are very conservative, and behave like insecure teenagers. They won't do anything bold, they all just copy each other.
I pushed YubiKey as a solution and explained in detail why SMS was an awful choice, but they went with SMS anyway.
It mostly came down to cost. SMS was the cheapest option. YubiKey would involve buying and sending the keys to customers, and they having the pain/cost of supporting them. There was also the feeling that YubiKeys were too confusing for customers. The nail in the coffin was "SMS is the standard solution in the industry" plus "If it's good enough for VISA it's good enough for us".
I pushed YubiKey as a solution and explained in detail why SMS was an awful choice, but they went with SMS anyway.
It mostly came down to cost. SMS was the cheapest option. YubiKey would involve buying and sending the keys to customers, and they having the pain/cost of supporting them. There was also the feeling that YubiKeys were too confusing for customers. The nail in the coffin was "SMS is the standard solution in the industry" plus "If it's good enough for VISA it's good enough for us".
But why won’t banks at least support customer provided yubikeys?
Because it's extra hassle?
Banks loathe anything relating, or adjacent, to good SWE principles.
Bank of America supports user purchased TOTP devices.
https://www.bankofamerica.com/security-center/online-mobile-...
https://www.bankofamerica.com/security-center/online-mobile-...
Brokerage, not bank, but you can do Yubikey-only at Vanguard.
https://www.bogleheads.org/forum/viewtopic.php?t=349826
https://www.bogleheads.org/forum/viewtopic.php?t=349826
The largest US crypto brokerages/exchanges support yubikey.
Some will provide and require them for top customers to ensure they are safe.
Some will provide and require them for top customers to ensure they are safe.
I'd guess part of the reason is that customers would blame the bank when their YubiKey doesn't work, which would become a nuisance for them as much as the YubiKey's usability issues are a nuisance for the customer.
I mean your employer wasn’t wrong. Yubikeys ARE way too confusing for the average user, way too easy to lose, etc. maybe have it as an option for power users, but they were right it would be a disastrous default.
Interesting. I assumed a lot of client software for small banks was vendored - I know that's the case for brokerages. Makes it all the weirder that they all imitate each other.
Here's the thing about SMS: your great aunt who doesn't know what a JPEG is, knows what a text is. Ok, she might not fully "get it" but she knows where to find a text message in her phone. My tech-literate fiancée struggles to get her YubiKey to work with her phone, and I've tried it with no more luck than she's had. YubiKeys should be supported but they're miles away from being usable enough to totally supplant other 2FA flows.
Here's the thing about SMS: your great aunt who doesn't know what a JPEG is, knows what a text is. Ok, she might not fully "get it" but she knows where to find a text message in her phone. My tech-literate fiancée struggles to get her YubiKey to work with her phone, and I've tried it with no more luck than she's had. YubiKeys should be supported but they're miles away from being usable enough to totally supplant other 2FA flows.
Banks are in a tough spot. Remember, banks have you as a customer, they also have a 100 year old person who still wants to come to the branch in person as a customer. Not everyone can grapple with the idea of a Yubikey, or why their bank shouldn't be protecting their money like it did in the past.
The problem is that the bank will automatically enable online access and SMS-confirmed transfers for that 100 year old person who doesn't even know how to use Internet.
[deleted]
Passkeys are being introduced right now in browsers and popular sites like a MFA option, but I think the intention is that they will grow and become the main factor in the future.
From what I've seen they're all controlled by huge tech companies. Hard pass.
I liked the username, password and TOTP combination. I could choose my own password manager, and TOTP generator app, based on my preferences.
I have a feeling this won't hold true forever. Microsoft has their own authenticator now, Steam has another one, Google has their "was this you?" built into the OS.
Monetization comes next? "View this ad before you login! Pay 50c to stay logged in for longer?"
I have a feeling this won't hold true forever. Microsoft has their own authenticator now, Steam has another one, Google has their "was this you?" built into the OS.
Monetization comes next? "View this ad before you login! Pay 50c to stay logged in for longer?"
Passkeys are an open standard with multiple implementations. It represents the opposite of the trend you're worried about there.
But the way it is designed, you can require a certain provider, and you can bet at least some sites will start requiring attestation from Google and or Apple.
Do they do attestation by default? I thought for Apple at least that was only a feature for enterprise managed devices (MDM). Attestation is also a registration-time check, so doesn’t necessarily constrain where the passkey is synced to later on.
MS Azure Active Entra's FIDO2 implementation only allows a select list of vendors. You need a certification from FIDO ($,$$$), you need to have an account that can upload on the MDS metadata service, and you need to talk to MS to see if they'll consider adding you to the list
It's not completely closed, but in practice no one on that list is a small independent open source project, those are all the kind of entrenched corporate security companies you'd expect
It's not completely closed, but in practice no one on that list is a small independent open source project, those are all the kind of entrenched corporate security companies you'd expect
Because that worked so well for OpenID. If you're lucky, you have the choice of which BigTech account you can use.
TOTP has substantial security gaps to make it a non-starter.
Maybe a pubkey system where you choose your own client would be what you’re looking for?
Maybe a pubkey system where you choose your own client would be what you’re looking for?
TLS Client Certs (aka mTLS) is an option for that, but the browser UI stuff for it is terrible and getting worse.
I couldn’t imagine trying to train the general public to use mTLS and deploy that system.
I’m not even sure it is difficult. Most people I’ve talked to in tech don’t even realize it is a possibility. Certificates are “complicated” as they put it.
I’m not even sure it is difficult. Most people I’ve talked to in tech don’t even realize it is a possibility. Certificates are “complicated” as they put it.
> Google has their "was this you?" built into the OS.
Not only that, but it's completely impossible to disable or remove that functionality or even make TOTP the primary option. Every single time I try to sign in, Google prompts my phone first, giving me a useless notification for later, and I have to manually click a couple of buttons to say "no I am not getting up to grab my phone and unlock it for this bullshit, let me enter my TOTP code". Every single time.
Not only that, but it's completely impossible to disable or remove that functionality or even make TOTP the primary option. Every single time I try to sign in, Google prompts my phone first, giving me a useless notification for later, and I have to manually click a couple of buttons to say "no I am not getting up to grab my phone and unlock it for this bullshit, let me enter my TOTP code". Every single time.
Password managers are adding support (as in they control the keys) and I've used my yubikeys as "passkeys" (with the difference that I can't autofill the username).
It's a good spec. I wish more people who spread FUD about it being a "tech-giant" only thing would instead focus on the productive things like demanding proper import/export between providers.
It's a good spec. I wish more people who spread FUD about it being a "tech-giant" only thing would instead focus on the productive things like demanding proper import/export between providers.
You realise that the second your password manager has it, then it's no longer MFA but it's just 1 factor authentication with extra steps right?
Password manager turns something you know into something you own. If also the something you own is in the password manager itself… it's the same as requiring extra long passwords.
Password manager turns something you know into something you own. If also the something you own is in the password manager itself… it's the same as requiring extra long passwords.
I don't understand this criticism. What is being controlled? Passkeys are an open standard that a browser can implement with public key crypto.
Doesn't passkeys give the service a signature to prove what type of hardware device you're using? e.g. it provides a way for the server to check whether you are using a software implementation? It's not really open if it essentially has type of DRM built in.
You're thinking of hardware-backed attestation, which provides a hardware root of trust. I believe passkeys are just challenge-response (using public key cryptography). You could probably add some sort of root of trust (for example, have the public key signed by the HSM that generated it) but that would be entirely additional to the passkey itself.
Passkeys do have the option of attestation, but the way Apple at least do them means Apple users won't have attestation, so most services won't require attestation.
They also require JavaScript to work unfortunately.
KeepassXC is working on supporting them natively in software, so you would not need to trust big tech companies, unless you are logging into a service that requires attestation to be enabled.
>I'd much rather see passwords entirely replaced by key-based authentication
I've never understood how key-based systems are considered better. I understand the encryption angle, nobody is compromising that. But now I have a key I need to personally shepherd? where do I keep it, and my backups, and what is the protection on those places? how many local copies, how many offsite? And I still need a password to access/use it, but with no recourse should I lose or forget. how am I supposed to remember that? It's all just kicking the same cans down the same roads.
I've never understood how key-based systems are considered better. I understand the encryption angle, nobody is compromising that. But now I have a key I need to personally shepherd? where do I keep it, and my backups, and what is the protection on those places? how many local copies, how many offsite? And I still need a password to access/use it, but with no recourse should I lose or forget. how am I supposed to remember that? It's all just kicking the same cans down the same roads.
正如我最近在一次演讲中所说，由 pypy 或 github 实现的 2FA 毫无意义，而实际上所有操作都是通过永不过期的令牌执行的，这些令牌保存在磁盘上的 .txt 文件中。
Doesn't GH explicitly warn against using non-expiring tokens?
Passwords have full scope of permission while session tokens can be limited.
In pypi to obtain a token that is limited in scope you must first generate an unlimited token.
True story.
In gh you can generate a limited one, but it's not really clear on what the permissions actually mean, so it's trial and error… which means most people will get tired and grant random stuff to have them working.
True story.
In gh you can generate a limited one, but it's not really clear on what the permissions actually mean, so it's trial and error… which means most people will get tired and grant random stuff to have them working.
我对 pypi 不太了解，但 github 对我来说似乎还不错。我还实现了自己的范围认证系统，所以即使它们并不完美，我也知道这是可以做到的
For some random server, sure. For a state sponsored attack? Having an embedded exploit you can use when convenient, or better yet an unknown exploit affecting every linux-based system connected to the internet that you can use when war breaks out - that's invaluable.
Yes, but even states have only finite resources, so even for them compromising an account would be cheaper.
(But you are right that a sleeper would be affordable for them.)
(But you are right that a sleeper would be affordable for them.)
Having one or two people on payroll to occasionally add commits to a project isn't exactly that expensive if it pays off. There are ~29,000,000 US government employees (federal, state and local). Other countries like China and India have tens of millions of government employees.
And they might as well be working on compromising other projects using different handles.
Not all government employees are equally capable.
Even if they contract it out, at $350/hr (which is not a price that would raise any flags), that is less that $750k. Even with a fancy office, couple of laptops and 5' monitors, this is less than a day at the bombing range or a few minutes keeping an aircraft carrier operational.
Even a team of 10 people working on this - the code and social aspect - would be a drop in the bucket for any nation-state.
Even a team of 10 people working on this - the code and social aspect - would be a drop in the bucket for any nation-state.
It’s a very cheap investment given the blast radius
they might not have been playing the long con. maybe approached by actors willing to pay them a lot of money to try and slip in a back door. I'm sure a deep dive into code contributions would clear that up for anyone familiar with the code base and some free time.
[deleted]
They did fuck up quite a bit though.
They injected their payload before they checked if oss-fuzz or valgrind or ... would notice something wrong.
That is sloppy and should have been anticipated and addressed BEFORE activating the code.
Anyway. This team got caught. What are the odds that this state-actor that did this, that this was the only project / team / library that they decided to attack?
Anyway. This team got caught. What are the odds that this state-actor that did this, that this was the only project / team / library that they decided to attack?
Using sockpuppets to pressure the original maintainer into granting commit access in the first place backs the long con theory.
2023 年 7 月 8 日的这篇 PR 很可疑，所以这很可能是一个长期骗局：https://github.com/google/oss-fuzz/pull/10667
不是 MFA，而是 git commit 签名。我不明白为什么这样的核心低级项目不强制执行它。如果 github 访问令牌被盗，MFA 也无济于事，我敢打赌大多数人都使用这样的令牌从 IDE 进行推送。
即使 github 的访问令牌被盗，突然缺少签名的提交也会引发危险信号。 github 应该允许项目强制提交签名（如果还不可能）。
然后，需要窃取访问令牌和歌唱密钥。
但当然，所有这些对于国家资助的黑客长期骗局或胁迫的情况都无济于事（在某些国家，这似乎很可能发生）
即使 github 的访问令牌被盗，突然缺少签名的提交也会引发危险信号。 github 应该允许项目强制提交签名（如果还不可能）。
然后，需要窃取访问令牌和歌唱密钥。
但当然，所有这些对于国家资助的黑客长期骗局或胁迫的情况都无济于事（在某些国家，这似乎很可能发生）
Git signing would not have helped here. In fact, the tags and release archives were signed.
This is a state sponsored event.
Pretty poorly executed though as they were tweaking and modifying things in their and other tools after the fact though.
As a state sponsored project. What makes you think this is their only project and that this is a big setback? I am paranoid myself to think yesterdays meeting went like : "team #25 has failed/been found out. Reallocate resources to the other 49 teams."
As a state sponsored project. What makes you think this is their only project and that this is a big setback? I am paranoid myself to think yesterdays meeting went like : "team #25 has failed/been found out. Reallocate resources to the other 49 teams."
And, Joey Hess has counted at least 750 commits to xz from that handle.
https://hachyderm.io/@joeyh/112180715824680521
This does not look trust-inspiring. If the code is complex, there could be many more exploits hiding.
https://hachyderm.io/@joeyh/112180715824680521
This does not look trust-inspiring. If the code is complex, there could be many more exploits hiding.
clickhouse 在 Playground 上有相当不错的 github_events 数据集，人们可以用它来做一些研究 - 有关数据集的一些信息 https://ghe.clickhouse.tech/
该用户 JiaT75 到目前为止所做的示例：
https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPT...
在过去 60 天内提及 xz、5.6 且未降级、cve 的拉取请求：
https://play.clickhouse.com/play?user=play#U0VMRUNUIGNyZWF0Z...
该用户 JiaT75 到目前为止所做的示例：
https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPT...
在过去 60 天内提及 xz、5.6 且未降级、cve 的拉取请求：
https://play.clickhouse.com/play?user=play#U0VMRUNUIGNyZWF0Z...
Yeah. It would be interesting to see who adopted to the compromised versions and how quickly, compared to how quickly they normally adopt new versions (not bots pulling upgrades, but how quickly maintainers approve and merge them)
If there were a bunch of people who adopted it abnormally fast compared to usual, might point to there being more "bad actors" in this operation (said at the risk of sounding paranoid if this turns out to be a state run thing)
If there were a bunch of people who adopted it abnormally fast compared to usual, might point to there being more "bad actors" in this operation (said at the risk of sounding paranoid if this turns out to be a state run thing)
750 commits... is xz able to send e-mails yet?
No. But if you have any centrifuges they will probably exhibit inconsistent behavior.
Maybe it’s the centrifuges which will send the mail, making the world’s first uranium-enriching spam botnet.
Yes, it sends an email containing your private key on installation.
It's hardly surprising given that parsing is generally considered to be a tricky problem. Plus, it's a 15 years old project that's widely used. 750 commits is nothing to sneer about. No wonder the original maintainer got burned out.
750 is not that many commits if you follow a commit style where each independent change gets its own commit.
Anyone have any level of confidence that for example EL7/8 would not be at risk even if more potential exploits at play?
I wouldn't count on it. RedHat packages contain lots of backported patches.
Right, that notion was what was making me nervous
At least in my group, the backports are hand picked to solve specific problems, not just random wholesale backports.
Sure, they aren't backporting patches wholesale. But the patches that did get backported, if any, needs much more scrutiny given the situation.
The thing about enterprise Linux distros is that they have a long support period. Bug fixes and security patches pile up.
Fortunately though, xz doesn't seem to have a lot of backported patches.
https://git.centos.org/rpms/xz/blob/c8s/f/SPECS/xz.spec https://git.centos.org/rpms/xz/blob/c7/f/SPECS/xz.spec
But take glibc for example. The amount of patches makes my head spin.
https://git.centos.org/rpms/glibc/blob/c8s/f/SPECS/glibc.spe...
The thing about enterprise Linux distros is that they have a long support period. Bug fixes and security patches pile up.
Fortunately though, xz doesn't seem to have a lot of backported patches.
https://git.centos.org/rpms/xz/blob/c8s/f/SPECS/xz.spec https://git.centos.org/rpms/xz/blob/c7/f/SPECS/xz.spec
But take glibc for example. The amount of patches makes my head spin.
https://git.centos.org/rpms/glibc/blob/c8s/f/SPECS/glibc.spe...
For the duration of a major release, up until ~x.4 pretty much everything from upstream gets backported with a delay of 6-12 months, depending on how conservative to change the rhel engineer maintaining this part of the kernel is.
After ~x.4 things slow down and only "important" fixes get backported but no new features.
After ~x.7 or so different processes and approvals come into play and virtually nothing except high severity bugs or something that "important customer" needs will be backported.
After ~x.4 things slow down and only "important" fixes get backported but no new features.
After ~x.7 or so different processes and approvals come into play and virtually nothing except high severity bugs or something that "important customer" needs will be backported.
Sadly, 8.6 and 9.2 kernel are the exception to this. Mainly as they are openshift container platform and fedramp requirements.
The goal is that 8.6, 9.2 and 9.4 will have releases at least every two weeks.
Maybe soon all Z streams will have a similar release cadence to keep up with the security expectations, but will keep a very similar expectations that you outlined above.
The goal is that 8.6, 9.2 and 9.4 will have releases at least every two weeks.
Maybe soon all Z streams will have a similar release cadence to keep up with the security expectations, but will keep a very similar expectations that you outlined above.
These changes were not backported to RHEL.
I don't think EL7 gets minor version updates anymore though
RedHat blog says no versions of RHEL are affected.
https://www.redhat.com/en/blog/urgent-security-alert-fedora-...
https://www.redhat.com/en/blog/urgent-security-alert-fedora-...
alex_duf(1)
If this is a conspiracy or a state-sponsored attack, they might have gone specifically for embedded devices and the linux kernel. Here archived from tukaani.org:
https://web.archive.org/web/20110831134700/http://tukaani.or...
> XZ Embedded is a relatively small decompressor for the XZ format. It was developed with the Linux kernel in mind, but is easily usable in other projects too.
> *Features*
> * Compiled code 8-20 KiB
> [...]
> * All the required memory is allocated at initialization time.
This is targeted at embedded and real-time stuff. Could even be part of boot loaders in things like buildroot or RTEMS. And this means potentially millions of devices, from smart toasters or toothbrushes to satellites and missiles which most can't be updated with security fixes.
https://web.archive.org/web/20110831134700/http://tukaani.or...
> XZ Embedded is a relatively small decompressor for the XZ format. It was developed with the Linux kernel in mind, but is easily usable in other projects too.
> *Features*
> * Compiled code 8-20 KiB
> [...]
> * All the required memory is allocated at initialization time.
This is targeted at embedded and real-time stuff. Could even be part of boot loaders in things like buildroot or RTEMS. And this means potentially millions of devices, from smart toasters or toothbrushes to satellites and missiles which most can't be updated with security fixes.
jnxx(2)
One scenario for malicious code in embedded devices would be a kind of killswitch which listens to a specific byte sequence and crashes when encountering it. For a state actor, having such an exploit would be gold.
That's an "interesting" thought.
One of my complaints about so many SciFi stories is the use of seemingly conventional weapons. I always thought that with so much advanced technology that weapons would be much more sophisticated. However if the next "great war" is won not by the side with the most destructive weapons but by the side with the best kill switch, subsequent conflicts might be fought with weapons that did not rely on any kind of computer assistance.
This is eerily similar to Einstein's (purported) statement that if World War III was fought with nuclear weapons, World War IV would be fought with sticks and stones. Similar, but for entirely different reasons.
I'm trying to understand why the characters in Dune fought with swords, pikes and knives.
One of my complaints about so many SciFi stories is the use of seemingly conventional weapons. I always thought that with so much advanced technology that weapons would be much more sophisticated. However if the next "great war" is won not by the side with the most destructive weapons but by the side with the best kill switch, subsequent conflicts might be fought with weapons that did not rely on any kind of computer assistance.
This is eerily similar to Einstein's (purported) statement that if World War III was fought with nuclear weapons, World War IV would be fought with sticks and stones. Similar, but for entirely different reasons.
I'm trying to understand why the characters in Dune fought with swords, pikes and knives.
> I'm trying to understand why the characters in Dune fought with swords, pikes and knives.
At least part of the reason is that the interaction between a lasgun and a shield would cause a powerful explosion that would kill the shooter too. No one wants that and no one will give up their shield, so they had to go back to melee weapons.
At least part of the reason is that the interaction between a lasgun and a shield would cause a powerful explosion that would kill the shooter too. No one wants that and no one will give up their shield, so they had to go back to melee weapons.
Were drones unthinkable at the time of Dune creation?
Or suicide attacks?
No, there is a in-world reason at least for no drones. Wikipedia:
> However, a great reaction against computers has resulted in a ban on any "thinking machine", with the creation or possession of such punishable by immediate death.
> However, a great reaction against computers has resulted in a ban on any "thinking machine", with the creation or possession of such punishable by immediate death.
For anyone who wants the short version: https://www.youtube.com/watch?v=2YnAs4NpRd8
tl;dr - Machine intelligences existed in Dune history, were discovered to be secretly controlling humanity (through abortion under false pretenses, forced sterilization, emotional/social control, and other ways), then were purged and replaced with a religious commandment: "Thou shalt not make a machine in the likeness of a human mind"
tl;dr - Machine intelligences existed in Dune history, were discovered to be secretly controlling humanity (through abortion under false pretenses, forced sterilization, emotional/social control, and other ways), then were purged and replaced with a religious commandment: "Thou shalt not make a machine in the likeness of a human mind"
There is a drone attack in a first movie
In the book Paul is attacked by an insect drone while in his room. The drone was controlled by a Harkonnen agent placed weeks in anticipation inside a structure of the palace so it was also a suicide attack as the agent had no chance to escape and would die of hunger/thirsty if not found.
No, and there is a (piloted) drone attack in the first book -- Paul is attacked by a hunter-seeker.
The reason nobody tries to use the lasgun-shield interaction as a weapon is because the resulting explosion is indistinguishable from a nuclear weapon, and the Great Convention prohibits the use of nukes on human targets.
Just the perception of having used a nuclear device would result in the House which did so becoming public enemy #1 and being eradicated by the Landsraad and Sardaukar combined.
The reason nobody tries to use the lasgun-shield interaction as a weapon is because the resulting explosion is indistinguishable from a nuclear weapon, and the Great Convention prohibits the use of nukes on human targets.
Just the perception of having used a nuclear device would result in the House which did so becoming public enemy #1 and being eradicated by the Landsraad and Sardaukar combined.
Nope. That's all I'm going to spoiler;-)
@Potro: If you liked the movie, read the books. I don't read a lot anymore, but during sick leave I started with the first book. Didn't stop until I finished the main story, including the sequels by Frank Herbert's son about a month later. That's like... uh... nine books?
@Potro: If you liked the movie, read the books. I don't read a lot anymore, but during sick leave I started with the first book. Didn't stop until I finished the main story, including the sequels by Frank Herbert's son about a month later. That's like... uh... nine books?
> I'm trying to understand why the characters in Dune fought with swords, pikes and knives.
Because the author wanted a pseudo-medieval setting.
(The shields and the prohibition against computers, nukes etc were just clever plot devices to make advanced weapons unusable).
Because the author wanted a pseudo-medieval setting.
(The shields and the prohibition against computers, nukes etc were just clever plot devices to make advanced weapons unusable).
All this circus makes me happy for never moving from sysvinit on embedded.
It is not just systemd which uses xz. For example, Debian's dpkg links xz-utils.
However, this particular attack only works through libsystemd to compromise sshd and it is related to systemd's kitchen sink "design".
It's related to excessive coupling between modules and low coherence.
There is a way for programs to implement the systemd readiness notification protocol without using libsystemd, and thus without pulling in liblzma, which is coupled to libsystemd even though the readiness notification protocol does not require any form of compression. libsystemd provides a wide range of things which have only weak relationships to each other.
There are in fact two ways, as two people independently wrote their own client code for the systemd readiness notification protocol, which really does not require the whole of libsystemd and its dependencies to achieve. (It might be more than 2 people nowadays.)
* https://jdebp.uk/FGA/unix-daemon-readiness-protocol-problems...
There is a way for programs to implement the systemd readiness notification protocol without using libsystemd, and thus without pulling in liblzma, which is coupled to libsystemd even though the readiness notification protocol does not require any form of compression. libsystemd provides a wide range of things which have only weak relationships to each other.
There are in fact two ways, as two people independently wrote their own client code for the systemd readiness notification protocol, which really does not require the whole of libsystemd and its dependencies to achieve. (It might be more than 2 people nowadays.)
* https://jdebp.uk/FGA/unix-daemon-readiness-protocol-problems...
如果您已经不喜欢 systemd，那么很容易验证您现有的偏见。事实上，从“最终用户界面”的角度来看，systemd 的设计比其前身更加连贯，因此它的单元在很大程度上是可移植的等，而 sysvinit 的情况并非如此。
现实情况是，它并不是专门针对 systemd 的，而是我们现代的软件设计方法，我们倾向于依赖太多的第三方代码，并乐于设计极其灵活但最终极其复杂的软件。
我的意思是，就近年来各种 CPU 攻击向量而言，这也是事实，是的，推测执行是一种简洁而“聪明”的优化，我们依靠它来提高速度，但也许这是一条太聪明的道路，我们应该坚持采用更简单的设计，这可能会导致速度较慢，但为构建未来几代 CPU 奠定了更坚实的基础。
现实情况是，它并不是专门针对 systemd 的，而是我们现代的软件设计方法，我们倾向于依赖太多的第三方代码，并乐于设计极其灵活但最终极其复杂的软件。
我的意思是，就近年来各种 CPU 攻击向量而言，这也是事实，是的，推测执行是一种简洁而“聪明”的优化，我们依靠它来提高速度，但也许这是一条太聪明的道路，我们应该坚持采用更简单的设计，这可能会导致速度较慢，但为构建未来几代 CPU 奠定了更坚实的基础。
People hate systemd from an ethical, philosophical, and ideological standpoint.
People love systemd for the efficiency, economics, etc.
It's like ideal vs production.
Let's be real, sshd loading random libraries it doesn't actually need because distros patched in a kitchen sink library is inexcusable. That kitchen sink library is libsystemd and it follows the same kitchen sink design principle that systemd-opponents have been criticising all along. But its easier to accuse them of being biased rather consider that maybe they have a point.
This is only evidence that libsystemd is popular. If you want to 0wn a bunch of systems, or even one particular system but make it non-obvious, you choose a popular package to mess with.
BeOS isn't getting a lot of CVEs attached to it, these days. That doesn't mean its good or secure, though.
BeOS isn't getting a lot of CVEs attached to it, these days. That doesn't mean its good or secure, though.
All that could change if BeOS adopts systemd.
> If the code is complex, there could be many more exploits hiding.
Then the code should not be complex. Low-level hacks and tricks (like pointer juggling) should be not allowed and simplicity and readability should be preferred.
Then the code should not be complex. Low-level hacks and tricks (like pointer juggling) should be not allowed and simplicity and readability should be preferred.
For tools like compression programs, you’d generally prefer performance over everything (except data corruption, of course).
Probably you would prefer no backdoors also?
Performance without correctness or trustworthiness is useless.
Yes, but my point was that at the level of performance tools like this are expected to operate at, it’s highly probable that you’ll need to get into incredibly esoteric code. Look at ffmpeg – tons of hand-written Assembly, because they need it.
To be clear, I have no idea how to solve this problem; I just don’t think saying that all code must be non-hacky is the right approach.
To be clear, I have no idea how to solve this problem; I just don’t think saying that all code must be non-hacky is the right approach.
Performance can be bought with better hardware. It gets cheaper and cheaper every year. Trustworthiness cannot be purchased in the same way. I do not understand why performance would ever trumph clean code, especially for for code that processes user provided input.
> Performance can be bought with better hardware.
I hate this argument. If current hardware promises you a theoretical throughput of 100 MB/s for an operation, someone will try to hit that limit. Your program that has no hard to understand code but gives me 5 MB/s will loose in the face of a faster one, even if that means writing harder to understand code.
I hate this argument. If current hardware promises you a theoretical throughput of 100 MB/s for an operation, someone will try to hit that limit. Your program that has no hard to understand code but gives me 5 MB/s will loose in the face of a faster one, even if that means writing harder to understand code.
There is no reason that understandable and safe code will hit just 5% of a theoretical max. It may be closer to 95%.
No, but often it is far worse than 95%. A good example is random.randint() vs math.ceil(random.random() * N) in Python. The former is approximately 5x slower than the latter, but they produce effectively the same result with large enough values of N. This isn’t immediately apparent from using them or reading docs, and it’s only really an issue in hot loops.
Another favorite of mine is bitshifting / bitwise operators. Clear and obvious? Depends on your background. Fast as hell? Yes, always. It isn’t always needed, but when it is, it will blow anything else out of the water.
Another favorite of mine is bitshifting / bitwise operators. Clear and obvious? Depends on your background. Fast as hell? Yes, always. It isn’t always needed, but when it is, it will blow anything else out of the water.
Those Python snippets are both clean options :)
Bitwise is highly context dependent. There are simple usages like shifts to divide/multiply by 2. Idiomatic patterns that are clean when wrapped in good reusable and restricted macros, like for common registers manipulation in microcontrollers. And other uses that are anything from involuntary obfuscation to competition grade obfuscation.
Bitwise is highly context dependent. There are simple usages like shifts to divide/multiply by 2. Idiomatic patterns that are clean when wrapped in good reusable and restricted macros, like for common registers manipulation in microcontrollers. And other uses that are anything from involuntary obfuscation to competition grade obfuscation.
> There are simple usages like shifts to divide/multiply by 2.
Clean code should not do that as the compiler will do that.
Clean code should just say what it wants to do, not replace that with low-level performance optimizations. (Also wasn't performance to be obtained from newer hardware?)
Clean code should not do that as the compiler will do that.
Clean code should just say what it wants to do, not replace that with low-level performance optimizations. (Also wasn't performance to be obtained from newer hardware?)
The compiler will almost always do the bit shifting, and better for you. Just switch python with rust and you’ll get both performance and safe code
This attitude is how we get streaming music players that consume in excess of 1 GiB of RAM.
Performant code needn’t be unclean; it’s just often using deeper parts of the language.
I have a small project that became absolute spaghetti. I rewrote it to be modular, using lots of classes, inheritance, etc. It was then slower, but eminently more maintainable and extensible. I’m addressing that by using more advanced features of the language (Python), like MemoryView for IPC between the C libraries it calls. I don’t consider this unclean, but it’s certainly not something you’re likely to find on a Medium article or Twitter take.
I value performant code above nearly everything else. I’m doing this for me, there are no other maintainers, and it’s what I enjoy. You’re welcome to prioritize something else in your projects, but it doesn’t make other viewpoints objectively worse.
Performant code needn’t be unclean; it’s just often using deeper parts of the language.
I have a small project that became absolute spaghetti. I rewrote it to be modular, using lots of classes, inheritance, etc. It was then slower, but eminently more maintainable and extensible. I’m addressing that by using more advanced features of the language (Python), like MemoryView for IPC between the C libraries it calls. I don’t consider this unclean, but it’s certainly not something you’re likely to find on a Medium article or Twitter take.
I value performant code above nearly everything else. I’m doing this for me, there are no other maintainers, and it’s what I enjoy. You’re welcome to prioritize something else in your projects, but it doesn’t make other viewpoints objectively worse.
Performant code does not need to be unclean, exactly! My original point was just to not put performance on a pedestal. Sure, prioritize it, but correct and clean should come first - at least for foundational libraries that others are supposed to build upon.
I maintain ML libraries that run on microcontrollers with kilobytes of memory, performance is a friend of mine ;)
I maintain ML libraries that run on microcontrollers with kilobytes of memory, performance is a friend of mine ;)
I suggest you run your browsers Javascript engine in interpreter mode to understand how crippling the simple and sraight forward solution is to performance.
I guess because at server farm level, performance/efficiency translate to real million USD savings. In general, at scale ends (the cloud and the embedded) this matters a lot. In resource limited environments like raspberry pi, this design philosophy wins over many users between DIY and the private industry.
Faster and more complex hardware can also have bugs or back doors, as can cheaper hardware. That said, I'm not happy with buggy and untrustworthy code either.
I have some questions.
1) Are there no legit code reviews from contributors like this? How did this get accepted into main repos while flying under the radar? When I do a code review, I try to understand the actual code I'm reviewing. Call me crazy I guess!
2) Is there no legal recourse to this? We're talking about someone who managed to root any linux server that stays up-to-date.
1) Are there no legit code reviews from contributors like this? How did this get accepted into main repos while flying under the radar? When I do a code review, I try to understand the actual code I'm reviewing. Call me crazy I guess!
2) Is there no legal recourse to this? We're talking about someone who managed to root any linux server that stays up-to-date.
> 2) Is there no legal recourse to this? We're talking about someone who managed to root any linux server that stays up-to-date.
Any government which uses GNU/Linux in their infrastructure can pitch this as an attempt to backdoor their servers.
The real question is: will we ever even know who was behind this? If it was some mercenary hacker intending to resell the backdoor, maybe. But if it was someone working with an intelligence agency in US/China/Israel/Russia/etc, I doubt they'll ever be exposed.
Any government which uses GNU/Linux in their infrastructure can pitch this as an attempt to backdoor their servers.
The real question is: will we ever even know who was behind this? If it was some mercenary hacker intending to resell the backdoor, maybe. But if it was someone working with an intelligence agency in US/China/Israel/Russia/etc, I doubt they'll ever be exposed.
反思为软件贡献引入验证结构的想法（类似于 RPKI 对 BGP 路由所做的事情），我看到了增强软件开发中的安全性和问责制的巨大潜力。
从理论上讲，这样的系统可以带来更大的透明度和责任感，特别是在一个贡献来自各个角落的生态系统中。
为贡献者实施可验证的身份证明可能具有挑战性，但它也提供了一个在不损害隐私和以假名贡献的自由的情况下增强安全性的机会。
接受拉取请求的人的责任也将变得更加清晰，从而可能降低恶意代码被合并的风险。
当然，建立强大的软件验证链需要开发生态系统中每个人的承诺，包括 GitHub 这样的平台。然而，我认为这不是一个障碍，而是发展我们软件开发中的安全和协作方法的重要一步。
从理论上讲，这样的系统可以带来更大的透明度和责任感，特别是在一个贡献来自各个角落的生态系统中。
为贡献者实施可验证的身份证明可能具有挑战性，但它也提供了一个在不损害隐私和以假名贡献的自由的情况下增强安全性的机会。
接受拉取请求的人的责任也将变得更加清晰，从而可能降低恶意代码被合并的风险。
当然，建立强大的软件验证链需要开发生态系统中每个人的承诺，包括 GitHub 这样的平台。然而，我认为这不是一个障碍，而是发展我们软件开发中的安全和协作方法的重要一步。
The actual inclusion code was never in the repo. The blobs were hidden as lzma test files.
So you review would need to guess from 2 new test files that those are, decompressed, a backdoor and could be injected which was never in the git history.
This was explicitly build to evade such reviews.
So you review would need to guess from 2 new test files that those are, decompressed, a backdoor and could be injected which was never in the git history.
This was explicitly build to evade such reviews.
I suppose you think the maintainers shouldn’t have scrutinized those files? Please tell me it’s a joke.
The person who added the malicious blobs and signed the compromized archives was literally a maintainer of the project.
Ok, go ahead and scrutinize those files without looking at the injection code that was never in the repo? Can you find anything malicious? Probably not - it looks like random garbage which is what it was claimed to be.
> The blobs were hidden as lzma test files.
OK, that is absolutely devious.
OK, that is absolutely devious.
>How did this get accepted into main repos while flying under the radar? When I do a code review, I try to understand the actual code I'm reviewing. Call me crazy I guess!
And? You never do any mistakes? Google "underhanded C contest"
And? You never do any mistakes? Google "underhanded C contest"
"Jia Tan" was not a contributor, but a maintainer of the project. The key point here is that this is a multi-year project of infiltrating the xz project and gaining commit access.
In a large tech company (including ones I have worked at), sometimes you have policy where every change has to be code reviewed by another person. This kind of stuff isn't possible when the whole project only has 1-2 maintainers. Who's going to review your change other than yourself? This is the whole problem of OSS right now that a lot of people are bringing up.
I maintain a widely used open source project myself. I would love it if I could get high quality code review for my commits similar to my last workplace lol, but very very few people are willing to roll up their sleeves like that and work for free. Most people would just go to the Releases page and download your software instead.
In a large tech company (including ones I have worked at), sometimes you have policy where every change has to be code reviewed by another person. This kind of stuff isn't possible when the whole project only has 1-2 maintainers. Who's going to review your change other than yourself? This is the whole problem of OSS right now that a lot of people are bringing up.
I maintain a widely used open source project myself. I would love it if I could get high quality code review for my commits similar to my last workplace lol, but very very few people are willing to roll up their sleeves like that and work for free. Most people would just go to the Releases page and download your software instead.
Warning, drunk brain talking. But a LLM driven email based "collaborator" could play a very long gMw adding basic features to a code made whilst earning trust backed by a generated online presence. My money is on a resurgance in the Web of Trust.
Clearly a human is even better at it.
State level actor? China?
您可能会被否决，因为看起来像东亚人的 Github 个人资料并不能证明攻击者来自哪里。
民族国家将竭尽全力掩饰自己的身份。当他们不是俄语时使用蹩脚的俄语英语，在另一种语言的代码中添加注释，以及各种其他东西来制造误导。
民族国家将竭尽全力掩饰自己的身份。当他们不是俄语时使用蹩脚的俄语英语，在另一种语言的代码中添加注释，以及各种其他东西来制造误导。
That's certainly true-- at the very least it "seems" like Asian, but it could very well be from any nation. If they were patient enough to work up to this point they would likely not be dumb enough to leak such information.
Otoh with these kind of kneejerk "antiracist" reactions the best way to disguise a chinese operative becomes to prentend you're chinese.
The web of trust is a really nice idea, but it works badly against that kind of attacks. Just consider that in the real world, most living people (all eight billions) are linked by only six degrees of separation. It really works, for code and for trusted social relations (like "I lend you 100 bucks and you pay me them back when you get your salary") mostly when you know the code author in person.
This is also not a new insight. In the beginning of the naughties, there was a web site named kuro5hin.org, which experiemented with user ratings and trust networks. It turned out impossible to prevent take-overs.
This is also not a new insight. In the beginning of the naughties, there was a web site named kuro5hin.org, which experiemented with user ratings and trust networks. It turned out impossible to prevent take-overs.
IIRC, kuro5hin and others all left out a crucial step in the web-of-trust approach: There were absolutely no repercussions when you extended trust to somebody who later turned out to be a bad actor.
It considers trust to be an individual metric instead of leaning more into the graph.
(There are other issues, e.g. the fact that "trust" isn't a universal metric either, but context dependent. There are folks whom you'd absolutely trust to e.g. do great & reliable work in a security context, but you'd still not hand them the keys to your car)
At least kuro5hin modeled a degradation of trust over time, which most models still skip.
It'd be a useful thing, but we have a long way to go before there's a working version.
It considers trust to be an individual metric instead of leaning more into the graph.
(There are other issues, e.g. the fact that "trust" isn't a universal metric either, but context dependent. There are folks whom you'd absolutely trust to e.g. do great & reliable work in a security context, but you'd still not hand them the keys to your car)
At least kuro5hin modeled a degradation of trust over time, which most models still skip.
It'd be a useful thing, but we have a long way to go before there's a working version.
Once you add punishment for handing out trust to bad actors, even in good faith (which you can't prove/disprove anyway), then you also need to somehow provide siginificant rewardsf for handing out trust to good actors - otherwise everyone is going to play it safe and not vouch for anyone and your system becomes useless.
There were experiments back in the day. Slashdot had one system based on randomly assigned moderation duty which worked pretty great actually, except that for the longest time you couldn't sort by it.
Kuro5hin had a system which didn't work at all, as you mentioned.
But the best was probably Raph Levien's Advogato. That had a web of trust system which actually worked. But had a pretty limited scope (open source devs).
Now everyone just slaps an upvote/downvote button on and calls it a day.
Kuro5hin had a system which didn't work at all, as you mentioned.
But the best was probably Raph Levien's Advogato. That had a web of trust system which actually worked. But had a pretty limited scope (open source devs).
Now everyone just slaps an upvote/downvote button on and calls it a day.
State actors have equaly long horizons to compromise
More likely that the account of that dev was breawched, dont you think ?
(I detached this subthread from https://news.ycombinator.com/item?id=39866275, for the sake of pruning the top heavy thread.)
https://github.com/tukaani-project/tukaani-project.github.io... Does this mean anything that it changed to a parameter??
no. unlikely.
看起来后门作者之一甚至禁用了该漏洞直接依赖于 oss-fuzz 的功能，以防止意外发现：https://social.treehouse.systems/@Aissen/112180302735030319
https://github.com/google/oss-fuzz/pull/10667
但幸运的是，有一些意外的发现：“我在对 postgres 更改进行基准测试时意外发现了一个安全问题。” https://mastodon.social/@AndresFreundTec/112180083704606941
https://github.com/google/oss-fuzz/pull/10667
但幸运的是，有一些意外的发现：“我在对 postgres 更改进行基准测试时意外发现了一个安全问题。” https://mastodon.social/@AndresFreundTec/112180083704606941
这个问题在这里得到解决：https://github.com/google/oss-fuzz/issues/11760
[deleted]
and that was in mid 2023. Very funny that Wikipedia on this issue says
> It is unknown whether this backdoor was intentionally placed by a maintainer or whether a maintainer was compromised
Yeah, if you've been compromised for a year your attacker is now your identity. Can't just wave hands, practice infosec hygiene
> It is unknown whether this backdoor was intentionally placed by a maintainer or whether a maintainer was compromised
Yeah, if you've been compromised for a year your attacker is now your identity. Can't just wave hands, practice infosec hygiene
Anyone keeping current with OpenSUSE Tumbleweed got a update...downgrade. Prior to `zypper dup --no-allow-vendor-change` I had 5.6.0, now I'm at 5.4.6.
I see `5.6.1.revertto5.4-3.2`
The backdoor is not in the C source directly, but a build script uses data from files in the test dir to only create the backdoor in the release tars. Did I summarize that correctly?
That's how I understand it. A build script that's in the releases tarballs but not the git repo, checks to see if it's being run as part of the debian/build or rpm build processes, and then injects content from one of the "test" files.
I could imagine another similar attack done against an image processing library, include some "test data" of corrupted images that should "clean up" (and have it actually work!) but the corruption data itself is code to be run elsewhere.
This is why the less the better... even if it means less comfortable... to a certain point obviously. And that includes SDKs...
I don't understand why you were downvoted. Having fewer moving parts does make it easier to catch issues.
Everything which is not engaging in licking Big Tech balls (open source or not) on HN is served with severe downvoting, that most of the time (probably real trash human beings or AI trolls with headless blink/geeko|webkit).
I am not embarrassed to say... is there anything in there that someone who runs a server with ssh needs to know?
I literally can't make heads or tails of the risk here. All I see is the very alarming and scary words "backdoor" and "ssh server" in the same sentence.
If I am keeping stuff up to date, is there anything at all to worry about?
I literally can't make heads or tails of the risk here. All I see is the very alarming and scary words "backdoor" and "ssh server" in the same sentence.
If I am keeping stuff up to date, is there anything at all to worry about?
You should probably not be running your own publicly-accessible ssh servers if this email is not sufficient to at least start figuring out what your next actions are.
The email itself comes with an evaluation script to figure out if anything is currently vulnerable to specifically this discovery. For affected distributions, openssh servers may have been backdoored for at least the past month.
The email itself comes with an evaluation script to figure out if anything is currently vulnerable to specifically this discovery. For affected distributions, openssh servers may have been backdoored for at least the past month.
Yet here I am, getting up every morning and getting dressed and tying my shoes all by myself, and then maintaining a small number of servers that have openssh on them!
Thanks, though, for pointing out the little script at the very end of that technical gauntlet of an email intended for specialists. I had gotten through the first 3 or 4 paragraphs and had given up.
What I should have done is just googled CVE-2024-3094, whatever, still glad I asked.
Thanks, though, for pointing out the little script at the very end of that technical gauntlet of an email intended for specialists. I had gotten through the first 3 or 4 paragraphs and had given up.
What I should have done is just googled CVE-2024-3094, whatever, still glad I asked.
> You should probably not be running your own publicly-accessible ssh servers if this email is not sufficient to at least start figuring out what your next actions are.
That seems like a fairly unreasonable stance.
That seems like a fairly unreasonable stance.
Not at all. For instance, I don't know what the next steps are, but I run SSH servers behind Wireguard, exactly to prevent them being accessible in the case of such events. Wireguard is simple to setup, even if I lack the expertise to understand exactly how to go forward.
> 我真的无法弄清楚这里的风险。我所看到的只是同一个句子中非常令人震惊和可怕的单词“后门”和“ssh 服务器”。
据我所知，问题的范围仍然存在很多未知数。迄今为止发现的情况表明它涉及绕过 SSH 中的身份验证。
在 https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b... 中，Sam James 指出
> 如果此有效负载加载到 openssh sshd 中，RSA_public_decrypt 函数将被重定向到恶意实现。我们观察到这种恶意实现可用于绕过身份验证。正在进行进一步的研究来解释原因。
因此，攻击者可能可以使用它来连接到易受攻击的服务器，而根本不需要进行身份验证。
据我所知，问题的范围仍然存在很多未知数。迄今为止发现的情况表明它涉及绕过 SSH 中的身份验证。
在 https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b... 中，Sam James 指出
> 如果此有效负载加载到 openssh sshd 中，RSA_public_decrypt 函数将被重定向到恶意实现。我们观察到这种恶意实现可用于绕过身份验证。正在进行进一步的研究来解释原因。
因此，攻击者可能可以使用它来连接到易受攻击的服务器，而根本不需要进行身份验证。
Thanks, that gist is a really lucid explanation for normal folks.
So much for a quiet Easter holiday. Fuck
It seems like based on the (very well written) analysis that this is a way to bypass ssh auth, not something that phones out which would've been even scarier.
My server runs arch w/ a LTS kernel (which sounds dumb on the surface, but was by far the easiest way to do ZFS on Linux that wasn't Ubuntu) and it seems that since I don't have SSH exposed to the outside internet for good reason, and my understanding is Arch never patched shhd to begin with that I and most people who would be in similar situations to me are unaffected.
Still insane that this happened to begin with, and I feel bad for the Archlinux maintainers who are now going to feel more pressure to try to catch things like this.
My server runs arch w/ a LTS kernel (which sounds dumb on the surface, but was by far the easiest way to do ZFS on Linux that wasn't Ubuntu) and it seems that since I don't have SSH exposed to the outside internet for good reason, and my understanding is Arch never patched shhd to begin with that I and most people who would be in similar situations to me are unaffected.
Still insane that this happened to begin with, and I feel bad for the Archlinux maintainers who are now going to feel more pressure to try to catch things like this.
Being included via libsystemd isn't the only way ssh can load liblzma, it can come as an indirect dependency of Selinux (and its PAM stack) IIUC. Which makes it even a bit more funny (?) since Arch also doesn't officially support any Selinux stuff.
There might be other ways sshd might pull in lzma, but those are the 2 ways I saw commonly mentioned.
On a different note, pacman/makepkg got the ability to checksum source repository checkouts in 6.1.
There might be other ways sshd might pull in lzma, but those are the 2 ways I saw commonly mentioned.
On a different note, pacman/makepkg got the ability to checksum source repository checkouts in 6.1.
xz is just a horribly designed format, and always has been. If you use it, please switch to Lzip. Same compression level, but designed by someone competent.
https://www.nongnu.org/lzip/
https://www.nongnu.org/lzip/xz_inadequate.html
https://www.nongnu.org/lzip/
https://www.nongnu.org/lzip/xz_inadequate.html
Thanks for that link, lzip sounds useful
Someone competent? More like a drama queen butthurt that his pet project did not win the popularity contest. Not the kind of person I want to rely on for important tools.
Be an asshole elsewhere. This makes me LESS want to use lzip because of such aggressive non-useful slander and just plain nonsense.
Funny how Lasse Collin started to ccing himself and Jia Tan from 2024-03-20 (that was a day of tons of xz kernel patches), he never did that before. :)
https://lore.kernel.org/lkml/20240320183846.19475-2-lasse.co...
https://lore.kernel.org/lkml/20240320183846.19475-2-lasse.co...
Also interesting, to me, how the GMail account for the backdoor contributor ONLY appears in the context of "XZ" discussions. Google their email address. Suggests a kind of focus, to me, and a lack of reality / genuineness.
This also means that Google might know who they are, unless they were careful to hide behind VPN or other such means.
This is extremely suspicious.
It looks like someone may have noticed a unmaintained or lightly maintained project related to various things, and moved to take control of it.
Otherwhere in the discussion here someone mentions the domain details changed; if you have control of the domain you have control of all emails associated with it.
It looks like someone may have noticed a unmaintained or lightly maintained project related to various things, and moved to take control of it.
Otherwhere in the discussion here someone mentions the domain details changed; if you have control of the domain you have control of all emails associated with it.
[deleted]
those pipe usages are quite suspicious
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...
pipeing into this shell script which now uses "eval"
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...
i guess this will be revisited and removed soon
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...
pipeing into this shell script which now uses "eval"
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-n...
i guess this will be revisited and removed soon
> pipeing into this shell script which now uses "eval"
I don’t actually see an issue with that `eval`. Why would one consider running `xz` followed by `eval`-ing its output more insecure than just running `xz`? If `xz` wants to do shenanigans with the privileges it already has, then it wouldn’t need `eval`’s help for that.
I don’t actually see an issue with that `eval`. Why would one consider running `xz` followed by `eval`-ing its output more insecure than just running `xz`? If `xz` wants to do shenanigans with the privileges it already has, then it wouldn’t need `eval`’s help for that.
just take a closer look at the analysis https://www.openwall.com/lists/oss-security/2024/03/29/4
then try to understand the pattern. they backdoored by modifying the build process of packages. now consider the $XZ is also from a backdoored build and the call recognizes in the same way with parameters --robot --version and the shell environment with the hint "xz_wrap.sh" from the piped process. a lot stuff to recognize for the $XZ process that it run as part of a kernel build.
Maybe they put advanced stuff in a backdoored $XZ binary to modify the kernel in a similar way they modified lzma based packages in the build process.
then try to understand the pattern. they backdoored by modifying the build process of packages. now consider the $XZ is also from a backdoored build and the call recognizes in the same way with parameters --robot --version and the shell environment with the hint "xz_wrap.sh" from the piped process. a lot stuff to recognize for the $XZ process that it run as part of a kernel build.
Maybe they put advanced stuff in a backdoored $XZ binary to modify the kernel in a similar way they modified lzma based packages in the build process.
because in order to put backdoor into xz executable, you need to infect its sources. and in order to infect the sources, you need to use a similar technique to hide the modification
"started to cc himself" seems to be simply "contributing to a new project and not having git-send-email fully set up". By default git-send-email Cc the sender, though in practice it's one of the first options one changes.
Time for another OS wipe. Glad I keep bleeding edge versions VMd
Mirror of the report, since the Openwall servers appear to be down.
https://web.archive.org/web/20240329182300/https://www.openw...
https://web.archive.org/web/20240329182300/https://www.openw...
[deleted]
Keeps one wonder how many similar backdoors are there in the wild. What is the best way to execute such a move? This is sophisticated enough, but not good enough to stay unnoticed for a long while. If I were a state actor I'd think about at least 6-12 months.
Really disappointed in the number of posters here who are playing down rushing to judgement and suggesting perhaps a legitimate developer was compromised, when it's very clear this is sophisticated and not the work of a single person.
I'm recalling bad memories of the Juniper backdoor years ago.
Whoever did this, was playing the long game. As the top post pointed out, there was an effort to get this into Fedora.... which eventually makes its way into RHEL (read: high value targets). This was not for short term payoffs by some rogue developer trying to mine crypto or other such nonsense. What you are seeing here is the planting of seeds for something months or a year down the road.
I'm recalling bad memories of the Juniper backdoor years ago.
Whoever did this, was playing the long game. As the top post pointed out, there was an effort to get this into Fedora.... which eventually makes its way into RHEL (read: high value targets). This was not for short term payoffs by some rogue developer trying to mine crypto or other such nonsense. What you are seeing here is the planting of seeds for something months or a year down the road.
Oof, this is on my Sid laptop:
{0}[calvinow@mozart ~] dpkg-query -W liblzma5
liblzma5:amd64 5.6.0-0.2
{0}[calvinow@mozart ~] hexdump -ve '1/1 "%.2x"' /lib/x86_64-linux-gnu/liblzma.so.5 | grep -c f30f1efa554889f54c89ce5389fb81e7000000804883ec28488954241848894c2410
1
No obvious need to reinstall if you didn't use ssh and expose it publicly and are not a politically important person. All signs suggest that it was a nation state attack, and you are likely not a target.
我们将拭目以待......鉴于 sshd 只是它可能选择的 argv[0] 之一，在完全分析之前，我还是有点疑神疑鬼。重装只需半小时，反正我还有些节目要赶:)
I was thinking about reinstalling, because I'm on Manjaro Linux, which has the version in question.
But it's unclear if earlier versions are also vulnerable.
And if it did nasty things to your machine, how do you make sure that the backups you have do not include ways for the backdoor to reinstate itself?
But it's unclear if earlier versions are also vulnerable.
And if it did nasty things to your machine, how do you make sure that the backups you have do not include ways for the backdoor to reinstate itself?
Sure, the backdoor could have e.g. injected an libav exploit into a video file to re-backdoor my system when I watch it... that's too paranoid for me.
I don't backup the whole system, just a specific list of things in /home.
I don't backup the whole system, just a specific list of things in /home.
The best part is everyone disabling security tests that started failing
Everybody here In jumping into the pure malice bandwagon, I have a better hypothesis.
Abandonment and inaction, the actual developers of these tools are elsewhere, oblivious to this drama, trying to make living because most of the time you are not compensated nor any corporation cares about making things sustainable at all. This is the default status of everything your fancy cloud depends on underneath.
An attacker took over of the project slowly and stayed dormant until recently.
Abandonment and inaction, the actual developers of these tools are elsewhere, oblivious to this drama, trying to make living because most of the time you are not compensated nor any corporation cares about making things sustainable at all. This is the default status of everything your fancy cloud depends on underneath.
An attacker took over of the project slowly and stayed dormant until recently.
Except that doesn't match reality.
Someone has worked on xz for several years. Are you saying that this somewhat active contributor was likely actively contributing, then all of a sudden stopped, also stopped paying attention, and also allowed their account to be compromised or otherwise handed it over to a nefarious party?
That fails the sniff test.
Someone has worked on xz for several years. Are you saying that this somewhat active contributor was likely actively contributing, then all of a sudden stopped, also stopped paying attention, and also allowed their account to be compromised or otherwise handed it over to a nefarious party?
That fails the sniff test.
See, people drop dead from OSS projects pretty frecuently, usually because they take on other life responsabilities and there is no cushion or guard against a bus factor.
Then it is very easy to get credentials compromised or have your project took over by someone else.
funding model of OSS work is obviously a problem, but these problems are deeper than that. even a very well compensated OSS developer can get a knock on the door from a government agency (or anyone with a "$5 wrench")[1] and they might feel "compelled" to give up their maintainer creds.
[1]: https://xkcd.com/538/
[1]: https://xkcd.com/538/
Well, yeah. The attacker, operating largely under the name Jia Tan, has successfully manipulated the original author (Lasse Collin) to become a maintainer.
The attacker indeed laid dormant for two years, pretending to just be maintaining xz.
I really don't see any way how this wasn't malice on Jia's part. But I do think your hypothesis applies to Lasse, who was just happy someone could help him maintain xz.
The attacker indeed laid dormant for two years, pretending to just be maintaining xz.
I really don't see any way how this wasn't malice on Jia's part. But I do think your hypothesis applies to Lasse, who was just happy someone could help him maintain xz.
"Amazon Linux customers are not affected by this issue, and no action is required. AWS infrastructure and services do not utilize the affected software and are not impacted. Users of Bottlerocket are not affected."
https://aws.amazon.com/security/security-bulletins/AWS-2024-...
https://aws.amazon.com/security/security-bulletins/AWS-2024-...
Github should probably remove the dopamine hits of green checkmarks etc. like in serious stock broker apps
They should also remove the emojis, there is no need to have people feel good about upvotes. I've long felt uncomfortable with emojis on Slack as well. Responding to a coding or infrastructure issue should not be a social activity, I respond because it's my job and if the issue is worth it, not because a human being should feel appreciated (either them or me).
Many people write code for fun and slack is a social communications platform.
If you can't imagine people using these tools for other reasons than pure unemotional business value then you don't understand their market.
Your suggestions would lose those platforms users and revenue.
If you can't imagine people using these tools for other reasons than pure unemotional business value then you don't understand their market.
Your suggestions would lose those platforms users and revenue.
The emojis reduce (but not eliminate) the number of "me too!"s PRs will get, which IMO is a good thing.
That only requires a vote button, not a whole range of cringe cartoon images.
Candidly how would someone protect against a vulnerability like this?
Compile all your packages from source would be a start.
You’re not wrong. However, building from source wouldn’t have protected you against this specific backdoor. The upstream source tarball itself was compromised in a cleverly sneaky way.
您可以阅读 https://www.openwall.com/lists/oss-security/2024/03/29/4
“但是，从源代码构建并不能保护您免受这种特定后门的侵害。”
取决于您如何从源代码构建。通用构建不是目标。 Andres Freund 表明该攻击针对特定类型的构建系统。
“但是，从源代码构建并不能保护您免受这种特定后门的侵害。”
取决于您如何从源代码构建。通用构建不是目标。 Andres Freund 表明该攻击针对特定类型的构建系统。
[deleted]
Build from source AND run an Ai agent that reviews every single line of code you compile (while hoping that the any potential exploit doesn’t also fool / exploit your AI agent)
Jesus! Does anyone know if Debian stable is affected?
It's not. Neither Ubuntu.
Do you have a source my friend? I thought Ubuntu was built off of Debian testing or unstable
The latest version in 23.10 is 5.4.1-0.2
https://packages.ubuntu.com/mantic/liblzma5
And in unreleased 24.04 is 5.4.5-0.3
https://packages.ubuntu.com/noble/liblzma5
There are no changelog entries indicating that the package was reverted.
https://packages.ubuntu.com/mantic/liblzma5
And in unreleased 24.04 is 5.4.5-0.3
https://packages.ubuntu.com/noble/liblzma5
There are no changelog entries indicating that the package was reverted.
[deleted]
The stable releases don't have this particular backdoor, but they're still using older versions of the library that were released by the same bad actor.
我查看了 GitHub 存储库和已发布的包之间的差异。发布包中约有 60 个文件不在存储库中（大多数是用于构建的生成文件），但也有一些 .po 文件发生了更改。
那是毁灭性的。
如果您不通过将“git ls-files”输入 tar 来构建发布包，那么您就做错了。
那是毁灭性的。
如果您不通过将“git ls-files”输入 tar 来构建发布包，那么您就做错了。
Why not `git archive`?
Because I didn't know about it.
Although if I look at its documentation, it's already a somewhat complicate invocation with unclear effects (lots of commandline options). Git seems to not be able to do KISS.
git ls-files and tar is a simple thing everybody understands and can do without much issues.
Although if I look at its documentation, it's already a somewhat complicate invocation with unclear effects (lots of commandline options). Git seems to not be able to do KISS.
git ls-files and tar is a simple thing everybody understands and can do without much issues.
I think this is unfortunately very common practice
Jai Tan's commit history on his github profile suggests he took off for Christmas, new years, and spring break. I smell an American.
Interesting. Is there also a pattern in the times of day? (I don't so much mean the times in commits done by the developer because they can be fake. I'd be more interested in authentic times recorded by GitHub, if any such times are publicly accessible.)
Another thing would be to examine everything ever written by the user for linguistic clues. This might point towards particular native languages or a particular variant of English or towards there being several different authors.
Another thing would be to examine everything ever written by the user for linguistic clues. This might point towards particular native languages or a particular variant of English or towards there being several different authors.
Someone said commits lined up with Beijing time, but I've not verified that.
But that wouldn't count for much, someone employed by anyone could work any hours.
But that wouldn't count for much, someone employed by anyone could work any hours.
而且 git 实际上存储了时区信息。您可以看到始终是中国时间 (GMT+8)。
附：可能是台湾人，因为中国和台湾共享同一时区。
下面是 git 邮箱文件的链接，您可以在其中查看时区。
从 2022 年起：
- https://github.com/tukaani-project/xz/commit/c6977e740008817...
- https://github.com/tukaani-project/xz/commit/7c16e312cb2f40b...
从 2024 年起：
- https://github.com/tukaani-project/xz/commit/af071ef7702debe...
- https://github.com/tukaani-project/xz/commit/a4f2e20d8466369...
附：可能是台湾人，因为中国和台湾共享同一时区。
下面是 git 邮箱文件的链接，您可以在其中查看时区。
从 2022 年起：
- https://github.com/tukaani-project/xz/commit/c6977e740008817...
- https://github.com/tukaani-project/xz/commit/7c16e312cb2f40b...
从 2024 年起：
- https://github.com/tukaani-project/xz/commit/af071ef7702debe...
- https://github.com/tukaani-project/xz/commit/a4f2e20d8466369...
Maybe it's a Western Australian, or Indonesian, or Thai...
GMT+8 covers a lot of places
GMT+8 covers a lot of places
That timezone information is provided by whoever created the commits so cannot be trusted to be correct. Considering the chosen alias it's not unexpected that the timezone information was also made to look Chinese.
So could be the holiday inactivity. I'd expect multiple layers of country obfuscation as well as conflicting information to confuse you. Or none. Impossible to know for sure.
So could be the holiday inactivity. I'd expect multiple layers of country obfuscation as well as conflicting information to confuse you. Or none. Impossible to know for sure.
Sometimes you smell an American because someone wanted you to smell an American.
Operating on a target region schedule doesn't seem particularly sophisticated, at least compared to the all the efforts put into this exploit.
Operating on a target region schedule doesn't seem particularly sophisticated, at least compared to the all the efforts put into this exploit.
[deleted]
[deleted]
Another interesting data point: about 2 years ago there was a clear pressure campaign to name a new maintainer: https://www.mail-archive.com/[email protected]/msg00566.h...
At the time I thought it was just rude, but maybe this is when it all started.
At the time I thought it was just rude, but maybe this is when it all started.
How many people are involved in this ?
Could be just a single person with a bunch of identities.
I would put money on government hackers. They're the sort of people that have the time to pull something like this off. Frankly I'm really surprised it isn't more common, though maybe it is and these guys were just super blatant. I would have expected more plausible deniability.
Good cop bad cop play maybe.
"Jigar Kumar" seems to have disappeared
true, that is suspicious as well. A person that hasn't even created any bugs or issues suddenly has a big problem with the speed of development? Especially the way this was phrased: "You ignore the many
patches bit rotting away on this mailing list. Right now you choke your repo.
Why wait until 5.4.0 to change maintainer? Why delay what your repo needs?"
"Why delay what your repo needs?" This sounds like scammer lingo
"Why delay what your repo needs?" This sounds like scammer lingo
Wow, people suck. I almost hope it's fake profiles urging the maintainer to take on a new member as a long con. Because I sincerely hope Jigar Kumar is not a real person behaving like that towards volunteers working for free.
[deleted]
Has this affected OpenBSD at all?
Seems the backdoor relied on Debian and others patching their copies of openssh to support systemd notifications, and this would obviously not be the case on OpenBSD.
To be sure the current ports version of xz is 5.4.5: https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/a...
Although the maintainer was working on updating to 5.6.1, but this news broke before the diff was landed: https://marc.info/?l=openbsd-ports&m=171174441521894&w=2
To be sure the current ports version of xz is 5.4.5: https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/a...
Although the maintainer was working on updating to 5.6.1, but this news broke before the diff was landed: https://marc.info/?l=openbsd-ports&m=171174441521894&w=2
I think its much more likely this was not a bad actor, given their long history of commits.
It's a known fact that China will "recruit" people to operate them. A quote:
> They talk to them, say my friend, I see you like our special menu. Are you from China? Are you here on a VISA? Do you have family back there? Would you like your family to stay alive? Is your loyalty to this temporary employer or is your loyalty to your motherland? You know, a whole bunch of stuff like that. That’s how Chinese intelligence operations acts...
This just gives feelings of less "compromised account" and more "Your account is now our account"
It's a known fact that China will "recruit" people to operate them. A quote:
> They talk to them, say my friend, I see you like our special menu. Are you from China? Are you here on a VISA? Do you have family back there? Would you like your family to stay alive? Is your loyalty to this temporary employer or is your loyalty to your motherland? You know, a whole bunch of stuff like that. That’s how Chinese intelligence operations acts...
This just gives feelings of less "compromised account" and more "Your account is now our account"
Isn't that still a "bad actor" even if they are coerced into it?
Yes.
[deleted]
For the purposes of security discussions, I would say yes. You often don't know their real identity let alone their motivations and tribulations.
However if we were critiquing characters in a book-- especially ones where narrative voice tells us exactly their true motivations--then maybe not, and they get framed as a "dupe" or "manipulated" etc.
However if we were critiquing characters in a book-- especially ones where narrative voice tells us exactly their true motivations--then maybe not, and they get framed as a "dupe" or "manipulated" etc.
"bad actor" doesn't mean "bad faith", it's not a value judgement
I believe your parent is trying to make a distinction that the handle's history may not be suspect, only recent activity, positing a rubber-hose type compromise.
I think we should seriously consider something like a ts clearance as mandatory for work on core technologies. Many other projects, both open and closed, are probably compromised by foreign agents.
That's hard to do when the development of these libraries is so international. Not to mention that it's already so hard to find maintainers for some of these projects. Given that getting a TS clearance is such a long and difficult process, it would almost guarantee more difficulty in finding people to do this thankless job.
It doesn't need to be TS for open source(but for closed, I'm leaning yes). But all code for these core technologies need to be tied to a real person that can be charged in western nations. Yes, it will make it harder to get people, but with how important these technologies are, we really should not be using some random guys code in the kernel.
Don't forget that the NSA bribed RSA (the company) to insert a backdoor into their RNG. Being in western jurisdiction doesn't mean you won't insert backdoors into code. It just changes whom you will target with these backdoors. But they all equally make our technology less trustworthy so they are all equally despicable.
It will significantly cut down on Russian and Chinese back doors, which is still an improvement, Mr. Just Made an Account.
That just means the bad actors will all have clearance while putting in a bunch of hurdles for amateur contributors. The only answer is the hard one, constant improvement in methods to detect and mitigate bugs.
"Constant improvement" sounds like "constantly playing catch-up". Besides that, someone with TS can be arrested and charged, and I don't want amateur contributors.
>and I don't want amateur contributors.
And you're free to not accept amateur contributions to the OS projects you maintain. Hell, you can require security clearance for your contributors right now, if you want.
And you're free to not accept amateur contributions to the OS projects you maintain. Hell, you can require security clearance for your contributors right now, if you want.
Software like that already exists. I'm saying open source should do better.
> I think we should seriously consider something like a ts clearance as mandatory for work on core technologies.
Was xz/lzma a core technology when it was created? Is my tiny "constant time equality" Rust crate a core technology? Even though it's used by the BLAKE3 crate? By the way, is the BLAKE3 crate a core technology? Will it ever become a core technology?
With free software in general, things do not start a "core technology"; they become a "core technology" over time due to usage. At which point would a maintainer have to get a TS clearance? Would the equivalent of a TS clearance from my Latin America country be acceptable? And how would I obtain it? Is it even available to people outside the military and government (legit question, I never looked)?
Was xz/lzma a core technology when it was created? Is my tiny "constant time equality" Rust crate a core technology? Even though it's used by the BLAKE3 crate? By the way, is the BLAKE3 crate a core technology? Will it ever become a core technology?
With free software in general, things do not start a "core technology"; they become a "core technology" over time due to usage. At which point would a maintainer have to get a TS clearance? Would the equivalent of a TS clearance from my Latin America country be acceptable? And how would I obtain it? Is it even available to people outside the military and government (legit question, I never looked)?
We probably shouldn't use your code at all, is the real answer. You can get TS, it just costs a lot of money.
In United States, you cannot apply for a clearance. You must get a job that requires a clearance, then start application process and wait.
Who is "we"? Are you from the US by any chance? Do you mean that the US government should rewrite every piece of core architecture (including Linux, Ssh, Nginx...) from scratch? Because they are all "contaminated" and actually were created by non-americans.
If that's the case, you do you. Do you also think that all other countries should do the same, and rewrite everything from scratch for their government use (without foreign, for example American, influence)? And what about companies? Should they be forced to switch to their government's "safe" software, or can they keep using Linux and ssh? What about multi-national companies? And what even counts as a "core" software?
So yeah, I don't think it's a good idea.
If that's the case, you do you. Do you also think that all other countries should do the same, and rewrite everything from scratch for their government use (without foreign, for example American, influence)? And what about companies? Should they be forced to switch to their government's "safe" software, or can they keep using Linux and ssh? What about multi-national companies? And what even counts as a "core" software?
So yeah, I don't think it's a good idea.
We can keep it between NATO plus friends.
Wow, I can't decide which is the bigger act of sabotage to open source, your ideas or the actual backdoor.
The Linux kernel is complaining about a lack of funding for CI-one of the highest visibility projects out there. Where will the money come from for this?
Corps? Aside from Intel most of them barely pay to upstream their drivers.
The govt? The US federal government cut so much of it's support since the 70s and 80s.
Corps? Aside from Intel most of them barely pay to upstream their drivers.
The govt? The US federal government cut so much of it's support since the 70s and 80s.
You're right, but accepting code from random Gmail accounts can't be the solution. Honestly the Linux kernel is a bloated mess, and will probably never be secured.
Accepting code from any source without properly reviewing it is surely the actual problem, no? This person only infiltrated this project because there was no proper oversight.
Maintainers need to be more stringent and vigilant of the code they ship, and core projects that many other projects depend upon should receive better support, financial and otherwise, from users, open source funds and companies alike. This is a fragile ecosystem that this person managed to exploit, and they likely weren't the only one.
Maintainers need to be more stringent and vigilant of the code they ship, and core projects that many other projects depend upon should receive better support, financial and otherwise, from users, open source funds and companies alike. This is a fragile ecosystem that this person managed to exploit, and they likely weren't the only one.
Maintainers can't fully review all code that comes in. They don't have the resources. Even if they could give it a good review, a good programmer could probably still sneak stuff in. That's assuming a maintainer wasn't compromised, like in this case. We need a certain level of trust that the contributors are not malicious.
Definitely this.
I’ve been a package maintainer for a decade. I make it a habit to spot check the source code of every update of every upstream package, hoping that if many others do the same, it might make a difference.
But this backdoor? I wouldn’t have been able to spot it to save my life.
I’ve been a package maintainer for a decade. I make it a habit to spot check the source code of every update of every upstream package, hoping that if many others do the same, it might make a difference.
But this backdoor? I wouldn’t have been able to spot it to save my life.
This wasn't caused by not reviewing the code of a dependency. This was a core maintainer of xz, who gradually gained trust and control of the project, and was then able to merge changes with little oversight. The failure was in the maintenance of xz, which would of course be much more difficult to catch in dependent projects. Which is why it's so impressive that it was spotted by an OpenSSH user. Not even OpenSSH maintainers noticed this, which points to a failure in their processes as well, to a lesser degree.
I do agree that it's unreasonable to review the code of the entire dependency tree, but reviewing own code thoroughly and direct dependencies casually should be the bare minimum we should expect maintainers to do.
I do agree that it's unreasonable to review the code of the entire dependency tree, but reviewing own code thoroughly and direct dependencies casually should be the bare minimum we should expect maintainers to do.
> Not even OpenSSH maintainers noticed this, which points to a failure in their processes as well, to a lesser degree.
The OpenSSH project has nothing to do with xz. The transitive dependency on liblzma was introduced by a patch written by a third party. [1] You can't hold OpenSSH project members accountable for something like this.
[1]: https://bugs.debian.org/778913
The OpenSSH project has nothing to do with xz. The transitive dependency on liblzma was introduced by a patch written by a third party. [1] You can't hold OpenSSH project members accountable for something like this.
[1]: https://bugs.debian.org/778913
Alright, that's fair. But I mentioned them as an example. Surely liblzma is a dependency in many projects, and _none_ of them noticed anything strange, until an end user did?
This is a tragedy of the commons, and we can't place blame on a single project besides xz itself, yet we can all share part of the blame to collectively do better in the future.
This is a tragedy of the commons, and we can't place blame on a single project besides xz itself, yet we can all share part of the blame to collectively do better in the future.
One of the primary responsibilities of a maintainer is to ensure the security of the software. If they can't keep up with the pace of development in order to ensure this for their users, then this should be made clear to the community, and a decision should be made about how to proceed. Open source maintenance is an often stressful and thankless role, but this is part of the problem that allowed this to happen. Sure, a sophisticated attacker would be able to fool the eyes of a single tired maintainer, but the chances of that happening are much smaller if there's a stringent high bar of minimum quality, and at least one maintainer understands the code that is being merged in. Change proposals should never be blindly approved, regardless of who they come from.
At the end of the day we have to be able to answer why this happened, and how we can prevent it from happening again. It's not about pointing fingers, but about improving the process.
BTW, there have been several attempts at introducing backdoors in the Linux kernel. Some manage to go through, and perhaps we don't know about others, but many were thwarted due to the extreme vigilance of maintainers. Thankfully so, as everyone is well aware of how critical the project is. I'm not saying that all projects have the resources and visibility of Linux, but clearly vigilance is a requirement for lowering the chances of this happening.
> That's assuming a maintainer wasn't compromised, like in this case.
What makes you say that? Everything I've read about this (e.g. [1]) suggests that this was done by someone who also made valid contributions and gained gradual control of the project, where they were allowed to bypass any checks, if they existed at all. The misplaced trust in external contributions, and the lack of a proper peer review process are precisely what allowed this to happen.
[1]: https://boehs.org/node/everything-i-know-about-the-xz-backdo...
At the end of the day we have to be able to answer why this happened, and how we can prevent it from happening again. It's not about pointing fingers, but about improving the process.
BTW, there have been several attempts at introducing backdoors in the Linux kernel. Some manage to go through, and perhaps we don't know about others, but many were thwarted due to the extreme vigilance of maintainers. Thankfully so, as everyone is well aware of how critical the project is. I'm not saying that all projects have the resources and visibility of Linux, but clearly vigilance is a requirement for lowering the chances of this happening.
> That's assuming a maintainer wasn't compromised, like in this case.
What makes you say that? Everything I've read about this (e.g. [1]) suggests that this was done by someone who also made valid contributions and gained gradual control of the project, where they were allowed to bypass any checks, if they existed at all. The misplaced trust in external contributions, and the lack of a proper peer review process are precisely what allowed this to happen.
[1]: https://boehs.org/node/everything-i-know-about-the-xz-backdo...
My understanding is that the attacker was the only maintainer of xz, that was trusted by upstream maintainers. They couldn't realistically check his work. The defence against this can't be "do better, volunteer maintainers". Maybe we could have better automated testing and analysis, but OSS is allergic to those.
当然，我并不是说这是唯一的解决方案，或者说它是万无一失的。但这应该给 OSS 社区中的每个人敲响警钟，让他们做得更好。
最终只有一个维护者的项目应该引起一些注意，并且根据其重要性，应该提供帮助和资源。我们都看过 xkcd，并发现它更有趣而不是可怕。
提高认识的一个想法是：提供一项服务，扫描 GitHub 和其他地方的项目，并根据各种因素分配维护分数。总线因素应该是主要因素。制作记分板、徽章，将其集成到包管理器和 IDE 等中。如果 GitHub 像他们声称的那样关心 OSS，那么 GitHub 本身将是实现这一目标的理想公司。
最终只有一个维护者的项目应该引起一些注意，并且根据其重要性，应该提供帮助和资源。我们都看过 xkcd，并发现它更有趣而不是可怕。
提高认识的一个想法是：提供一项服务，扫描 GitHub 和其他地方的项目，并根据各种因素分配维护分数。总线因素应该是主要因素。制作记分板、徽章，将其集成到包管理器和 IDE 等中。如果 GitHub 像他们声称的那样关心 OSS，那么 GitHub 本身将是实现这一目标的理想公司。
Okay, so instead of one random Gmail account taking over a critical project, we need two or three?
This only ensures the backdoors are coming from governments that issued the clearances, nothing more. I prefer more competition, at least there is incentive to detect those issues.
It will ensure that my OS doesn't have code from random Gmail accounts. If someone with U.S clearance submits a backdoor, they should either be charged in the U.S, or extradited to somewhere that will charge them. We have no idea who this person is, and even if we did we probably could not hold them accountable.
This seems infeasible for projects like LLVM that depend on international collaboration.
That's a very US centric view and would practically split the open source community along the atlantic at best and fracture it globally at worst. Be careful what you wish for.
how many people in PRISM had such clearance? and how many of them would i trust? precisely zero.
Killing your pipeline for innovation and talent development doesn't make you secure, it makes you fall behind. The Soviet Union found this out the hard way when they made a policy decision to steal chip technology instead of investing in their own people. They were outpaced and the world came to use chips, networks, and software designed by Americans.
That's the exact opposite of what I'm saying we do. We need to invest in engineers we can trust, and cut off those we can't.
我们是谁？美国人？当然，这对你来说很好，但美国人在美国之外也并不完全值得信任，我是作为一个通常支持美国的人这么说的。这种心态恰恰表明他们不了解世界上大多数人如何看待美国。即使在像法国这样的地方，美国也被视为盟友，但却是一个非常不值得信任的盟友。特别是到目前为止，在所有已确认的后门中，大多数实际上是美国制造的。
如果这个后门与美国有关，你的提议能解决什么问题？
如果这个后门与美国有关，你的提议能解决什么问题？
"We" doesn't have to be the U.S. This is a false dichotomy that I see people in this thread keep pushing. I suspect in bad faith, by the people that want to insert backdoors. As a baseline, we could keep the contributors to NATO and friends. If a programmer is caught backdooring, they can be charged and extradited to and from whatever country.
如果只是引渡问题，美国与116个国家签有引渡条约。您仍然必须 1) 确保用户的真实身份（ID？），2) 他们可靠，3) 没有人泄露他们的帐户。
1) 和 3)（在某种程度上，2））在某种程度上是由具有安全意识的普通雇主例行完成的。您的雇主知道您是谁，并且可能会考虑如何避免您的帐户被黑客入侵。
但什么是可靠性呢？可以是任何内容，从“这个家伙没有未执行的搜查令”到“这个家伙已经被执法机构广泛调查，有足够的资源来深入了解他们的生活、财务、朋友和家人、习惯等等”。
我可能愿意为了一份实际的、“现实世界”的工作而经历这些困难，但仅仅为了能够提交到 Github 存储库而让自己接受数月的调查似乎有点过分了。
此外，人是会变的，你应该能够一直跟踪每个人，以防有人被勒索或被说服做坏事。如果你发现某人是双重间谍，会发生什么？回滚多年的承诺可能非常困难。
1) 和 3)（在某种程度上，2））在某种程度上是由具有安全意识的普通雇主例行完成的。您的雇主知道您是谁，并且可能会考虑如何避免您的帐户被黑客入侵。
但什么是可靠性呢？可以是任何内容，从“这个家伙没有未执行的搜查令”到“这个家伙已经被执法机构广泛调查，有足够的资源来深入了解他们的生活、财务、朋友和家人、习惯等等”。
我可能愿意为了一份实际的、“现实世界”的工作而经历这些困难，但仅仅为了能够提交到 Github 存储库而让自己接受数月的调查似乎有点过分了。
此外，人是会变的，你应该能够一直跟踪每个人，以防有人被勒索或被说服做坏事。如果你发现某人是双重间谍，会发生什么？回滚多年的承诺可能非常困难。
Getting a TS equivalent is exactly what helps minimize them chances that someone is compromised. Ideally, such an investigation would be transferable between jobs/projects, like normal TS clearance is. If someone is caught, yes rolling back years isn't practical, but we probably ought to look very closely at what they've done, like is probably being done with xz.
I guess it depends on the ultimate goal.
If the ultimate goal is to avoid backdoors in critical infrastructures (think government systems, financial sector, transportation,...) you could force those organizations to use forks managed by an entity like CISA, NIST or whatever.
If the ultimate goal is to avoid backdoors in random systems (i.e. for "opportunistic attacks"), you have to keep in mind random people and non-critical companies can and will install unknown OSS projects as well as unknown proprietary stuff, known but unmaintained proprietary stuff (think Windows XP), self-maintained code, and so on. Enforcing TS clearances on OSS projects would not significantly mitigate that risk, IMHO.
Not to mention that, as we now know, allies spy and backdoor allies (or at least they try)... so an international alliance doesn't mean intelligence agencies won't try to backdoor systems owned by other countries, even if they are "allies".
If the ultimate goal is to avoid backdoors in critical infrastructures (think government systems, financial sector, transportation,...) you could force those organizations to use forks managed by an entity like CISA, NIST or whatever.
If the ultimate goal is to avoid backdoors in random systems (i.e. for "opportunistic attacks"), you have to keep in mind random people and non-critical companies can and will install unknown OSS projects as well as unknown proprietary stuff, known but unmaintained proprietary stuff (think Windows XP), self-maintained code, and so on. Enforcing TS clearances on OSS projects would not significantly mitigate that risk, IMHO.
Not to mention that, as we now know, allies spy and backdoor allies (or at least they try)... so an international alliance doesn't mean intelligence agencies won't try to backdoor systems owned by other countries, even if they are "allies".
The core systems of Linux should be secured, regardless of who is using it. We don't need every single open source project to be secured. It's not okay to me that SSH is potentially vulnerable, just because it's my personal machine. As for allies spying on each other, that certainly happens, but is a lot harder to do without significant consequences. It will be even harder if we make sure that every commit is tied to a real person that can face real consequences.
The "core systems of Linux" include the Linux kernel, openssh, xz and similar libraries, coreutils, openssl, systemd, dns and ntp clients, possibly curl and wget (what if a GET on a remote system leaks data?),... which are usually separate projects.
The most practical way to establish some uniform governance over how people use those tools would involve a new OS distribution, kinda like Debian, Fedora, Slackware,... but managed by NIST or equivalent, which takes whatever they want from upstream and enrich it with other features.
But it doesn't stop here. What about browsers (think about how browsers protect us from XSS)? What about glibc, major interpreters and compilers? How do you deal with random Chrome or VS Code extensions? Not to mention "smart devices"...
Cybersecurity is not just about backdoors, it is also about patching software, avoiding data leaks or misconfigurations, proper password management, network security and much more.
Relying on trusted, TS cleared personnel for OS development doesn't prevent companies from using 5-years old distros or choosing predictable passwords or exposing critical servers to the Internet.
As the saying goes, security is not a product, it's a mindset.
The most practical way to establish some uniform governance over how people use those tools would involve a new OS distribution, kinda like Debian, Fedora, Slackware,... but managed by NIST or equivalent, which takes whatever they want from upstream and enrich it with other features.
But it doesn't stop here. What about browsers (think about how browsers protect us from XSS)? What about glibc, major interpreters and compilers? How do you deal with random Chrome or VS Code extensions? Not to mention "smart devices"...
Cybersecurity is not just about backdoors, it is also about patching software, avoiding data leaks or misconfigurations, proper password management, network security and much more.
Relying on trusted, TS cleared personnel for OS development doesn't prevent companies from using 5-years old distros or choosing predictable passwords or exposing critical servers to the Internet.
As the saying goes, security is not a product, it's a mindset.
We wouldn't have to change the structure of the project to ensure that everyone is trustworthy.
As for applications beyond the core system, that would fall on the individual organizations to weigh the risks. Most places already have a fairly limited stack and do not let you install whatever you want. But given that the core system isn't optional in most cases, it needs extra care. That's putting aside the fact that most projects are worked on by big corps that do go after rogue employees. Still, I would prefer if some of the bigger projects were more secure as well.
Your "mindset" is basically allowing bad code into the Kernel and hoping that it gets caught.
As for applications beyond the core system, that would fall on the individual organizations to weigh the risks. Most places already have a fairly limited stack and do not let you install whatever you want. But given that the core system isn't optional in most cases, it needs extra care. That's putting aside the fact that most projects are worked on by big corps that do go after rogue employees. Still, I would prefer if some of the bigger projects were more secure as well.
Your "mindset" is basically allowing bad code into the Kernel and hoping that it gets caught.
A quote from... your arse?
That is what I thought too but it wasn't hard to find:
https://darknetdiaries.com/transcript/21/
https://darknetdiaries.com/transcript/21/
It's also a known fact that China will coerce people by threatening family and friends.
Seen this happen to friends here in Australia who were attending pro-Taiwan protests.
Seen this happen to friends here in Australia who were attending pro-Taiwan protests.
We detached this subthread from https://news.ycombinator.com/item?id=39867106.
Wait, I'm on mobile. Did this partially slip by because of the ABSURD PRACTICE of publishing release.tarballs that do not 1:1 correspond with source?
Let me guess, autotools? I want to rage shit post but I guess I'll wait for confirmation first.
EDIT: YUP, AT LEAST PARTIALLY. Fucking god damn autotools.
Let me guess, autotools? I want to rage shit post but I guess I'll wait for confirmation first.
EDIT: YUP, AT LEAST PARTIALLY. Fucking god damn autotools.
[deleted]
一整天都在说这个，GitHub 确实需要对 tarball 与实际存储库进行自动 diff / A/B 检查，当 tarball 与存储库不匹配时，至少用警告标记所有内容（+[在此处插入额外的审查步骤]）。
The author (Jia Tan) also changed the xz.tukaani.org (actually the github.io, where the main contributor is, surprise, also them) release description to state all new releases are signed by their OpenPGP key. I'd guess that was one of the first steps to a complete project takeover.
I hope Lasse Collin still has control of his accounts, though the CC on the kernel mailing list looks kind of suspicious to me.
I hope Lasse Collin still has control of his accounts, though the CC on the kernel mailing list looks kind of suspicious to me.
Out of curiosity I looked at the list of followers of the account who committed the backdoor.
Randomly picked https://github.com/Neustradamus and looked at all their contributions.
Interestingly enough, they got Microsoft to upgrade ([0],[1]) `vcpkg` to liblzma 5.6.0 3 weeks ago.
[0] https://github.com/microsoft/vcpkg/issues/37197
[1] https://github.com/microsoft/vcpkg/pull/37199
Randomly picked https://github.com/Neustradamus and looked at all their contributions.
Interestingly enough, they got Microsoft to upgrade ([0],[1]) `vcpkg` to liblzma 5.6.0 3 weeks ago.
[0] https://github.com/microsoft/vcpkg/issues/37197
[1] https://github.com/microsoft/vcpkg/pull/37199
OMG：看看其他贡献。他正试图接管项目，并在上百个项目中推动对 sha256 的修改。
例如：https://github.com/duesee/imap-flow/issues/96
例如：https://github.com/duesee/imap-flow/issues/96
这家伙的互动看起来很奇怪，但这可能只是因为非英语母语或奇怪的态度，或者他非常擅长掩盖自己的行踪，例如发现了一个 cpython 问题，他因连续打开问题而受到谴责：https://github.com/python/cpython/issues/115195#issuecomment...
但他似乎主要是围绕这些内容进行有趣的互动，例如https://github.com/python/cpython/issues/95341#issuecomment-... 或 ping 整个 python 团队以链接到核心 Python 开发人员的 PR...：https://github.com/python/cpython/issues/95341#issuecomment-...
如果我在 $dayjob 项目中看到这一点，我会把他视为无伤大雅的麻烦（过度兴奋、吵闹、恶作剧）。
这是 2020 年的 PR，他建议/请求向 SMTP 客户端添加 SCRAM：https://github.com/marlam/msmtp/issues/36，这与您找到的 PR 基本相同。链接的文档看起来是真实的，SCRAM 是一种针对各种协议（在本例中主要是 SMTP、IMAP 和 XMPP）的实际质询/响应身份验证方法：https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...
虽然，这有点令人毛骨悚然，他出现在 SCRAM 页面的版本历史中，但编辑看起来大多是无辜的，尽管他确实插入了他的“state of play”github 存储库。
但他似乎主要是围绕这些内容进行有趣的互动，例如https://github.com/python/cpython/issues/95341#issuecomment-... 或 ping 整个 python 团队以链接到核心 Python 开发人员的 PR...：https://github.com/python/cpython/issues/95341#issuecomment-...
如果我在 $dayjob 项目中看到这一点，我会把他视为无伤大雅的麻烦（过度兴奋、吵闹、恶作剧）。
这是 2020 年的 PR，他建议/请求向 SMTP 客户端添加 SCRAM：https://github.com/marlam/msmtp/issues/36，这与您找到的 PR 基本相同。链接的文档看起来是真实的，SCRAM 是一种针对各种协议（在本例中主要是 SMTP、IMAP 和 XMPP）的实际质询/响应身份验证方法：https://en.wikipedia.org/wiki/Salted_Challenge_Response_Auth...
虽然，这有点令人毛骨悚然，他出现在 SCRAM 页面的版本历史中，但编辑看起来大多是无辜的，尽管他确实插入了他的“state of play”github 存储库。
> dickriding
https://www.urbandictionary.com/define.php?term=Dickriding
I guess I'm not in the right demographic to know the term.
https://www.urbandictionary.com/define.php?term=Dickriding
I guess I'm not in the right demographic to know the term.
"fawning" or "ingratiating" seem to be the standard English words for this.
True, it does seem innocent enough upon more reflection.
将该账号报告给github，以防万一。
什么？他们只是要求那里有一些功能？
你需要冷静下来；这太愚蠢了。如果你开始仔细检查微观细节，一半的 GitHub 帐户看起来“可疑”。
你需要冷静下来；这太愚蠢了。如果你开始仔细检查微观细节，一半的 GitHub 帐户看起来“可疑”。
[deleted]
I appreciate the way that duesee handled that whole issue.
[deleted]
嘿，我记得这家伙！他是一个试图在 ifupdown-ng 中加入大量低质量内容的人的朋友，包括复制与许可证不兼容的代码并删除通知。他在每次公关中都抱怨 "项目已死"。他甚至要求把这个账户变成 "团队成员"。
https://github.com/ifupdown-ng/ifupdown-ng/pulls/easynetdev
不过他关注了 54000 个账户，所以这可能只是巧合。
https://github.com/ifupdown-ng/ifupdown-ng/pulls/easynetdev
不过他关注了 54000 个账户，所以这可能只是巧合。
I wouldn't be surprised if that is just a bot.
He even follows me, though I have never published any open-source project on my own.
He even follows me, though I have never published any open-source project on my own.
The PR + angry user pushing for the PR author to gain commit access spiel is definitely suspiciously similar to what happened with xz-utils. Possible coincidence but worth investigating further.
Dear @0xthr0w4, do you attack me because I have requested the XZ update?
Do not mix, I am not linked to the XZ project.
Do not mix, I am not linked to the XZ project.
The parent comment doesn't read like an attack to me. Just an observation. Would be curious why you wanted the update though.
[deleted]
请求更新到 liblzma 5.6.0 [0] 的拉取请求列表
我想知道所有提议升级的帐户应该接受多少审查。
[0] https://github.com/search?q=liblzma+5.6.0&type=pullrequests
我想知道所有提议升级的帐户应该接受多少审查。
[0] https://github.com/search?q=liblzma+5.6.0&type=pullrequests
Tukaani website states "jiatan" as the nickname of the malicious code committer on Libera Chat.
WHOWAS jiatan provided me the following information:
jiatan ~jiatan 185.128.24.163 * :Jia Tan jiatan 185.128.24.163 :actually using host jiatan jiatan :was logged in as jiatan tungsten.libera.chat :Fri Mar 14:47:40 2024
WHOIS yields nothing, the user is not present on the network at the moment.
Given that 185.128.24.163 is covered with a range-block on the English Wikipedia, it appears this is a proxy.
WHOWAS jiatan provided me the following information:
jiatan ~jiatan 185.128.24.163 * :Jia Tan jiatan 185.128.24.163 :actually using host jiatan jiatan :was logged in as jiatan tungsten.libera.chat :Fri Mar 14:47:40 2024
WHOIS yields nothing, the user is not present on the network at the moment.
Given that 185.128.24.163 is covered with a range-block on the English Wikipedia, it appears this is a proxy.
> it appears this is a proxy.
Yes, that IP address appears associated with witopia[.]net, specifically vpn.singapore.witopia[.]net points to that IP address.
Yes, that IP address appears associated with witopia[.]net, specifically vpn.singapore.witopia[.]net points to that IP address.
Waiting for the new YouTube videos on this. "Woah! Linux has a back door dudes!". My distribution, Ubuntu (now Kubuntu) 2022 isn't affected.
not sure why you're being downvoted. this is exactly what is going to happen.
Still better than TwoMinuteToiletPapers and other AI-bamboozled channels hyping over proprietary OpenAI crap (text/photo/video), what a time to be alive!
我很好奇向OSS软件注入后门的行为是否合法/非法？
除非我们能证明他们积极利用了这一点，否则他们是否在某种程度上是清白的？
除非我们能证明他们积极利用了这一点，否则他们是否在某种程度上是清白的？
Probably depends on criminal code a country. Mine does (EU country):
> Section 231 Obtaining and Possession of Access Device and Computer System Passwords and other such Data
> (1) Whoever with the intent to commit a criminal offence of Breach of secrecy of correspondence [...] or a criminal offence of Unauthorised access to computer systems and information media [...] produces, puts into circulation, imports, exports, transits, offers, provides, sells, or otherwise makes available, obtains for him/herself or for another, or handles
> a) a device or its component, process, instrument or any other means, including a computer programme designed or adapted for unauthorised access to electronic communications networks, computer system or a part thereof, or
> b) a computer password, access code, data, process or any other similar means by which it is possible to gain access to a computer system or a part thereof,
shall be sentenced .. (1 year as an individual, 3 years as a member of a organized group)
> Section 231 Obtaining and Possession of Access Device and Computer System Passwords and other such Data
> (1) Whoever with the intent to commit a criminal offence of Breach of secrecy of correspondence [...] or a criminal offence of Unauthorised access to computer systems and information media [...] produces, puts into circulation, imports, exports, transits, offers, provides, sells, or otherwise makes available, obtains for him/herself or for another, or handles
> a) a device or its component, process, instrument or any other means, including a computer programme designed or adapted for unauthorised access to electronic communications networks, computer system or a part thereof, or
> b) a computer password, access code, data, process or any other similar means by which it is possible to gain access to a computer system or a part thereof,
shall be sentenced .. (1 year as an individual, 3 years as a member of a organized group)
The way I see it: People are being charged for their speech all the time. Especially outside the US, but even in the US. And code is speech.
And that is even before all the hacking/cracking/espionage laws get involved.
There's a reason all the (sane) people doing grey/black hat work take their security and anonymity extremely seriously.
And that is even before all the hacking/cracking/espionage laws get involved.
There's a reason all the (sane) people doing grey/black hat work take their security and anonymity extremely seriously.
My favorite part was the analysis of "I'm not really a security researcher or reverse engineer but here's a complete breakdown of exactly how the behavior changes."
You only get this kind of humility when you're working with absolute wizards on a consistent basis.
You only get this kind of humility when you're working with absolute wizards on a consistent basis.
I'd love to be at Microsoft right now and have the power to review this user's connection history to Github, even though VPN exists, many things can be learned from connection habits, links to ISPs, maybe even guess if VPNs were used, roundtrip time on connections can give hints.
I really don't think some random guy wants to weaken ssh just to extract some petty ransomware cash from a couple targets.
I really don't think some random guy wants to weaken ssh just to extract some petty ransomware cash from a couple targets.
> I really don't think some random guy wants to weaken ssh just to extract some petty ransomware cash from a couple targets.
Which is why there's probably nothing remotely interesting in them logs.
Which is why there's probably nothing remotely interesting in them logs.
Intelligence agencies get caught red handed all the time so I wouldn't be too sure.
If it was an organised group I'm sure they were careful, of course, but it only takes one fuckup.
If it was an organised group I'm sure they were careful, of course, but it only takes one fuckup.
I'm guessing Microsoft just got a call from the Government telling them not to look too deeply into it.
Nah. I'm sure Microsoft got a call from the alphabet boys and nobody, not even internal employees are allowed to look at the logs right now.
天哪，又一个不使用 github 的原因。 :D 仅在这个评论部分就出现了很多原因。
people are mis-reading the Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067708
it wasn't the apparently newly-created identity "Hans Jansen" just asking for a new version to be uploaded, it was "Hans Jansen" providing a new version to be uploaded as a non-maintainer-upload - Debian-speak for "the maintainer is AWOL, someone else is uploading their package". if "Hans Jansen" is another attacker then they did this cleverly, providing the new - compromised - upstream tarballs in an innocent-looking way and avoiding anyone examining the upstream diff.
it wasn't the apparently newly-created identity "Hans Jansen" just asking for a new version to be uploaded, it was "Hans Jansen" providing a new version to be uploaded as a non-maintainer-upload - Debian-speak for "the maintainer is AWOL, someone else is uploading their package". if "Hans Jansen" is another attacker then they did this cleverly, providing the new - compromised - upstream tarballs in an innocent-looking way and avoiding anyone examining the upstream diff.
Could anyone please tell me if current stable version of Debian has that backdoor or not?
Debian stable has 5.4.1, the backdoored versions are 5.6.0-5.6.1
https://packages.debian.org/bookworm/xz-utils
https://packages.debian.org/bookworm/liblzma5
https://packages.debian.org/bookworm/xz-utils
https://packages.debian.org/bookworm/liblzma5
Debian Stable seems to be in the clear.
https://lists.debian.org/debian-security-announce/2024/msg00...
https://lists.debian.org/debian-security-announce/2024/msg00...
It does not contain the backdoor: <https://security-tracker.debian.org/tracker/CVE-2024-3094<
I read through the entire report and it gradually got more interesting. Then, I got to the very end, saw Andres Freund's name, and it put a smile on my face. :)
Who else would have run a PostgreSQL performance benchmark and discover a major security issue in the process?
Who else would have run a PostgreSQL performance benchmark and discover a major security issue in the process?
Personally, I use lzip ever since I read https://www.nongnu.org/lzip/xz_inadequate.html
Seems like the complexity of XZ has backfired severely, as expected.
> Seems like the complexity of XZ has backfired severely, as expected.
this is a very bad reading of the current situation.
this is a very bad reading of the current situation.
This kind of shallow dismissal is really unhelpful to those of us trying to follow the argument. You take a tone of authoritative expert, without giving any illuminating information to help outsiders judge the merit of your assertion. Why is it a very bad reading of the current situation? What is a better reading?
To summarize the article, the back door is introduced through build scripts and binaries distributed as “test” data. Very little to do with the complexity or simplicity of xz; more that it was a dependency of critical system binaries (systemd) and ripe for hostile takeover of the maintainer role.
Introducing a back door is not the same thing as a badly designed file format.
I am not sure I agree that every low quality post needs a detailed rebuttal? HN couldn't function under such rules.
as to the specific comment:
> Seems like the complexity of XZ has backfired severely, as expected.
to summarise: someone found a project with a vulnerable maintenance situation, spent years getting involved in a project, then got commit rights, and then commited a backdoor in some binaries and the build system, then got sock puppets to agitate for OSes to adopt the backdoored code.
the comment I replied to made a "shallow" claim of complexity without any details, so let's look at some possible interpretations:
- code complexity - doesn't seem super relevant - the attacker hide a highly obfuscated backdoor in a binary test file and committed it - approximately no one is ever going to catch such things without a process step of requiring binaries be generatable in a reasonable-looking and hopefully-hard-to-backdoor kind of way. cryptographers are good at this: https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number
- build complexity - sure, but it's auto*, that's very common.
- organisational complexity - the opposite is the case. it had one guy maintaining it, who asked for help.
- data/file format complexity - doesn't seem relevant unless it turns out the obfuscation method used was particularly easy for this format, but even in that case, you'd think others would be vulnerable to something equivalent
perhaps OP had some other thing in mind, but then they could have said that, instead of making a crappy comment.
as to the specific comment:
> Seems like the complexity of XZ has backfired severely, as expected.
to summarise: someone found a project with a vulnerable maintenance situation, spent years getting involved in a project, then got commit rights, and then commited a backdoor in some binaries and the build system, then got sock puppets to agitate for OSes to adopt the backdoored code.
the comment I replied to made a "shallow" claim of complexity without any details, so let's look at some possible interpretations:
- code complexity - doesn't seem super relevant - the attacker hide a highly obfuscated backdoor in a binary test file and committed it - approximately no one is ever going to catch such things without a process step of requiring binaries be generatable in a reasonable-looking and hopefully-hard-to-backdoor kind of way. cryptographers are good at this: https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number
- build complexity - sure, but it's auto*, that's very common.
- organisational complexity - the opposite is the case. it had one guy maintaining it, who asked for help.
- data/file format complexity - doesn't seem relevant unless it turns out the obfuscation method used was particularly easy for this format, but even in that case, you'd think others would be vulnerable to something equivalent
perhaps OP had some other thing in mind, but then they could have said that, instead of making a crappy comment.
Totally agree. This aggressive stance about xz suddenly is not even helpful to anyone. xz has been and will always be my preferred compression algorithm for times to come, despite this pitfall of really insane levels of social engineering.
I feel for the author having burn out and such, but in all fairness, xz is one of the best compression formats of today's time and still going.
What a disappointment.
It's something always in the back of our minds as developers using public libraries, but when something like this happens, non-developers that hear about it start to associate it with the rest of the open-source community.
It's essentially a terrorist attack on developer experience. Thankfully, management doesn't follow the same approach as the TSA.
It's something always in the back of our minds as developers using public libraries, but when something like this happens, non-developers that hear about it start to associate it with the rest of the open-source community.
It's essentially a terrorist attack on developer experience. Thankfully, management doesn't follow the same approach as the TSA.
"Lasse Collin," as other posters here have found, does not seem to exist as an experienced coder. Oddly, there is a Swedish jazz musician named Lasse Collin, which would otherwise be one of those names, especially the last name, that would stick out. Instead it is buried under a lot of mentions of a musician.
Searching for my real name on Google doesn't return anything either, I don't think this means anything.
Lasse Collin the contributor is findable, especially if you add "tukaani" to the search. But not in any other context, unless that's what old jazz musicians do in their retirement.
I don't think that's what they meant. The idea is to find information about their personal life, not OSS contributions. Something that proves they're a real person.
Lasse Collin 几十年来一直致力于 xz：https://sourceforge.net/p/sevenzip/discussion/45797/thread/0...
现在，他的 GitHub 帐户目前是否被他控制是另一个问题。
另外，为了了解更多背景信息：2022 年，Lasse 表示他在 xz 上工作很困难，正在寻找维护者，并提到了 Jia Tan：https://www.mail-archive.com/[email protected]/msg00567.h...
现在，他的 GitHub 帐户目前是否被他控制是另一个问题。
另外，为了了解更多背景信息：2022 年，Lasse 表示他在 xz 上工作很困难，正在寻找维护者，并提到了 Jia Tan：https://www.mail-archive.com/[email protected]/msg00567.h...
Fairly deep bugs for a Bazaar.
Thank the gods I didn't plan on having a life this weekend
Looking at how many requests to update to the backdoored version have been made, I wonder if the fact that many people (including developers) have been conditioned to essentially accept updates as "always-good" is a huge contributing factor in how easy it is to spread something like this.
The known unknowns can be better than the unknown unknowns.
The known unknowns can be better than the unknown unknowns.
Totally agree. With things like Dependabot encouraged by GitHub, people now get automated pull requests for dependency updates, increasing the speed of propagation of such vulnerabilities.
两个 https://github.com/tukaani-project 成员帐户均已被暂停。
（要查看这一点，您可以列出每个帐户的关注者）。
（要查看这一点，您可以列出每个帐户的关注者）。
有点相关，因为我很少看到关于如何更安全的语言作为解决方案的评论。
这里[0]是一个非常简单的例子，它展示了这种供应链攻击在Rust中是多么容易；我们不要忘记几天前发生了一次非常大的蟒蛇攻击[1]。
[0] - https://github.com/c-skills/rust1
[1] - https://checkmarx.com/blog/over-170k-users-affected-by-attac...
这里[0]是一个非常简单的例子，它展示了这种供应链攻击在Rust中是多么容易；我们不要忘记几天前发生了一次非常大的蟒蛇攻击[1]。
[0] - https://github.com/c-skills/rust1
[1] - https://checkmarx.com/blog/over-170k-users-affected-by-attac...
I am very concerned about Rust.
Rust’s “decision” to have a very slim standard library has advantages, but it severely amplifies some other issues. In Go, I have to pull in zero dependencies to make an HTTP request. In Rust, pulling reqwest pulls in at least 30 distinct packages (https://lib.rs/crates/reqwest). Date/time, “basic” base64, common hashing or checksums, etc, they all become supply chain vectors.
The Rust ecosystem’s collective refusal to land stable major versions is one of the amplifying issues. “Upgrade fatigue” hits me, at least. “Sure, upgrade ring to 0.17” (which is effectively the 16th major version). And because v0.X versions are usually incompatible, it’s not really possible to opt not to upgrade, because it only takes a short while before some other transitive dependency breaks because you are slow to upgrade. I recently spent a while writing my code to support running multiple versions of the `http` library, for example (which, to be fair, did just land version 1.0). My NATS library (https://lib.rs/crates/async-nats) is at version 34. My transitive base64 dependency is at version 22 (https://lib.rs/crates/base64).
This makes it nearly impossible for me to review these libraries and pin them, because if I pin [email protected], and bar needs [email protected], I just get both. bar can’t do =>0.41, because the point of the 0.X series is that it is not backwards compatible. It makes this process so time consuming that I expect people will either just stop (as if they did) reviewing their dependencies, or accept that they might have to reinvent everything from URL parsing to constructing http headers or doing CRC checks.
Combine this with a build- and compile-time system that allows completely arbitrary code execution, which is routinely just a wrapper for stuff like in the zx attack (look at a lot of the low-level libs you inevitably pull in). Sure, the build scripts and the macro system enables stuff like the amazing sqlx library, but said build and macro code is already so hard to read, it really takes proper wizardry to properly understand.
Rust’s “decision” to have a very slim standard library has advantages, but it severely amplifies some other issues. In Go, I have to pull in zero dependencies to make an HTTP request. In Rust, pulling reqwest pulls in at least 30 distinct packages (https://lib.rs/crates/reqwest). Date/time, “basic” base64, common hashing or checksums, etc, they all become supply chain vectors.
The Rust ecosystem’s collective refusal to land stable major versions is one of the amplifying issues. “Upgrade fatigue” hits me, at least. “Sure, upgrade ring to 0.17” (which is effectively the 16th major version). And because v0.X versions are usually incompatible, it’s not really possible to opt not to upgrade, because it only takes a short while before some other transitive dependency breaks because you are slow to upgrade. I recently spent a while writing my code to support running multiple versions of the `http` library, for example (which, to be fair, did just land version 1.0). My NATS library (https://lib.rs/crates/async-nats) is at version 34. My transitive base64 dependency is at version 22 (https://lib.rs/crates/base64).
This makes it nearly impossible for me to review these libraries and pin them, because if I pin [email protected], and bar needs [email protected], I just get both. bar can’t do =>0.41, because the point of the 0.X series is that it is not backwards compatible. It makes this process so time consuming that I expect people will either just stop (as if they did) reviewing their dependencies, or accept that they might have to reinvent everything from URL parsing to constructing http headers or doing CRC checks.
Combine this with a build- and compile-time system that allows completely arbitrary code execution, which is routinely just a wrapper for stuff like in the zx attack (look at a lot of the low-level libs you inevitably pull in). Sure, the build scripts and the macro system enables stuff like the amazing sqlx library, but said build and macro code is already so hard to read, it really takes proper wizardry to properly understand.
You have perfectly put into words, all my thoughts.
I have been thinking about ways to secure myself, as it is exhausting to think about it every time there is an update or some new dependency.
After this attack, I think the only sure way is to unplug the computer and go buy goats.
The next best thing? Probably ephemeral VMs or some Codespaces/"Cloud Dev Env thingy". (except neither would save me in the xz case)
I have been thinking about ways to secure myself, as it is exhausting to think about it every time there is an update or some new dependency.
After this attack, I think the only sure way is to unplug the computer and go buy goats.
The next best thing? Probably ephemeral VMs or some Codespaces/"Cloud Dev Env thingy". (except neither would save me in the xz case)
Or you vendor everything.
You don't automatically download anything at build or install time, you just update your local source copies when you want to. Which to be clear I know means rarely.
It's 1970 all over again!
You don't automatically download anything at build or install time, you just update your local source copies when you want to. Which to be clear I know means rarely.
It's 1970 all over again!
Yes, but this doesn’t prevent issues like the xz issue, where the code looks fine, but the build scripts alter it.
Vendoring is nice, and I usually prefer it, but you don't always have the time or people for it.
Vendoring + custom build system (Bazel?) for everything is basically googles approach, if what I have read is correct. Definitely better than everything we have, but the resources for it are not something most can afford.
P.S also what mrcus said, if we trust the upstream build process, we may as well trust their binaries.
Vendoring + custom build system (Bazel?) for everything is basically googles approach, if what I have read is correct. Definitely better than everything we have, but the resources for it are not something most can afford.
P.S also what mrcus said, if we trust the upstream build process, we may as well trust their binaries.
That was what the 1970 crack was about.
> In Rust, pulling reqwest pulls in at least 30 distinct packages
This would be less of a problem if each dependency (and in turn, their dependencies) were individually sandboxed, and only allowed to access specific inputs/files at runtime in the capability security (https://en.wikipedia.org/wiki/Capability-based_security) fashion.
This way the attack surface would be hollowed out as much as possible, and exploits limited to the (sub)program output or specific accessible (writable) files.
This would be less of a problem if each dependency (and in turn, their dependencies) were individually sandboxed, and only allowed to access specific inputs/files at runtime in the capability security (https://en.wikipedia.org/wiki/Capability-based_security) fashion.
This way the attack surface would be hollowed out as much as possible, and exploits limited to the (sub)program output or specific accessible (writable) files.
[deleted]
The two active maintainers seem to be: Lasse Collin <[email protected]> and Jia Tan <[email protected]>
Searching DDG for "jiat0218" I came across a blog post which I found weird. Seems to be dated: 2006-05-03
Blog post: "Kuso拍賣．有靈氣的筷子 - 闕小豪" <https://char.tw/blog/post/24397301>
Internet Archive link: <https://web.archive.org/web/20240329182713/https://char.tw/b...>
The contents of the page when translated seems to be about jiat0218 auctioning a pair of spiritual chopsticks as a prank.
The blog entry is basically a QA between jiat0218 and various other people about these chopsticks.
If Jia Tan does turn out to be a compromised maintainer working for a state actor then some of the content on the blog page can be viewed in a more sinister way (i.e. spycraft / hacks for sale etc.).
Example question 38:
Searching DDG for "jiat0218" I came across a blog post which I found weird. Seems to be dated: 2006-05-03
Blog post: "Kuso拍賣．有靈氣的筷子 - 闕小豪" <https://char.tw/blog/post/24397301>
Internet Archive link: <https://web.archive.org/web/20240329182713/https://char.tw/b...>
The contents of the page when translated seems to be about jiat0218 auctioning a pair of spiritual chopsticks as a prank.
The blog entry is basically a QA between jiat0218 and various other people about these chopsticks.
If Jia Tan does turn out to be a compromised maintainer working for a state actor then some of the content on the blog page can be viewed in a more sinister way (i.e. spycraft / hacks for sale etc.).
Example question 38:
Question 38
accounta066 (3): Are these chopsticks really that good? I kind of want to buy
them! But I recently sent money for online shopping but didn’t receive anything.
It’s very risky; currently jiat0218 you don’t have any reviews, you can
interview me. Do you want to hand it over?! … A sincere buyer will keep it.
Reply to
jiat0218 (4): First of all, I would like to express my condolences to you for
your unfortunate experience! What can I say about this kind of thing...My little
sister has always been trustworthy. What’s more, this is a pair of spiritual
chopsticks, so I hope to have a good one. It’s the beginning! As you can see,
my little sister is very careful and takes her time when answering your
questions. Except for the two messages that were accidentally deleted by her,
she always answers your questions. If this still doesn’t reassure you, then I
can only say that I still have room to work hard. You are still welcome
to bid... ^_^
Chopsticks could also be a codeword for something. Maybe some sort a backdoor into a system somewhere.
This is likely just a coincidence. 0218 looks like a birthday and jiat is probably the name + initial. 18 years is also too long of a time horizon for this.
Crazy to think that the time horizon for these kinds of attacks span decades. This absolutely does not read like a coincidence. Chopsticks, little sister, "room to work hard", all sound like codewords.
Do you say that about every word commonly used in Asia?
Sounds to me like google translate gibberish
Something about this I found surprising is that Linux distros are pulling and packaging pre-built binaries from upstream projects. I'd have expected them to build from source.
They were pulling a tarball from upstream and building it - the tarball was compromised.
答案并不完整。有 2 种提取信息源的方法：
坏的 - https://github.com/tukaani-project/xz/releases/download/...
或
好 - https://github.com/tukaani-project/xz/archive/refs/tags/...
特别是在 Gentoo 中，https://github.com/gentoo/gentoo/blob/master/app-arch/xz-uti 中有一个注释...
# 记住：我们不能在此 ebuild 中使用 autotools，以便
# 避免使用自动工具进行循环部署
也就是说，要从 gnu.org 解压 autoconf-2.72e.tar.xz，你需要 xz-tools。这只是一个最短的循环。这并不常见，但 xz-utils 是少数几个将 autohell 文件的再生视为不必要的麻烦的案例之一（结果适得其反）。
坏的 - https://github.com/tukaani-project/xz/releases/download/...
或
好 - https://github.com/tukaani-project/xz/archive/refs/tags/...
特别是在 Gentoo 中，https://github.com/gentoo/gentoo/blob/master/app-arch/xz-uti 中有一个注释...
# 记住：我们不能在此 ebuild 中使用 autotools，以便
# 避免使用自动工具进行循环部署
也就是说，要从 gnu.org 解压 autoconf-2.72e.tar.xz，你需要 xz-tools。这只是一个最短的循环。这并不常见，但 xz-utils 是少数几个将 autohell 文件的再生视为不必要的麻烦的案例之一（结果适得其反）。
不幸的是，这些 GitHub 链接不再有效，因此我们无法使用它们来了解这里出了什么问题。希望尘埃落定后，GH 会改变这一决定。
其要点是：“好的”版本是由 github 自动生成的“源代码”版本。 “坏”的是手动生成并上传的源代码版本，它可以有您想要的任何内容。
GitHub 不应该只是反转并公开存储库并“按原样”存档，因为有许多滚动发行版（从 Gentoo 到 LFS）、子模块拉取器、CI 系统、不知情的用户，它们可能会拉取并安装存档项目的最新后门提交。
但是，如果您想访问后门 tarball 的精确副本，它们仍然可以在每个镜像上使用，例如。 g。在http://gentoo.mirror.root.lu/distfiles/9f/。对于这个级别的项目，世界各地的许多人都会对工件进行校验和镜像，这没有什么问题。
但是，如果您想访问后门 tarball 的精确副本，它们仍然可以在每个镜像上使用，例如。 g。在http://gentoo.mirror.root.lu/distfiles/9f/。对于这个级别的项目，世界各地的许多人都会对工件进行校验和镜像，这没有什么问题。
[deleted]
Sorry, by "they" I mean "Debian and Fedora", which (when including derivatives) include most Linux systems which use a Linux distro in the standard sense.
Not in this case as the other commenter pointed out but for example Vivaldi on Arch Linux is just a repackaged upstream build.
https://gitlab.archlinux.org/archlinux/packaging/packages/vi...
https://gitlab.archlinux.org/archlinux/packaging/packages/vi...
I'm not trying to troll, but I'm wondering if a distro like Gentoo is less susceptible to such attacks, since the source code feels more transparent with their approach. But then again, it seems that upstream was infected in this case, so I'm not sure if a culture of compiling from source locally would help.
It is not going to make a difference. If you run malicious code, you will get hacked. Compiling the code yourself does not prevent the code from being malicious.
The one it might help is it might make it easier to find the back door once you know there is one.
The one it might help is it might make it easier to find the back door once you know there is one.
I guess that rewriting liblzma in Rust would not have prevented this backdoor. But would have likely increased the confidence in its safety.
Using the build system (and potentially the compiler) to insert malicious backdoors is far from a new idea, and I don't see why this example would the only case.
Using the build system (and potentially the compiler) to insert malicious backdoors is far from a new idea, and I don't see why this example would the only case.
Don’t know all the details and rust isn’t immune to a build attack, but stuff like that tends to stand out a lot more I think in a build.rs than it would in some m4 automake soup.
There was a drama back then where serde tried to ship its derive macro as a precompiled binary: https://news.ycombinator.com/item?id=37189462
The backdoor hinged on hiding things in large shell scripts, obscure C "optimizations", and sanitizer disabling. I'd expect all of those would be a much bigger red flag in the Rust world.
It would have made it worse, because there would be 300 crates with 250 different maintainers, all pulled in by several trivial/baseline dependencies. More dependencies = higher the probability that a malicious maintainer has gotten maintainer's rights for one of them, especially because many original authors/maintainers of rust style microdepencency crates move on with their lives and eventually seek to exit their maintainer role. At least for classic C/C++ software, by the virtue of it being very inconvenient to casually pull 300 dependencies for something trivial, there are fewer dependencies, i.e. separate projects/repos, and these tend to be more self-contained. There are also "unserious" distributions like Fedora and something like stable/testing/unstable pipeline in Debian, which help with catching the most egregious attempts. Crates.io and npm are unserious by their very design, which is focused on maximizing growth by eliminating as many "hindrances" as possible.
Why is rust beginning to sound like JavaScript?
Modern coders have been conditioned to import random libs to save 30mins work.
Rust specifically chose a minimal standard library to not get stuck with the Python "dead batteries" problem. There's a strong culture as well of minimizing a project's dependencies in Rust.
> Rust specifically chose a minimal standard library to not get stuck with the Python "dead batteries" problem.
So has C++ in the past although there seems to be a push for a more batteries included approach recently.
> There's a strong culture as well of minimizing a project's dependencies in Rust.
This doesn't match what anyone can observe by looking at dependencies of Rust projects.
So has C++ in the past although there seems to be a push for a more batteries included approach recently.
> There's a strong culture as well of minimizing a project's dependencies in Rust.
This doesn't match what anyone can observe by looking at dependencies of Rust projects.
This hack exploited a fairly unique quirk in the linux C ecosystem / culture. That packages are built from "tarballs" that are not exact copies of the git HEAD as they also contain generated scripts with arbitrary code.
It would not have happened in any modern language. It probably wouldn't have even happened in a Vistual Studio C-project for windows either.
It would not have happened in any modern language. It probably wouldn't have even happened in a Vistual Studio C-project for windows either.
Funny you should say that, given they definitely have exploit code in `vcpkg`
> It would not have happened in any modern language.
It would. pip for example installs from tarballs uploaded to PyPi, not from a git repository.
It would. pip for example installs from tarballs uploaded to PyPi, not from a git repository.
Pip and similar are their own can of worms yeah. They trade convinience for an almost complete lack of oversight.
But in this case we are talking about people (distro packagers) manually downloading the source and building it which is not quite the same thing.
But in this case we are talking about people (distro packagers) manually downloading the source and building it which is not quite the same thing.
`pip install` does do exactly the same thing: it downloads and executes code from a tarball uploaded to PyPi by its maintainer. There's no verification process that ensures that tarball matches what's in the git repository.
Yes I know, and that's what I meant when I said "their own can of worms".
Distro-provided python packages don't use pip however, at least afaik.
Distro-provided python packages don't use pip however, at least afaik.
The distro-provided Python packages are usually still build from the source on PyPi as uploaded by the maintainer, not what's in git.
If it were using Cargo as its build system, it might make such manipulations more obvious / understandable?
Related ongoing threads:
Xz: Disable ifunc to fix Issue 60259 - https://news.ycombinator.com/item?id=39869718
FAQ on the xz-utils backdoor - https://news.ycombinator.com/item?id=39869068
Everything I Know About the XZ Backdoor - https://news.ycombinator.com/item?id=39868673
Xz: Disable ifunc to fix Issue 60259 - https://news.ycombinator.com/item?id=39869718
FAQ on the xz-utils backdoor - https://news.ycombinator.com/item?id=39869068
Everything I Know About the XZ Backdoor - https://news.ycombinator.com/item?id=39868673
[deleted]
pRoBaBlY a StaTe AcToR
zero definition of what that means...
egos of people who just like to say cool words they don't understand
lol
this comment will probably get deleted, but let the action of this comment being deleted stand that in 2024 we're all allowed to use big words with no definition of what they mean -> bad
state actor? who? what motive? what country? all comments involving "state actor" are very broad and strange... i would like people to stop using words that have no meaning, as it really takes away from the overall conversation of what is going on.
i mean you're seriously going to say "state actor playing the long game" to what end? the issue was resolved in 2 hours... this is stupid
zero definition of what that means...
egos of people who just like to say cool words they don't understand
lol
this comment will probably get deleted, but let the action of this comment being deleted stand that in 2024 we're all allowed to use big words with no definition of what they mean -> bad
state actor? who? what motive? what country? all comments involving "state actor" are very broad and strange... i would like people to stop using words that have no meaning, as it really takes away from the overall conversation of what is going on.
i mean you're seriously going to say "state actor playing the long game" to what end? the issue was resolved in 2 hours... this is stupid
For starters, the backdoor was technically really sophisticated.
For example, the malicious code circumvents a hardening technique (RELRO) in a clever way, which would otherwise have blocked it from manipulating the sshd code in the same process space at runtime. This is not something that script kiddies usually cook up in an afternoon to make a quick buck. You need experts and a lot of time to pull off feats like that.
This points to an organization with excellent funding. I’m not surprised at all that people are attributing this to some unknown nation-level group.
For example, the malicious code circumvents a hardening technique (RELRO) in a clever way, which would otherwise have blocked it from manipulating the sshd code in the same process space at runtime. This is not something that script kiddies usually cook up in an afternoon to make a quick buck. You need experts and a lot of time to pull off feats like that.
This points to an organization with excellent funding. I’m not surprised at all that people are attributing this to some unknown nation-level group.
A lot of software (including https://gitlab.com/openconnect/openconnect of which I'm a maintainer) uses libxml2, which in turn transitively links to libzma, using it to load and store compressed XML.
I'm not *too* worried about OpenConnect given that we use `libxml2` only to read and parse uncompressed XML…
But I am wondering if there has been any statement from libxml2 devs (they're under the GNOME umbrella) about potential risks to libxml2 and its users.
I'm not *too* worried about OpenConnect given that we use `libxml2` only to read and parse uncompressed XML…
But I am wondering if there has been any statement from libxml2 devs (they're under the GNOME umbrella) about potential risks to libxml2 and its users.
> only to read and parse uncompressed XML…
how does libxml2 know to decompress something?
does it require you, as the caller, to explicitly tell it to?
or does it look at the magic bytes or filename or mimetype or something?
how does libxml2 know to decompress something?
does it require you, as the caller, to explicitly tell it to?
or does it look at the magic bytes or filename or mimetype or something?
> how does libxml2 know to decompress something?
>
> does it require you, as the caller, to explicitly tell it to?
In the entry point/function that we use, `xmlReadMemory` (https://gnome.pages.gitlab.gnome.org/libxml2/devhelp/libxml2...), it doesn't handle compressed XML at all.
But there are indeed others where it attempts to auto-detect compression, although as I understand it from the docs only ZLib compression is autodetected… though I suspect these may be out-of-date and it may autodetect any/all compiled -in compression algorithms.
Regardless, the fact that it links with liblzma is cause for concern, given the mechanism of operation of the liblzma/xz backdoor.
In the entry point/function that we use, `xmlReadMemory` (https://gnome.pages.gitlab.gnome.org/libxml2/devhelp/libxml2...), it doesn't handle compressed XML at all.
But there are indeed others where it attempts to auto-detect compression, although as I understand it from the docs only ZLib compression is autodetected… though I suspect these may be out-of-date and it may autodetect any/all compiled -in compression algorithms.
Regardless, the fact that it links with liblzma is cause for concern, given the mechanism of operation of the liblzma/xz backdoor.
This doesn't matter, if libxml2 loads .so and the library is malicious, you are already potentially compromised, as it is possible to run code on library load.
一月份的有趣提交，其中实际的 OpenPGP 密钥发生了更改：https://github.com/tukaani-project/tukaani-project.github.io...
GitHub 暂停了该项目
They just signed each other's keys around that time, and one needs to redistribute the public keys for that; nothing suspicious about it I think. The key fingerprint 22D465F2B4C173803B20C6DE59FCF207FEA7F445 remained the same.
before:
before:
pub rsa4096/0x59FCF207FEA7F445 2022-12-28 [SC] [expires: 2027-12-27]
22D465F2B4C173803B20C6DE59FCF207FEA7F445
uid Jia Tan <[email protected]>
sig 0x59FCF207FEA7F445 2022-12-28 [selfsig]
sub rsa4096/0x63CCE556C94DDA4F 2022-12-28 [E] [expires: 2027-12-27]
sig 0x59FCF207FEA7F445 2022-12-28 [keybind]
pub rsa4096/0x59FCF207FEA7F445 2022-12-28 [SC] [expires: 2027-12-27]
22D465F2B4C173803B20C6DE59FCF207FEA7F445
uid Jia Tan <[email protected]>
sig 0x59FCF207FEA7F445 2022-12-28 [selfsig]
sig 0x38EE757D69184620 2024-01-12 Lasse Collin <[email protected]>
sub rsa4096/0x63CCE556C94DDA4F 2022-12-28 [E] [expires: 2027-12-27]
sig 0x59FCF207FEA7F445 2022-12-28 [keybind]
pub rsa4096/0x38EE757D69184620 2010-10-24 [SC] [expires: 2025-02-07]
3690C240CE51B4670D30AD1C38EE757D69184620
uid Lasse Collin <[email protected]>
sig 0x38EE757D69184620 2024-01-08 [selfsig]
sig 0x59FCF207FEA7F445 2024-01-12 Jia Tan <[email protected]>
sub rsa4096/0x5923A9D358ADF744 2010-10-24 [E] [expires: 2025-02-07]
sig 0x38EE757D69184620 2024-01-08 [keybind]We need to get these complex & bloated build-systems under control.
What we need is to move away from 1970s build tools.
所有这些几个月前突然上传的旧版本（4.x、5.0.x 等）可能也应该被视为可疑：https://github.com/tukaani-project/tukaani-project.github.io...
Pretty much proof that OSS != automatically more secure. And proof that OSS projects can get backdoored. See this for more ideas on this issue: https://seirdy.one/posts/2022/02/02/floss-security/
该恶意软件隐藏在不透明的二进制文件中。如果有的话，这表明我们需要更多的开源和更多的可重复性。
Was Debian 12/stable unaffected? Only sid?
My understanding is that that's correct. I'm on fully upgraded stable (Debian 12) and my xz is 5.4.2 and liblzma as well.
Maybe it's finally time to start sunsetting LZMA and xz all together in favor of newer algorithms like Zstandard that also offer better performance but compression rates on par with LZMA.
Yes but don’t start thinking they’re immune to compromise
Nobody is. But it's a great opportunity window.
> I am *not* a security researcher, nor a reverse engineer.
Could have fooled me - impressive write-up!
Could have fooled me - impressive write-up!
Damn. I'm on macOS and use homebrew. To my surprise I had "xz" version 6.5.1 installed on my computer!
I ran "brew upgrade" and that downgraded to version 5.4.6.
I ran "brew upgrade" and that downgraded to version 5.4.6.
同一作者在 libarchive 上可能存在恶意提交：https://github.com/libarchive/libarchive/pull/1609
Is there already a list of distributions that included the affected versions in non-prereelase channels?
None that I could find have included it. Not even NixOS 23.11.
Wouldn’t be surprised that the ssh auth being made slower was deliberate - that makes it fairly easy to index all open ssh servers on the internet, then to see which ones get slower to fail preauth as they install the backdoor
Looks like GitHub has suspended access to the repository, which while it protects against people accidentally compiling and using the code, but certainly complicates forensic analysis for anyone who doesn't have a clone or access to history (which is what I think a lot of people will be doing now to understand their exposure).
Well that's inconvenient, I was (probably, time permitting) going to propose to some of my friends that we attempt to reverse this for fun tomorrow.
Anyone have a link to the git history? I guess we can use the ubuntu tarball for the evil version.
Anyone have a link to the git history? I guess we can use the ubuntu tarball for the evil version.
It looks like git clone https://git.tukaani.org/xz.git still works for now (note: you will obviously be cloning malware if you do this) - that is, however, trusting the project infrastructure that compromised maintainers could have had access to, so I'm not sure if it is unmodified.
HEAD (git rev-parse HEAD) on my result of doing that is currently 0b99783d63f27606936bb79a16c52d0d70c0b56f, and it does have commits people have referenced as being part of the backdoor in it.
HEAD (git rev-parse HEAD) on my result of doing that is currently 0b99783d63f27606936bb79a16c52d0d70c0b56f, and it does have commits people have referenced as being part of the backdoor in it.
显然，有一个 git 存储库的回溯机，它“巧合”地在新闻爆发的前一天存档了这个存储库：
https://archive.softwareheritage.org/browse/origin/visits/?o...
https://archive.softwareheritage.org/browse/origin/visits/?o...
For bad-3-corrupt_lzma2.xz, the claim was that "the original files were generated with random local to my machine. To better reproduce these files in the future, a constant seed was used to recreate these files." with no indication of what the seed was.
I got curious and decided to run 'ent' https://www.fourmilab.ch/random/ to see how likely the data in the bad stream was to be random. I used some python to split the data into 3 streams, since it's supposed to be the middle one that's "bad":
I used this regex to split in python, and wrote to "tmp":
I got curious and decided to run 'ent' https://www.fourmilab.ch/random/ to see how likely the data in the bad stream was to be random. I used some python to split the data into 3 streams, since it's supposed to be the middle one that's "bad":
I used this regex to split in python, and wrote to "tmp":
re.split(b'\xfd7zXZ', x)
$ ent tmp2 # bad file payload
Entropy = 4.157806 bits per byte.
Optimum compression would reduce the size
of this 48 byte file by 48 percent.
Chi square distribution for 48 samples is 1114.67, and randomly
would exceed this value less than 0.01 percent of the times.
Arithmetic mean value of data bytes is 51.4167 (127.5 = random).
Monte Carlo value for Pi is 4.000000000 (error 27.32 percent).
Serial correlation coefficient is 0.258711 (totally uncorrelated = 0.0).
$ ent tmp3 # urandom
Entropy = 5.376629 bits per byte.
Optimum compression would reduce the size
of this 48 byte file by 32 percent.
Chi square distribution for 48 samples is 261.33, and randomly
would exceed this value 37.92 percent of the times.
Arithmetic mean value of data bytes is 127.8125 (127.5 = random).
Monte Carlo value for Pi is 3.500000000 (error 11.41 percent).
Serial correlation coefficient is -0.067038 (totally uncorrelated = 0.0).
Now to be fair, such an archive could have been created with a “store” level of compression that doesn’t actually perform any compression.
My reading of the commit message is they're claiming the "data" should look random.
为什么 Github 禁用了（显然是官方的）xz 存储库，但却向全世界开放了受牵连的帐户？当 GitHub 撤销了每个人查看受影响源代码的访问权限时，解决这个问题变得相当困难。
https://github.com/tukaani-project/xz 与 https://github.com/JiaT75
https://github.com/tukaani-project/xz 与 https://github.com/JiaT75
该帐户已被暂停一段时间，但由于某种原因，该帐户未显示在个人资料本身上（可以在 https://github.com/Larhzu?tab=following 上查看）。禁用存储库是较新的事情，虽然令人烦恼且实际上可能毫无意义，但删除包含真正后门的存储库并不是特别不合理。
Taking down the repo prevents more people inadvertendly pulling and building the backdoor so that makes sense. They should have immediately rehosted and archived the state at a different URL which makes it clear to not use it.
How that backdoor is triggered and what exactly it does?
It seems that to counter this type of supply chain attack, the best practices for managing software dependencies are to pin the version numbers of dependencies instead of using `latest`, and to use static linking instead of dynamic linking.
This gist summarizes the current situation very well: https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...
Definitely looking like they were most likely some sort of state actor. This is very well done and all in plain sight. It's reassuring that it was discovered but given a simple audit of the release build artifacts would have raised alarms, how prevalent is this behavior in other projects? Terrifying stuff.
Definitely looking like they were most likely some sort of state actor. This is very well done and all in plain sight. It's reassuring that it was discovered but given a simple audit of the release build artifacts would have raised alarms, how prevalent is this behavior in other projects? Terrifying stuff.
It doesn't really relate to this issue other than that both issues share a common source, but I wish we'd never fallen for xz.
I agree with the lzip guy
https://www.nongnu.org/lzip/xz_inadequate.html
I agree with the lzip guy
https://www.nongnu.org/lzip/xz_inadequate.html
Looks like Jonathan Blow was right about open source.
Brain fart: would it be possible to attach passwords to a crypto based micro transaction such that every time you attempted a password entry your crypto account was charged a small fee for the login attempt?
This would thwart brute force attacks, but not be a significant cost for users. If you could attach your login to the crypto account it would mean the account would have to be funded to allow the attempt. The token wouldn't store passwords it would just be a gatekeeper to the login attempt.
The fees would be paid to the service providers as mining fees.
E.g. [email protected] needs a password and a token provided from a designated crypto address to gain access to the service.
This would thwart brute force attacks, but not be a significant cost for users. If you could attach your login to the crypto account it would mean the account would have to be funded to allow the attempt. The token wouldn't store passwords it would just be a gatekeeper to the login attempt.
The fees would be paid to the service providers as mining fees.
E.g. [email protected] needs a password and a token provided from a designated crypto address to gain access to the service.
I hope mainstream news cover this so the general population can understand the issue with our software ecoysystems reliance on unpaid open-source maintainers
I worry the mainstream news take would just be "open source bad, microsoft closed source and google cloud good"
xz is so pervasive, I just discovered on my Mac that the (affected?) version 5.6.1 made it into homebrew. The post in the linked article says that only Linux x86-64 systems are affected, but now I'm left scratching my head whether my Mac is also in trouble, just that we don't know it yet.
为什么 GitHub 不强制“发布”成为源代码和来自 GitHub 操作等的二进制文件的简单存储库 tarball...
我觉得非常讽刺的是，“版本控制”站点不能保证可重现的构建（也不能保证可重现的源！！）
真正的恶棍不是肇事者，而是微软，更是我们所有人。
我觉得非常讽刺的是，“版本控制”站点不能保证可重现的构建（也不能保证可重现的源！！）
真正的恶棍不是肇事者，而是微软，更是我们所有人。
Because then for autoconf codebases you have to commit `./configure` or you have to require that users have autoconf installed and run `autoreconf -fi` first.
Maybe autoconf-using projects should really just require that users have autoconf installed.
Not that that would prevent backdoors, mind you.
Maybe autoconf-using projects should really just require that users have autoconf installed.
Not that that would prevent backdoors, mind you.
If committing configure is objectionable, perhaps there could be "service" repositories that are not directly writable and are guaranteed to be nothing more than the base repo + autoconf cruft used to generate the releases.
Well, for example in jq we do commit bison/flex outputs because for users ensuring that they have the right version of those can be tricky. We could do the same w.r.t. autoconf and its outputs, though again, that won't preclude backdoors.
Yeah, it's less about detecting backdoors specifically and more about having a way to compare releases to build jobs.
提交构建的工件会带来类似的问题：您如何知道提交的工件实际上源自其源？ 或者来自构建工具的非后门版本？ 你好，肯·汤普森的攻击。
我不认为这些问题有一个简单的答案。
我们在 jq 中所做的就是依靠 GitHub Actions 来运行构建和“make dist”。 事实上，我们现在也可以停止提交 bison/flex 输出，因为我们可以确保 tarball 包含它们。
我们还发布了 GitHub 自动为版本生成的 git repo 快照，尽管我们这样做是因为 GitHub 不给人们选择的余地。
我不认为这些问题有一个简单的答案。
我们在 jq 中所做的就是依靠 GitHub Actions 来运行构建和“make dist”。 事实上，我们现在也可以停止提交 bison/flex 输出，因为我们可以确保 tarball 包含它们。
我们还发布了 GitHub 自动为版本生成的 git repo 快照，尽管我们这样做是因为 GitHub 不给人们选择的余地。
多思考一下：也许 GitHub 控制“发布”存储库会有一些好处，而这些存储库可能只能编写为 GA。他们会写下所有内容——也许作为一个 docker 镜像——这样任何人都可以拉下镜像并比较 shas，或者其他什么。也许他们的竞争对手也可以做到这一点。最终目标是让多个受信任方在相同的代码上执行构建，产生相同的输出，并允许任何随机数执行相同的操作。
如果源包含在这些图像中，我们就可以证明目标是基于源的。
这确实不容易，也不容易。
如果源包含在这些图像中，我们就可以证明目标是基于源的。
这确实不容易，也不容易。
思想观念太僵化。有无数的东西最适合属于发布文件而不是源代码，它们不能通过 github 操作从该源代码生成，并且单独不应强迫任何人使用 github 操作。
Is there a proper reverse engineering of the payload yet?
用户在向 microsoft/vcpkg 发出的问题中提供了 5.6.0 和 5.4.5
5.4.5 可能受到损害
https://github.com/microsoft/vcpkg/issues/37197
5.4.5 可能受到损害
https://github.com/microsoft/vcpkg/issues/37197
we should take this diagram and change "random person in nebraska" to "possibly a state-level attacker"
https://xkcd.com/2347/
nice
https://xkcd.com/2347/
nice
Github 将可疑存储库设为私有并隐藏最近的帐户活动是错误的举动，并且正在干扰公民调查工作。
Going forward this will require more than a citizens investigation. Law enforcement will surely be granted access. Also, tarballs are still available in package managers if you really want to dig into the code.
It's a crime scene. It effectively has the "police" yellow tape around it.
There's a bug in the detection script. The line:
if [ "$path" == "" ]
should be
if [ "$path" = "" ]
if [ "$path" == "" ]
should be
if [ "$path" = "" ]
Bash accepts both variants of the equality operator. So it is not a bug.
Here's a handy bash script I threw together to audit any docker containers you might be running on your machine. It's hacky, but will quickly let you know what version, if any, of xz, is running in your docker containers.
``` #!/bin/bash
# Get list of all running Docker containers containers=$(docker ps --format "{{.Names}}")
# Loop through each container for container in $containers; do # Get container image image=$(docker inspect --format='{{.Config.Image}}' "$container")
echo "Output written to docker_container_versions.txt" ```
``` #!/bin/bash
# Get list of all running Docker containers containers=$(docker ps --format "{{.Names}}")
# Loop through each container for container in $containers; do # Get container image image=$(docker inspect --format='{{.Config.Image}}' "$container")
# Execute xz --version inside the container
version=$(docker exec "$container" xz --version)
# Write container name, image, and command output to a text file
echo "Container: $container" >> docker_container_versions.txt
echo "Image: $image" >> docker_container_versions.txt
echo "xz Version:" >> docker_container_versions.txt
echo "$version" >> docker_container_versions.txt
echo "" >> docker_container_versions.txt
echo "Output written to docker_container_versions.txt" ```
Notes on time stamps and time zones.
A few interesting bits that I haven't fully fleshed out. TLDR: Some people have been throwing around that Jia is from “China,” but it seems also quite possible that Jia is from somewhere in Eastern Europe pretending to be from China. In addition, Lasse Collin and Hans Jansen are from the same EET time zone.
The following analysis was conducted on JiaT75’s (https://github.com/JiaT75?tab=overview&from=2021-12-01&to=20...) commits to the XZ repository, and their time stamps.
Observation 1: Time zone basic analysis
Here is the data on Jia’s time zone and the number of times he was recorded in that time zone: 3: + 0200 (in winter: February and November) 6: +0300 (in summer: in Jun, Jul, early October) 440: +0800
1. The +800 is likely CST. China (or Indonesia or Philippines), given that Australia does daylight savings time and almost no one lives in Siberia and the Gobi dessert. 2. The +0200/+0300, if we are assuming that this is one location, is likely on EET (Finland, Estonia, Latvia, Lithuania, Ukraine, Moldavia, Romania, Bulgaria, Greece, Turkey). This is because we see a switch from +300 in the winter (past the last weekend of October) and +200 in the summer (past the last Sunday in March). 1. Incidentally, this seems to be the same time zone as Lasse Collin and Hans Jansen…
Observation 2: Time zone inconsistencies
Let’s analyze the few times where Jia was recorded in a non +800 time zone. Here, we notice that there are some situations where Jia switches between +800 and +300/+200 in a seemingly implausible time. Indicating that perhaps he is not actually in +800 CST time, as his profile would like us to believe.
Jia Tan Tue, 27 Jun 2023 23:38:32 +0800 —> 23:38 + 8 = 7:30 (+ 1) Jia Tan Tue, 27 Jun 2023 17:27:09 +0300 —> 17:27 + 3 = 20:30 —> about a 9 hour difference, but a flight from China to anywhere in Eastern Europe is at a min 10 hours
Jia Tan Thu, 5 May 2022 20:53:42 +0800 Jia Tan Sat, 19 Nov 2022 23:18:04 +0800 Jia Tan Mon, 7 Nov 2022 16:24:14 +0200 Jia Tan Sun, 23 Oct 2022 21:01:08 +0800 Jia Tan Thu, 6 Oct 2022 21:53:09 +0300 —> 21:53 + 3 = 1:00 (+1) Jia Tan Thu, 6 Oct 2022 17:00:38 +0800 —> 17:00 + 8 = 1:00 (+1) Jia Tan Wed, 5 Oct 2022 23:54:12 +0800 Jia Tan Wed, 5 Oct 2022 20:57:16 +0800 —> again, given the flight time, this is even more impossible
Jia Tan Fri, 2 Sep 2022 20:18:55 +0800 Jia Tan Thu, 8 Sep 2022 15:07:00 +0300 Jia Tan Mon, 25 Jul 2022 18:30:05 +0300 Jia Tan Mon, 25 Jul 2022 18:20:01 +0300 Jia Tan Fri, 1 Jul 2022 21:19:26 +0800 Jia Tan Thu, 16 Jun 2022 17:32:19 +0300 Jia Tan Mon, 13 Jun 2022 20:27:03 +0800 —> the ordering of these time stamps and the switching back and forth between time zones looks strange.
Jia Tan Thu, 15 Feb 2024 22:26:43 +0800 Jia Tan Thu, 15 Feb 2024 01:53:40 +0800 Jia Tan Mon, 12 Feb 2024 17:09:10 +0200 Jia Tan Mon, 12 Feb 2024 17:09:10 +0200 Jia Tan Tue, 13 Feb 2024 22:38:58 +0800 —> this travel time is possible, but the duration of stay is unlikely
Observation 3: Strange record of time stamps
It seems that from the commits, often the time stamps are out of order. I am not sure what would cause this other than some tampering.
Observation 4: Bank holiday inconsistencies
We notice that Jia’s work schedule and holidays seems to align much better with an Eastern European than a Chinese person.
Disclaimer: I am not an expert in Chinese holidays, so this very well could be inaccurate. I am referencing this list of bank holidays:(https://www.bankofchina.co.id/en-id/service/information/late...)
Chinese bank holidays (just looking at 2023): - Working on 2023, 29 September: Mid Autumn Festival - Working on 2023, 05 April: Tomb Sweeping Day - Working on 2023, 26, 22, 23, 24, 26, 27 Jan: Lunar New Year
Eastern European holidays: - Never working on Dec 25: Christmas (for many EET countries) - Never working Dec 31 or Jan 1: New Years
Observation 5: Little weekend work —> salary job?
The most common working days for Jia were Tue (86), Wed (85), Thu (89), and Fri (79). If we adjust his time zone to EET, then that means he is usually working 9 am to 6 pm. This makes much more sense than someone working at midnight and 1 am on a Tuesday night.
These times also line up well with Hans Jansen and Lasse Collin.
I think it is more likely that Jia does this as part of his work… somewhere in Eastern Europe. Likely working with, or in fact being one and the same as, Hans Jansen and Lasse Collin.
A few interesting bits that I haven't fully fleshed out. TLDR: Some people have been throwing around that Jia is from “China,” but it seems also quite possible that Jia is from somewhere in Eastern Europe pretending to be from China. In addition, Lasse Collin and Hans Jansen are from the same EET time zone.
The following analysis was conducted on JiaT75’s (https://github.com/JiaT75?tab=overview&from=2021-12-01&to=20...) commits to the XZ repository, and their time stamps.
Observation 1: Time zone basic analysis
Here is the data on Jia’s time zone and the number of times he was recorded in that time zone: 3: + 0200 (in winter: February and November) 6: +0300 (in summer: in Jun, Jul, early October) 440: +0800
1. The +800 is likely CST. China (or Indonesia or Philippines), given that Australia does daylight savings time and almost no one lives in Siberia and the Gobi dessert. 2. The +0200/+0300, if we are assuming that this is one location, is likely on EET (Finland, Estonia, Latvia, Lithuania, Ukraine, Moldavia, Romania, Bulgaria, Greece, Turkey). This is because we see a switch from +300 in the winter (past the last weekend of October) and +200 in the summer (past the last Sunday in March). 1. Incidentally, this seems to be the same time zone as Lasse Collin and Hans Jansen…
Observation 2: Time zone inconsistencies
Let’s analyze the few times where Jia was recorded in a non +800 time zone. Here, we notice that there are some situations where Jia switches between +800 and +300/+200 in a seemingly implausible time. Indicating that perhaps he is not actually in +800 CST time, as his profile would like us to believe.
Jia Tan Tue, 27 Jun 2023 23:38:32 +0800 —> 23:38 + 8 = 7:30 (+ 1) Jia Tan Tue, 27 Jun 2023 17:27:09 +0300 —> 17:27 + 3 = 20:30 —> about a 9 hour difference, but a flight from China to anywhere in Eastern Europe is at a min 10 hours
Jia Tan Thu, 5 May 2022 20:53:42 +0800 Jia Tan Sat, 19 Nov 2022 23:18:04 +0800 Jia Tan Mon, 7 Nov 2022 16:24:14 +0200 Jia Tan Sun, 23 Oct 2022 21:01:08 +0800 Jia Tan Thu, 6 Oct 2022 21:53:09 +0300 —> 21:53 + 3 = 1:00 (+1) Jia Tan Thu, 6 Oct 2022 17:00:38 +0800 —> 17:00 + 8 = 1:00 (+1) Jia Tan Wed, 5 Oct 2022 23:54:12 +0800 Jia Tan Wed, 5 Oct 2022 20:57:16 +0800 —> again, given the flight time, this is even more impossible
Jia Tan Fri, 2 Sep 2022 20:18:55 +0800 Jia Tan Thu, 8 Sep 2022 15:07:00 +0300 Jia Tan Mon, 25 Jul 2022 18:30:05 +0300 Jia Tan Mon, 25 Jul 2022 18:20:01 +0300 Jia Tan Fri, 1 Jul 2022 21:19:26 +0800 Jia Tan Thu, 16 Jun 2022 17:32:19 +0300 Jia Tan Mon, 13 Jun 2022 20:27:03 +0800 —> the ordering of these time stamps and the switching back and forth between time zones looks strange.
Jia Tan Thu, 15 Feb 2024 22:26:43 +0800 Jia Tan Thu, 15 Feb 2024 01:53:40 +0800 Jia Tan Mon, 12 Feb 2024 17:09:10 +0200 Jia Tan Mon, 12 Feb 2024 17:09:10 +0200 Jia Tan Tue, 13 Feb 2024 22:38:58 +0800 —> this travel time is possible, but the duration of stay is unlikely
Observation 3: Strange record of time stamps
It seems that from the commits, often the time stamps are out of order. I am not sure what would cause this other than some tampering.
Observation 4: Bank holiday inconsistencies
We notice that Jia’s work schedule and holidays seems to align much better with an Eastern European than a Chinese person.
Disclaimer: I am not an expert in Chinese holidays, so this very well could be inaccurate. I am referencing this list of bank holidays:(https://www.bankofchina.co.id/en-id/service/information/late...)
Chinese bank holidays (just looking at 2023): - Working on 2023, 29 September: Mid Autumn Festival - Working on 2023, 05 April: Tomb Sweeping Day - Working on 2023, 26, 22, 23, 24, 26, 27 Jan: Lunar New Year
Eastern European holidays: - Never working on Dec 25: Christmas (for many EET countries) - Never working Dec 31 or Jan 1: New Years
Observation 5: Little weekend work —> salary job?
The most common working days for Jia were Tue (86), Wed (85), Thu (89), and Fri (79). If we adjust his time zone to EET, then that means he is usually working 9 am to 6 pm. This makes much more sense than someone working at midnight and 1 am on a Tuesday night.
These times also line up well with Hans Jansen and Lasse Collin.
I think it is more likely that Jia does this as part of his work… somewhere in Eastern Europe. Likely working with, or in fact being one and the same as, Hans Jansen and Lasse Collin.
TLDR：有些人一直在谈论“中国”，但贾似乎也很有可能来自东欧某个地方，假装来自中国。此外，Lasse Collin 和 Hans Jansen 来自同一 EET 时区。
这些是我关于时间戳/区域的笔记。有一些有趣的部分我还没有完全充实。
以下分析是针对 JiaT75 (https://github.com/JiaT75?tab=overview&from=2021-12-01&to=20...) 对 XZ 存储库的提交及其时间戳进行的。
观察一：时区基本分析
以下是贾所在时区的数据以及他在该时区被记录的次数：
3：+ 0200（冬季：二月和十一月）
6：+0300（夏季：六月、七月、十月初）
440：+0800
1. +800 可能是 CST。中国（或印度尼西亚或菲律宾），因为澳大利亚实行夏令时，而且几乎没有人住在西伯利亚和戈壁沙漠。
2. 如果我们假设这是一个位置，+0200/+0300 可能位于 EET（芬兰、爱沙尼亚、拉脱维亚、立陶宛、乌克兰、摩尔达维亚、罗马尼亚、保加利亚、希腊、土耳其）。这是因为我们看到冬季（十月最后一个周末之后）的 +300 和夏季（三月最后一个周日之后）的 +200 发生了变化。
顺便说一句，这似乎与 Lasse Collin 和 Hans Jansen 是同一时区……
观察 2：时区不一致
我们来分析一下贾在非+800时区录制的几次。在这里，我们注意到，在某些情况下，贾在看似难以置信的时间内在+800和+300/+200之间切换。表明他可能实际上并不处于 +800 CST 时间，正如他的个人资料希望我们相信的那样。
家谈 2023 年 6 月 27 日星期二 23:38:32 +0800 —> 23:38 + 8 = 7:30 (+ 1)
家谈 2023 年 6 月 27 日星期二 17:27:09 +0300 —> 17:27 + 3 = 20:30
—> 时差约 9 小时，但从中国飞往东欧任何地方的航班最短 10 小时
贾坦 2022 年 5 月 5 日星期四 20:53:42 +0800
贾坦 2022 年 11 月 19 日 星期六 23:18:04 +0800
贾谈 2022 年 11 月 7 日星期一 16:24:14 +0200
孙嘉 2022 年 10 月 23 日 21:01:08 +0800
贾坦 2022 年 10 月 6 日星期四 21:53:09 +0300 —> 21:53 + 3 = 1:00 (+1)
嘉坦 2022 年 10 月 6 日星期四 17:00:38 +0800 —> 17:00 + 8 = 1:00 (+1)
谭嘉 2022 年 10 月 5 日星期三 23:54:12 +0800
谭嘉 2022 年 10 月 5 日星期三 20:57:16 +0800
—> 再说一遍，考虑到飞行时间，这更不可能
谭嘉 2022 年 9 月 2 日星期五 20:18:55 +0800
贾坦 2022 年 9 月 8 日星期四 15:07:00 +0300
谭家 2022 年 7 月 25 日星期一 18:30:05 +0300
谭家 2022 年 7 月 25 日星期一 18:20:01 +0300
谭嘉 2022 年 7 月 1 日星期五 21:19:26 +0800
贾坦 2022 年 6 月 16 日星期四 17:32:19 +0300
贾坦 星期一，2022 年 6 月 13 日 20:27:03 +0800
—> 这些时间戳的顺序以及来回切换看起来很奇怪。
贾坦 2024 年 2 月 15 日星期四 22:26:43 +0800
贾坦 2024 年 2 月 15 日星期四 01:53:40 +0800
谭家 2024 年 2 月 12 日星期一 17:09:10 +0200
谭家 2024 年 2 月 12 日星期一 17:09:10 +0200
家谈 2024 年 2 月 13 日星期二 22:38:58 +0800
—> 这个旅行时间是可能的，但停留时间不太可能
观察3：奇怪的时间戳记录
从提交看来，时间戳通常是无序的。除了一些篡改之外，我不确定什么会导致这种情况。
观察 4：银行假日不一致
我们注意到，贾的工作安排和假期似乎更适合东欧人，而不是中国人。
免责声明：我不是中国节日方面的专家，所以这很可能是不准确的。我参考的是bak假期列表：(https://www.bankofchina.co.id/en-id/service/information/late...)
中国银行假期（仅查看 2023 年）：
- 2023年工作，9月29日：中秋节
- 2023 年工作，4 月 5 日：清明节
- 2023年1月26日、22日、23日、24日、26日、27日：农历新年
东欧假期：
- 12 月 25 日圣诞节期间不工作（对于许多 EET 国家/地区）
- 12 月 31 日或 1 月 1 日从不工作：新年
观察5：没有周末工作——>带薪工作？
贾最常见的工作日是周二（86）、周三（85）、周四（89）和周五（79）。如果我们把他的时区调整为 EET，那就意味着他通常工作时间是上午 9 点到下午 6 点。这比周二晚上午夜和凌晨 1 点工作更有意义。
这些时间也与汉斯·詹森和莱塞·科林相符。
我认为贾跃亭更有可能将这作为他工作的一部分……在东欧的某个地方。很可能与汉斯·詹森和莱塞·科林一起工作，或者实际上是同一个人。
这些是我关于时间戳/区域的笔记。有一些有趣的部分我还没有完全充实。
以下分析是针对 JiaT75 (https://github.com/JiaT75?tab=overview&from=2021-12-01&to=20...) 对 XZ 存储库的提交及其时间戳进行的。
观察一：时区基本分析
以下是贾所在时区的数据以及他在该时区被记录的次数：
3：+ 0200（冬季：二月和十一月）
6：+0300（夏季：六月、七月、十月初）
440：+0800
1. +800 可能是 CST。中国（或印度尼西亚或菲律宾），因为澳大利亚实行夏令时，而且几乎没有人住在西伯利亚和戈壁沙漠。
2. 如果我们假设这是一个位置，+0200/+0300 可能位于 EET（芬兰、爱沙尼亚、拉脱维亚、立陶宛、乌克兰、摩尔达维亚、罗马尼亚、保加利亚、希腊、土耳其）。这是因为我们看到冬季（十月最后一个周末之后）的 +300 和夏季（三月最后一个周日之后）的 +200 发生了变化。
顺便说一句，这似乎与 Lasse Collin 和 Hans Jansen 是同一时区……
观察 2：时区不一致
我们来分析一下贾在非+800时区录制的几次。在这里，我们注意到，在某些情况下，贾在看似难以置信的时间内在+800和+300/+200之间切换。表明他可能实际上并不处于 +800 CST 时间，正如他的个人资料希望我们相信的那样。
家谈 2023 年 6 月 27 日星期二 23:38:32 +0800 —> 23:38 + 8 = 7:30 (+ 1)
家谈 2023 年 6 月 27 日星期二 17:27:09 +0300 —> 17:27 + 3 = 20:30
—> 时差约 9 小时，但从中国飞往东欧任何地方的航班最短 10 小时
贾坦 2022 年 5 月 5 日星期四 20:53:42 +0800
贾坦 2022 年 11 月 19 日 星期六 23:18:04 +0800
贾谈 2022 年 11 月 7 日星期一 16:24:14 +0200
孙嘉 2022 年 10 月 23 日 21:01:08 +0800
贾坦 2022 年 10 月 6 日星期四 21:53:09 +0300 —> 21:53 + 3 = 1:00 (+1)
嘉坦 2022 年 10 月 6 日星期四 17:00:38 +0800 —> 17:00 + 8 = 1:00 (+1)
谭嘉 2022 年 10 月 5 日星期三 23:54:12 +0800
谭嘉 2022 年 10 月 5 日星期三 20:57:16 +0800
—> 再说一遍，考虑到飞行时间，这更不可能
谭嘉 2022 年 9 月 2 日星期五 20:18:55 +0800
贾坦 2022 年 9 月 8 日星期四 15:07:00 +0300
谭家 2022 年 7 月 25 日星期一 18:30:05 +0300
谭家 2022 年 7 月 25 日星期一 18:20:01 +0300
谭嘉 2022 年 7 月 1 日星期五 21:19:26 +0800
贾坦 2022 年 6 月 16 日星期四 17:32:19 +0300
贾坦 星期一，2022 年 6 月 13 日 20:27:03 +0800
—> 这些时间戳的顺序以及来回切换看起来很奇怪。
贾坦 2024 年 2 月 15 日星期四 22:26:43 +0800
贾坦 2024 年 2 月 15 日星期四 01:53:40 +0800
谭家 2024 年 2 月 12 日星期一 17:09:10 +0200
谭家 2024 年 2 月 12 日星期一 17:09:10 +0200
家谈 2024 年 2 月 13 日星期二 22:38:58 +0800
—> 这个旅行时间是可能的，但停留时间不太可能
观察3：奇怪的时间戳记录
从提交看来，时间戳通常是无序的。除了一些篡改之外，我不确定什么会导致这种情况。
观察 4：银行假日不一致
我们注意到，贾的工作安排和假期似乎更适合东欧人，而不是中国人。
免责声明：我不是中国节日方面的专家，所以这很可能是不准确的。我参考的是bak假期列表：(https://www.bankofchina.co.id/en-id/service/information/late...)
中国银行假期（仅查看 2023 年）：
- 2023年工作，9月29日：中秋节
- 2023 年工作，4 月 5 日：清明节
- 2023年1月26日、22日、23日、24日、26日、27日：农历新年
东欧假期：
- 12 月 25 日圣诞节期间不工作（对于许多 EET 国家/地区）
- 12 月 31 日或 1 月 1 日从不工作：新年
观察5：没有周末工作——>带薪工作？
贾最常见的工作日是周二（86）、周三（85）、周四（89）和周五（79）。如果我们把他的时区调整为 EET，那就意味着他通常工作时间是上午 9 点到下午 6 点。这比周二晚上午夜和凌晨 1 点工作更有意义。
这些时间也与汉斯·詹森和莱塞·科林相符。
我认为贾跃亭更有可能将这作为他工作的一部分……在东欧的某个地方。很可能与汉斯·詹森和莱塞·科林一起工作，或者实际上是同一个人。
This 2011 addition to the XZ Utils Wikipedia page is interesting because a) why is this relevant, b) who is Mike Kezner since he's not mentioned on the Tukaani project page (https://tukaani.org/about.html) under "Historical acknowledgments".
https://en.wikipedia.org/w/index.php?title=XZ_Utils&diff=pre...
Arch Linux played an important role in making this compression software trusted and depended upon. Perhaps not a coincidence, but at the very least, such a big project should more carefully consider the software they distribute and rely on, whether it's worth the risk.
https://en.wikipedia.org/w/index.php?title=XZ_Utils&diff=pre...
Arch Linux played an important role in making this compression software trusted and depended upon. Perhaps not a coincidence, but at the very least, such a big project should more carefully consider the software they distribute and rely on, whether it's worth the risk.
> Arch Linux played an important role in making this compression software trusted and depended upon.
because of the way arch distributes packages? then what you think about freebsd?
because of the way arch distributes packages? then what you think about freebsd?
If you check the history of that IP address, it added Mike Kezner to other pages.
No clue why.
You say yourself that the time data could be tampered. It's trivial to change commit dates in git. So this analysis means nothing by itself, unfortunately.
I wouldn't say that. This guy seems to have tried hard to appear Chinese (and possibly tampered the time stamps this way) – but based on that analysis, it seems plausible they did a bad job and were actually based out of Eastern Europe.
Made a more detailed write-up on this: https://rheaeve.substack.com/p/xz-backdoor-times-damned-time...
我根据Jia的Github头像图询问ChatGPT 4：
ChatGPT 认为头像来自的时区与 +2 和 +3 一致，看看它的排名如何，最后是贾的头像描述：
---
排名、分数、国家、城市、时区、标准
1, 10，沙特阿拉伯，麦加，AST (UTC+3)，伊斯兰教的中心地带，根深蒂固的书法传统。
2, 9.5, 伊朗，德黑兰，IRST (UTC+3:30)，具有独特风格和历史的完整波斯书法。
3、9，土耳其，伊斯坦布尔，TRT (UTC+3)，奥斯曼书法的历史意义，积极保存。
4, 8.5, 埃及, 开罗, EET (UTC+2), 爱资哈尔大学所在地, 课程中有书法。
5, 8, 摩洛哥，马拉喀什，WET (UTC+0)，书法融入建筑和手工艺。
6, 7.5, 阿拉伯联合酋长国，阿布扎比，GST (UTC+4)，通过节日和博物馆推广伊斯兰艺术。
7, 7，叙利亚，大马士革，欧洲东部时间 (UTC+2)，阿拉伯书法的历史中心，尽管最近发生了冲突。
8, 6.5, 巴基斯坦，伊斯兰堡，PKT (UTC+5)，丰富的传统，举办多个致力于书法的机构和活动。
9, 6，印度尼西亚，雅加达，WIB (UTC+7)，最大的穆斯林占多数的国家，拥有书法艺术和纪念碑。
10, 5.5, 西班牙, 科尔多瓦, CET (UTC+1), 伊斯兰文化的遗产和书法欣赏，特别是在安达卢西亚。
--
GPT4：该图像似乎是字母“J”在复杂边框内的程式化表示，可能受到伊斯兰书法艺术风格的启发。华丽的背景是典型的阿拉伯式花纹图案，这是伊斯兰艺术的特征，由重复的几何形式组成，通常与植物、花卉的形状相呼应，有时还与书法文字的形状相呼应。字母“J”以鲜艳的黄色脱颖而出，与周围设计的深绿色形成鲜明对比。
ChatGPT 认为头像来自的时区与 +2 和 +3 一致，看看它的排名如何，最后是贾的头像描述：
---
排名、分数、国家、城市、时区、标准
1, 10，沙特阿拉伯，麦加，AST (UTC+3)，伊斯兰教的中心地带，根深蒂固的书法传统。
2, 9.5, 伊朗，德黑兰，IRST (UTC+3:30)，具有独特风格和历史的完整波斯书法。
3、9，土耳其，伊斯坦布尔，TRT (UTC+3)，奥斯曼书法的历史意义，积极保存。
4, 8.5, 埃及, 开罗, EET (UTC+2), 爱资哈尔大学所在地, 课程中有书法。
5, 8, 摩洛哥，马拉喀什，WET (UTC+0)，书法融入建筑和手工艺。
6, 7.5, 阿拉伯联合酋长国，阿布扎比，GST (UTC+4)，通过节日和博物馆推广伊斯兰艺术。
7, 7，叙利亚，大马士革，欧洲东部时间 (UTC+2)，阿拉伯书法的历史中心，尽管最近发生了冲突。
8, 6.5, 巴基斯坦，伊斯兰堡，PKT (UTC+5)，丰富的传统，举办多个致力于书法的机构和活动。
9, 6，印度尼西亚，雅加达，WIB (UTC+7)，最大的穆斯林占多数的国家，拥有书法艺术和纪念碑。
10, 5.5, 西班牙, 科尔多瓦, CET (UTC+1), 伊斯兰文化的遗产和书法欣赏，特别是在安达卢西亚。
--
GPT4：该图像似乎是字母“J”在复杂边框内的程式化表示，可能受到伊斯兰书法艺术风格的启发。华丽的背景是典型的阿拉伯式花纹图案，这是伊斯兰艺术的特征，由重复的几何形式组成，通常与植物、花卉的形状相呼应，有时还与书法文字的形状相呼应。字母“J”以鲜艳的黄色脱颖而出，与周围设计的深绿色形成鲜明对比。
Interesting :). However, I think that EET is the only time zone that works. (This is mostly because is seems that the area follows DST, which most non western countries in the worlf do not).
[deleted]
[deleted]
Well isn't this an interesting commit. He finished his inject macro to compose the payload at build, so now he can start clearing up the repo so none of that shit gets seen when cruising through it.
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=4323bc3e0c1...
https://git.tukaani.org/?p=xz.git;a=commitdiff;h=4323bc3e0c1...
On Ubuntu there is a bug report asking to sync the 5.6 version from Debian experimental https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2055...
前几天登上 HN 头版[1]的“pack”[0]压缩实用程序现在给我敲响了警钟。 （当时也是如此，但现在更是如此）
它是用 Pascal 编写的，唯一（半）记录的自己构建它的方法是使用图形 IDE，并拉入预编译的库二进制文件（存储在依赖项的 git 存储库中，afaict Pack 是唯一的依赖项 - 似乎由同一假名作者维护，但来自不同的帐户）。
我提出了一个问题[2]，概述了我的担忧。我当然不是在指责他们有后门二进制文件，但如果我要建立一个故意有后门的项目，它看起来很像这样。
[0] https://pack.ac/
[1] https://news.ycombinator.com/item?id=39793805
[2] https://github.com/PackOrganization/Pack/issues/10
它是用 Pascal 编写的，唯一（半）记录的自己构建它的方法是使用图形 IDE，并拉入预编译的库二进制文件（存储在依赖项的 git 存储库中，afaict Pack 是唯一的依赖项 - 似乎由同一假名作者维护，但来自不同的帐户）。
我提出了一个问题[2]，概述了我的担忧。我当然不是在指责他们有后门二进制文件，但如果我要建立一个故意有后门的项目，它看起来很像这样。
[0] https://pack.ac/
[1] https://news.ycombinator.com/item?id=39793805
[2] https://github.com/PackOrganization/Pack/issues/10
Maybe @JiaT75 got forced to do it. Maybe someone has more personal contact with him and can check how he is doing.
Incredible. It's like discovering your colleague for 2 years at the secret nuclear weapon facility is a spy for another country, covering his tracks until the very last minute. Feels like a Hollywood movie is coming up.
Should we start doing background checks on all committers to such critical IT infrastructure?
Should we start doing background checks on all committers to such critical IT infrastructure?
Not even background check but a foreground check would already help. Like literally, who dis? any identity at all?
Too often maintainers who have no time just blanket approve PRs and see if stuff breaks.
Too often maintainers who have no time just blanket approve PRs and see if stuff breaks.
But how? Let's say you're one of 10 maintainers of an open source project. A new user wants to contribute. What do you do? Do you ask them to send you some form of ID? Assuming this is legal and assuming you could ensure the new user is the actual owner of an actual, non counterfeit ID, what do you do? Do you vet people based on their nationality? If so, what nationality should be blackballed? Maybe 3 maintainers are American, 5 are European and 2 are Chinese. Who gets to decide? Or do you decide based on the company they work for?
Open source is, by definition, open. The PR/merge request process is generally meant to accept or refuse commits based on the content (which is why you have a diff), not on the owner.
Building consensus on which commits are actually valid, even in the face of malicious actors, is a notoriously difficult problem. Byzantine fault tolerance can be achieved with a 2/3 + 1 majority, but if anyone can create new identities and have them join the system (Sybil attack) you're going to have to do things differently.
Open source is, by definition, open. The PR/merge request process is generally meant to accept or refuse commits based on the content (which is why you have a diff), not on the owner.
Building consensus on which commits are actually valid, even in the face of malicious actors, is a notoriously difficult problem. Byzantine fault tolerance can be achieved with a 2/3 + 1 majority, but if anyone can create new identities and have them join the system (Sybil attack) you're going to have to do things differently.
This was only a matter of time. Open source projects are under-staffed, maintainers are overworked and burned out, and everyone relies on the goodwill of all actors.
Obviously a bad actor will make use of these conditions and the assumption of good will.
We need automated tooling to vet for stuff like this. And maybe migrate away from C/C++ while we are at it because they don't make such scanning easy at all.
Obviously a bad actor will make use of these conditions and the assumption of good will.
We need automated tooling to vet for stuff like this. And maybe migrate away from C/C++ while we are at it because they don't make such scanning easy at all.
I hope Lasse Collin is doing OK! Here is a older message from him [1]
"I haven't lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I've worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we'll see.
It's also good to keep in mind that this is an unpaid hobby project. "
Github (Microsoft) are in a unique position to figure out if his account is hacked or not, and find a way to reach him. I hope they reach out and offer him some proper support! Economic support (if that's needed), or just help clearing his name.
This is another tale of how we are building multi trillion dollar industries on the back of unpaid volunteers. It's not github 'job', and many other organisations have benefited even more from Lasses work, but they are in a unique position, and would be literally pocket change for them.
1:https://www.mail-archive.com/[email protected]/msg00567.h...
"I haven't lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I've worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we'll see.
It's also good to keep in mind that this is an unpaid hobby project. "
Github (Microsoft) are in a unique position to figure out if his account is hacked or not, and find a way to reach him. I hope they reach out and offer him some proper support! Economic support (if that's needed), or just help clearing his name.
This is another tale of how we are building multi trillion dollar industries on the back of unpaid volunteers. It's not github 'job', and many other organisations have benefited even more from Lasses work, but they are in a unique position, and would be literally pocket change for them.
1:https://www.mail-archive.com/[email protected]/msg00567.h...
Relevant xkcd:
https://xkcd.com/2347/
https://xkcd.com/2347/
In a movie his mental health issues would likely have been caused intentionally by the attacker, setting the stage for the mole to offer to step in just at the right time. Seems a bit far fetched in this case though for what looks like a tangential attack.
or
> Recently I've worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we'll see.
Is actually Jia Tan has him tied up in a basement and is posing as him. State actors can do that kind of thing.
Is actually Jia Tan has him tied up in a basement and is posing as him. State actors can do that kind of thing.
In that case why bother with the Jia Tan persona at all instead of just pushing the malware as Lasse Collin.
In a movie, he was killed by foreign state actors, and his identity assumed by the foreign state hacker. Actually, someone should check on him.
> what looks like a tangential attack
Does it? I expect that finding someone vulnerable was the more likely approach rather than messing with the life of a stable maintainer, but it does seem very much like the attacker was acting with malicious intent from the start of his interaction with the xz project.
Does it? I expect that finding someone vulnerable was the more likely approach rather than messing with the life of a stable maintainer, but it does seem very much like the attacker was acting with malicious intent from the start of his interaction with the xz project.
Lasse appears to be active and working on undoing the sabotage. https://git.tukaani.org/?p=xz.git;a=blobdiff;f=CMakeLists.tx...
I would start restoring trust by reverting all this guys commits. It's the best way to be sure.
我希望看到对此给予更多关注。我有能力进行划分，不会过度内疚自己，但天哪，我真的希望他一切都好。这会毁了我。
我其实是跟我爸说这件事的。我有一个项目，有 500 多个用户，不完全具有 root 访问权限，但足以造成严重损坏。我可以想到至少一种隐蔽的方法来从中隐藏二进制工件。
大约两年前，有人出现，开始做出良好的承诺。在这种情况下，他们还有其他一些社区代表可以追溯到更远的地方，但是……伙计，这是一种令人不安的感觉。
我其实是跟我爸说这件事的。我有一个项目，有 500 多个用户，不完全具有 root 访问权限，但足以造成严重损坏。我可以想到至少一种隐蔽的方法来从中隐藏二进制工件。
大约两年前，有人出现，开始做出良好的承诺。在这种情况下，他们还有其他一些社区代表可以追溯到更远的地方，但是……伙计，这是一种令人不安的感觉。
> I'm capable of compartmentalization
teach me how. help me learn how, please. any resources with practical utility you can share? or any class of therapists that are good at teaching this with right frameworks offered? thank you
teach me how. help me learn how, please. any resources with practical utility you can share? or any class of therapists that are good at teaching this with right frameworks offered? thank you
Comment from Andres Freund on how and why he found it [0] and more information on the LWN story about the backdoor. Recommend people read this to see how close we came (and think about what this is going to mean for the future).
[0] https://lwn.net/Articles/967194/
[0] https://lwn.net/Articles/967194/
That man deserves a Nobel Prize
that's... creative. and patient. 11/10 concerning - now I'm wondering how many other projects could have shit like this in them or added right as I'm writing this shudder
Jia Tan "cleaned up" in all their ZSTD branches some hours ago, probably hiding something https://github.com/JiaT75/zstd/branches/all
Bad move. Destroying evidence is a felony.
If you are this deep into it, it doesn't matter.
Not everywhere, and only if you can prove that were evidences :)
GitHub/Microsoft 可能有备份。我现在就要把它们拿出来。
chmod u+x running detect_sh script just runs with no output on my arch linux box?
https://www.openwall.com/lists/oss-security/2024/03/29/4
https://www.openwall.com/lists/oss-security/2024/03/29/4
Yes, Arch Linux’s OpenSSH binary doesn’t even link to liblzma, which means your installation is not affected by this particular backdoor.
The authors of the `detect_sh` script didn’t have that scenario in mind, so the `ldd` invocation never finds a link and the script bails early without a message.
The authors of the `detect_sh` script didn’t have that scenario in mind, so the `ldd` invocation never finds a link and the script bails early without a message.
Thanks!
remove the -e option on the script and run it.
Anyway, arch is not affected because they don't modify openssh to link against any of this nonesense.
Anyway, arch is not affected because they don't modify openssh to link against any of this nonesense.
now I wonder which browsers link liblzma?
I wonder which browsers link liblzma and can this lead to https eavesdropping?
It was caught out of luck due to performance degradation. So nobody reads the code - not even once- prior to merging into upstream supply chain?
https://x.com/bl4sty/status/1773780531143925959?s=20
So nobody reads releases notes either.
But I’m sure this was a one off and were safe now
So nobody reads releases notes either.
But I’m sure this was a one off and were safe now
由其他人创建的有问题的存储库的镜像可在 [1] 中找到。 GitHub 应该公开证据（即使只是重命名或以更安全的格式存档），而不是删除/隐藏它。
v5.6.1 的违规 tarball 更容易找到，一个例子是。[2]
m4/.gitignore 于 2 周前更新，以隐藏仅存在于发布 tarball 中的 build-to-host.m4，用于在构建时注入后门。 [3]
[1] https://git.phial.org/d6/xz-analysis-mirror
[2] https://mirrors.xtom.ee/gentoo/distfiles/9f/xz-5.6.1.tar.gz
[3] https://git.phial.org/d6/xz-analysis-mirror/commit/4323bc3e0...
v5.6.1 的违规 tarball 更容易找到，一个例子是。[2]
m4/.gitignore 于 2 周前更新，以隐藏仅存在于发布 tarball 中的 build-to-host.m4，用于在构建时注入后门。 [3]
[1] https://git.phial.org/d6/xz-analysis-mirror
[2] https://mirrors.xtom.ee/gentoo/distfiles/9f/xz-5.6.1.tar.gz
[3] https://git.phial.org/d6/xz-analysis-mirror/commit/4323bc3e0...
There's good discussion of the timeline here: https://boehs.org/node/everything-i-know-about-the-xz-backdo...
Why is the Long Range Zip lrzip compression format not used? It gives better compression than xz when using the correct switches.
State actor or not, let's not ignore that the backdoor has been discovered thanks to the open nature of the projects involved that allowed digging into the code. Just another example like the infamous Borland InterBase backdoor in the early 2K that remained dormant for years and was discovered months after the source code has been released.
If the xz malware authors worked for any corp that produced closed source drivers or blobs that can't be properly audited, we would be fucked; I just hope this is not already happening, because the attack surface in all those devices and appliances out there running closed code is huge.
Sadly this is exactly one of the cases where open source is much more vulnerable to a state actor sponsored attack than proprietary software. (it is also easier to find such backdoors in OS software but that's BTW)
Why? Well, consider this, to "contribute" to a proprietary project you need to get hired by a company, go through their he. Also they have to be hiring in the right team etc. Your operative has to be in a different country, needs a CV that checks out, passports/ids are checked etc.
But to contribute to an OS project? You just need an email address. Your operative sends good contributions until they build trust, then they start introducing backdoors in the part of the code "no one, but them understands".
The cost of such attack is a lot lower for a state actor so we have to assume every single OS project that has a potential to get back doored had many attempts of doing so. (proprietary software too, but as mentioned, this is much more expensive)
So what is the solution? IDK, but enforcing certain "understandability" requirements can be a part of it.
Why? Well, consider this, to "contribute" to a proprietary project you need to get hired by a company, go through their he. Also they have to be hiring in the right team etc. Your operative has to be in a different country, needs a CV that checks out, passports/ids are checked etc.
But to contribute to an OS project? You just need an email address. Your operative sends good contributions until they build trust, then they start introducing backdoors in the part of the code "no one, but them understands".
The cost of such attack is a lot lower for a state actor so we have to assume every single OS project that has a potential to get back doored had many attempts of doing so. (proprietary software too, but as mentioned, this is much more expensive)
So what is the solution? IDK, but enforcing certain "understandability" requirements can be a part of it.
Is that true? Large companies producing software usually have bespoke infra, which barely anyone monitors. See: the Solarwinds hack. Similarly to the xz compromise they added the a Trojan to the binary artifacts by hijacking the build infrastructure. According to Wikipedia "around 18,000 government and private users downloaded compromised versions", it took almost a year for somebody to detect the trojan.
Thanks to the tiered updates of Linux distros, the backdoor was caught in testing releases, and not in stable versions. So only a very low percentage of people were impacted. Also the whole situation happened because distros used the tarball with a "closed source" generated script, instead of generating it themselves from the git repo. Again proving that it's easier to hide stuff in closed source software that nobody inspects.
Same with getting hired. Don't companies hire cheap contractors from Asia? There it would be easy to sneak in some crooked or even fake person to do some dirty work. Personally I was even emailed by a guy from China who asked me if I was willing to "borrow" him my identity so he could work in western companies, and he would share the money with me. Of course I didn't agree, but I'm not sure if everybody whose email he found on Github did.
https://en.wikipedia.org/wiki/2020_United_States_federal_gov...
Thanks to the tiered updates of Linux distros, the backdoor was caught in testing releases, and not in stable versions. So only a very low percentage of people were impacted. Also the whole situation happened because distros used the tarball with a "closed source" generated script, instead of generating it themselves from the git repo. Again proving that it's easier to hide stuff in closed source software that nobody inspects.
Same with getting hired. Don't companies hire cheap contractors from Asia? There it would be easy to sneak in some crooked or even fake person to do some dirty work. Personally I was even emailed by a guy from China who asked me if I was willing to "borrow" him my identity so he could work in western companies, and he would share the money with me. Of course I didn't agree, but I'm not sure if everybody whose email he found on Github did.
https://en.wikipedia.org/wiki/2020_United_States_federal_gov...
> Well, consider this, to "contribute" to a proprietary project you need to get hired by a company, go through their he.
Or work for a third-party company that gets access to critical systems without any checks. See for example the incident from 2022 here: https://en.wikipedia.org/wiki/Okta,_Inc.
Or a third-party that rents critical infrastructure to the company (Cloud, SaaS solutions).
Or work for a third-party company that gets access to critical systems without any checks. See for example the incident from 2022 here: https://en.wikipedia.org/wiki/Okta,_Inc.
Or a third-party that rents critical infrastructure to the company (Cloud, SaaS solutions).
Or exactly this kind of backdoor in open source but target proprietary software. I don't know of any survey but I'd be surprised if less than half of proprietary software used open source software one way or another and not surprised if it was quite a bit more than that.
I think we have to assume that all community software is a target. The payoff for bad actors is too great.
For every one of these we spot, assume there are two we have not.
For every one of these we spot, assume there are two we have not.
Hello,
Github just disabled the repo : https://github.com/tukaani-project/xz
Do someone have an up to date fork to see the project history ?
Github just disabled the repo : https://github.com/tukaani-project/xz
Do someone have an up to date fork to see the project history ?
Is there any news concerning the payload analysis? Just curious to see if it can be correlated with something I have in my sshd logs (e.g. login attempt with specific RSA keys).
由于 GitHub 禁用了存储库..
我上传了来自两个可疑用户及其共享项目存储库的所有 GitHub 事件，作为易于使用的 CSV 文件：
https://github.com/emirkmo/xz-backdoor-github
对于那些想要查看 GitHub 事件（提交、评论、pull_requets、diffs 等）的人
我上传了来自两个可疑用户及其共享项目存储库的所有 GitHub 事件，作为易于使用的 CSV 文件：
https://github.com/emirkmo/xz-backdoor-github
对于那些想要查看 GitHub 事件（提交、评论、pull_requets、diffs 等）的人
Better make a torrent out of them.
Surely the real target of this was Tor (which links liblzma) not random SSH servers.
请注意：这些更改是在 GitHub 强制执行 2FA 后进行的（当然不是为了“更好的安全性”，而是为了促进 FIDO2 和 FIDO2 的 Windows Hello 生物识别实现，请参阅 https://codeberg.org/KOLANICH/Fuck-GuanTEEnomo 了解更多信息。直到最近（目前通过 git 协议访问我的 acc 被阻止，我猜是因为缺乏 2FA 设置）甚至可以推送到人们有权访问的所有存储库即使没有在帐户中启用 2FA，也只需使用单因素 SSH 密钥）。正如我所警告的，当恶意维护者引入后门，或者将其项目出售给广告公司的“聪明企业家”，或者在某个州的范围内生活和赚钱的忠诚“爱国者”，或者只是一个获得了他无法拒绝的要约的无权之人时，没有什么可以保护。一般来说，“合法”维护者对供应链的攻击是无法阻止的。 “Jia Tan”只是一个马甲，旨在减轻维护人员的后果，让他们看起来没有参与其中。他们肯定是。至少根据当前信息，是他们授予恶意帐户代表项目发布版本和访问存储库的权限。
恕我直言，无论怎样，与接受恶意更改有关的后门项目的所有维护者都应被视为同谋并受到抵制。我们不需要证明他们的责任的证据，而是他们需要维护自己的声誉。我们可以根据他们的声誉自由做出决定。即使他们自己被黑了，那也不是我们的问题，而是他们的问题。我们的问题是确保自己的安全。基于一个人可能被欺骗或被黑客攻击的事实而毁掉他的声誉可能会让人觉得“不公正”……但如果一个人可能被欺骗或被黑客攻击，为什么他/她应该像其他人一样拥有如此好的声誉？因此，排除和取代每个人都是很有意义的，对他们来说，无论是出于漠不关心还是出于恶意，都有妥协的证据。但自由和开源软件是一个以饺子价格（0 美元，免费）提供产品的统治机构，对于大多数后门软件来说，这是完全可以接受的，因为他们可以免费获得它们。有能力支付软件费用的强大参与者只会雇佣开发人员来开发他们的私人版本，同时允许公众支付 0 美元购买他们的免费版本并使用自己安装的后门。换句话说，市场彻底失灵。
我认为
1. xz项目必须完全关闭。我的意思是项目应该停止使用它作为依赖项，从发行版中排除，抵制它。 LZMA 算法是由 Igor Pavlov 在 7z 项目中开发的，但不知何故，liblzma 是由不相关的人开发和维护的。 liblzma 应该作为 7z 项目的一部分进行开发，除了来自 xz 的 API 兼容性适配器的简单代码之外，不使用任何代码。
2. 受侵害的作者创建的项目应受到抵制。
3. 应审核受感染的开发人员/维护人员接触的其他项目。
4.所有使用autotools的项目都应该经过审核，并且必须用cmake/meson替换autotools。 Autotools 就是一坨屎，完全无法理解。毫不奇怪，它被用来隐藏后门——根据我在 FOSS 的经验，无论如何没有人喜欢碰它的脚本。
5. 任何项目都不应该从版本构建。项目应该直接从 git 构建。应加速在 git 和 git forges（GitHub、GitLab、Codeberg、sr.ht）中实现 SHA256 的全面支持，以减轻使用冲突替换批准提交的攻击（我猜二进制资源文件（如图片）中的随机性可以从审阅者的眼睛中隐藏起来）。
恕我直言，无论怎样，与接受恶意更改有关的后门项目的所有维护者都应被视为同谋并受到抵制。我们不需要证明他们的责任的证据，而是他们需要维护自己的声誉。我们可以根据他们的声誉自由做出决定。即使他们自己被黑了，那也不是我们的问题，而是他们的问题。我们的问题是确保自己的安全。基于一个人可能被欺骗或被黑客攻击的事实而毁掉他的声誉可能会让人觉得“不公正”……但如果一个人可能被欺骗或被黑客攻击，为什么他/她应该像其他人一样拥有如此好的声誉？因此，排除和取代每个人都是很有意义的，对他们来说，无论是出于漠不关心还是出于恶意，都有妥协的证据。但自由和开源软件是一个以饺子价格（0 美元，免费）提供产品的统治机构，对于大多数后门软件来说，这是完全可以接受的，因为他们可以免费获得它们。有能力支付软件费用的强大参与者只会雇佣开发人员来开发他们的私人版本，同时允许公众支付 0 美元购买他们的免费版本并使用自己安装的后门。换句话说，市场彻底失灵。
我认为
1. xz项目必须完全关闭。我的意思是项目应该停止使用它作为依赖项，从发行版中排除，抵制它。 LZMA 算法是由 Igor Pavlov 在 7z 项目中开发的，但不知何故，liblzma 是由不相关的人开发和维护的。 liblzma 应该作为 7z 项目的一部分进行开发，除了来自 xz 的 API 兼容性适配器的简单代码之外，不使用任何代码。
2. 受侵害的作者创建的项目应受到抵制。
3. 应审核受感染的开发人员/维护人员接触的其他项目。
4.所有使用autotools的项目都应该经过审核，并且必须用cmake/meson替换autotools。 Autotools 就是一坨屎，完全无法理解。毫不奇怪，它被用来隐藏后门——根据我在 FOSS 的经验，无论如何没有人喜欢碰它的脚本。
5. 任何项目都不应该从版本构建。项目应该直接从 git 构建。应加速在 git 和 git forges（GitHub、GitLab、Codeberg、sr.ht）中实现 SHA256 的全面支持，以减轻使用冲突替换批准提交的攻击（我猜二进制资源文件（如图片）中的随机性可以从审阅者的眼睛中隐藏起来）。
It's always Debian, like last time when they removed RNG randomness from ssh because of a warning.
Why isn't he identified personally? Very likely he is 'contributing' to other projects under different accounts.
So when are we going to stop pretending that OSS maintainers/projects are reaping what they sow when they "work for free" and give away their source code away using OSS licensed software, while large companies profit off of them? If they were paid more (or in some cases even actually paid), then they could afford to quit their day jobs, reducing burn out, they could actually hire a team of trusted vetted devs instead of relying on the goodwill of strangers who step up "just to help them out" and they could pay security researchers to vet their code.
Turns out burned out maintainers are a great attack vector and if you are willing to play the long game you can ingratiate yourself with the community with your seemingly innocuous contributions.
Turns out burned out maintainers are a great attack vector and if you are willing to play the long game you can ingratiate yourself with the community with your seemingly innocuous contributions.
Paid people get burnt out as well and they are just as likely to accept free help as an unpaid person.
That's true, but many of these maintainers work a day job on top of doing the open source work precisely because the open source work doesn't pay the bills. If they could get back 40 hours of their time I think many would appreciate it
> So when are we going to stop pretending ...
I'm not sure that we are. Doesn't everybody know that developing/maintaining free software is largely thankless work, with little to no direct recompense?
I don't think moving towards unfree software is a good way to make free software more secure. It shouldn't be a surprise that proprietary software is less likely to be exploited in this way simply because they don't accept any patches from outside of the team. What you want is more people that understand and care about free software and low barriers to getting involved.
I'm not sure that we are. Doesn't everybody know that developing/maintaining free software is largely thankless work, with little to no direct recompense?
I don't think moving towards unfree software is a good way to make free software more secure. It shouldn't be a surprise that proprietary software is less likely to be exploited in this way simply because they don't accept any patches from outside of the team. What you want is more people that understand and care about free software and low barriers to getting involved.
> 难道不是每个人都知道开发/维护自由软件在很大程度上是吃力不讨好的工作，几乎没有直接的回报吗？
不，我不认为这是一种普遍认可的感觉。许多维护者都详细地接收了用户的授权需求，就好像他们是开源软件项目的付费客户一样。乔治·斯塔夫拉卡斯 (Georges Stavracas) 在 Tech over Tea 播客^1 上的采访描述了许多此类经历。同样，当 Aseprite 转换其许可证^2以确保财务稳定时，它面临着用户的强烈反对，指责开发者背叛和压迫社区。
另一方面，如果每个人都确实知道这种情况，那么令人遗憾的是，这么多人都知道，却不愿意在经济上支持开发商改变这种状况。查看大型开源项目的所有开发人员，他们有日常工作，或者为了从事开源项目而大幅减薪。我知道并不是每个人都能在经济上支持一个项目，但我个人尝试打破那种期望我使用的所有东西都是免费的习惯，并竭尽全力为项目维护者寻找捐赠按钮，并在筹款活动中提高认识。现在，如果我能直接为 Emacs 开发捐款就好了……我会鼓励其他人也这样做。
> 你想要的是更多的人理解和关心自由软件并且参与门槛较低。
这很难。例如，DigitalOcean 的 Hacktoberfest 等举措背后的意图就是为了实现这一目标。从理论上讲，提交 4 个 Pull 请求并赢得一件 T 恤是个好主意，但在实践中却并非如此。该活动因无意中鼓励肤浅的贡献而受到批评，例如较小的文本编辑或琐碎的提交，这给维护者带来了负担^3，导致许多维护者只存档 10 月份的存储库。
因此，尽管人们认识到需要更多的人理解和重视自由软件，并且进入门槛较低，但目前的状况往往是不够的。前进的道路不仅应该包括提高意识和参与度，还应该为维护者提供有意义的支持和补偿。通过这样做，我们可以培育一个更加可持续、安全和充满活力的开源社区。或者至少我是这么感觉的......
1. https://www.youtube.com/watch?v=kO0V7BE1bEo
2.https://github.com/aseprite/aseprite/issues/1242
3. https://twitter.com/shitoberfest?lang=en
不，我不认为这是一种普遍认可的感觉。许多维护者都详细地接收了用户的授权需求，就好像他们是开源软件项目的付费客户一样。乔治·斯塔夫拉卡斯 (Georges Stavracas) 在 Tech over Tea 播客^1 上的采访描述了许多此类经历。同样，当 Aseprite 转换其许可证^2以确保财务稳定时，它面临着用户的强烈反对，指责开发者背叛和压迫社区。
另一方面，如果每个人都确实知道这种情况，那么令人遗憾的是，这么多人都知道，却不愿意在经济上支持开发商改变这种状况。查看大型开源项目的所有开发人员，他们有日常工作，或者为了从事开源项目而大幅减薪。我知道并不是每个人都能在经济上支持一个项目，但我个人尝试打破那种期望我使用的所有东西都是免费的习惯，并竭尽全力为项目维护者寻找捐赠按钮，并在筹款活动中提高认识。现在，如果我能直接为 Emacs 开发捐款就好了……我会鼓励其他人也这样做。
> 你想要的是更多的人理解和关心自由软件并且参与门槛较低。
这很难。例如，DigitalOcean 的 Hacktoberfest 等举措背后的意图就是为了实现这一目标。从理论上讲，提交 4 个 Pull 请求并赢得一件 T 恤是个好主意，但在实践中却并非如此。该活动因无意中鼓励肤浅的贡献而受到批评，例如较小的文本编辑或琐碎的提交，这给维护者带来了负担^3，导致许多维护者只存档 10 月份的存储库。
因此，尽管人们认识到需要更多的人理解和重视自由软件，并且进入门槛较低，但目前的状况往往是不够的。前进的道路不仅应该包括提高意识和参与度，还应该为维护者提供有意义的支持和补偿。通过这样做，我们可以培育一个更加可持续、安全和充满活力的开源社区。或者至少我是这么感觉的......
1. https://www.youtube.com/watch?v=kO0V7BE1bEo
2.https://github.com/aseprite/aseprite/issues/1242
3. https://twitter.com/shitoberfest?lang=en
To be clear, I'm not at all against compensating developers for their work. I am not trying to argue that people do not need to be supported financially, or that you shouldn't donate, or that no one should be able to make a living working on free software, and so on.
What I'm saying is that paying people (or having a trusted security team) to work on software necessarily makes it less free. Note that "less free" doesn't mean worthless and absolutely free isn't the ideal.
Sorry, I used "everybody" to mean a subset of everybody -- the "we" that you referred to, or people generally involved in open source software development.
> it's a shame that so many people know, and yet are unwilling to financially support developers to change that.
Regardless of which set of everyone, this is undoubtedly the case. However, I'm not sure that paying (some of) the developers a wage is the best way to improve the software, particularly as free software.
> initiatives like DigitalOcean's Hacktoberfest, are designed to do just this.
You've got this backwards. Hacktoberfest is a scheme to pay (more) people to contribute (more) to open source projects. This is an example of why paying people to work on open source doesn't necessarily improve the software. It also doesn't lower any barriers, it just increases the incentive to overcome them.
So while this might increase the number of people contributing[0] to open source projects, it doesn't directly increase the number of people who understand and care about the specific project they're contributing to, let alone the broader free software movement.
In short, you can't pay people to care.
[0] according to their pretty weak metric for what contributing is
What I'm saying is that paying people (or having a trusted security team) to work on software necessarily makes it less free. Note that "less free" doesn't mean worthless and absolutely free isn't the ideal.
Sorry, I used "everybody" to mean a subset of everybody -- the "we" that you referred to, or people generally involved in open source software development.
> it's a shame that so many people know, and yet are unwilling to financially support developers to change that.
Regardless of which set of everyone, this is undoubtedly the case. However, I'm not sure that paying (some of) the developers a wage is the best way to improve the software, particularly as free software.
> initiatives like DigitalOcean's Hacktoberfest, are designed to do just this.
You've got this backwards. Hacktoberfest is a scheme to pay (more) people to contribute (more) to open source projects. This is an example of why paying people to work on open source doesn't necessarily improve the software. It also doesn't lower any barriers, it just increases the incentive to overcome them.
So while this might increase the number of people contributing[0] to open source projects, it doesn't directly increase the number of people who understand and care about the specific project they're contributing to, let alone the broader free software movement.
In short, you can't pay people to care.
[0] according to their pretty weak metric for what contributing is
OSS maintainers aren't reaping anything. Most OSS licenses say the software is provided without warranty.
is this sev0?
Is this sev0?
This is another proof that systemd is an anti-pattern for security: with its crawling and ever growing web of dependencies, it extends the surface of vulnerability to orders of magnitude, and once embraced not even large distro communities can defend you from that.
A malware code injection in upstream xz-tools is a vector for remote exploitation of the ssh daemon due to a dependency on systemd for notifications and due to systemd's call to dlopen() liblzma library (CVE-2024-3094). The resulting build interferes with authentication in sshd via systemd.
A malware code injection in upstream xz-tools is a vector for remote exploitation of the ssh daemon due to a dependency on systemd for notifications and due to systemd's call to dlopen() liblzma library (CVE-2024-3094). The resulting build interferes with authentication in sshd via systemd.
Please take the systemd trolling to Reddit. They likely targeted xz specifically because it’s so widely used but there are dozens of other libraries which are potential candidates for an attack on sshd, much less everything else which has a direct dependency unrelated to systemd (e.g. dpkg).
Rather than distracting, think about how the open source projects you use would handle an attack like this where someone volunteers to help a beleaguered maintainer and spends time helpfully taking on more responsibilities before trying to weaken something.
Rather than distracting, think about how the open source projects you use would handle an attack like this where someone volunteers to help a beleaguered maintainer and spends time helpfully taking on more responsibilities before trying to weaken something.
You are distracting from facts with speculations and trolling FUD. I refer to what is known and has happened, you are speculating on what is not known.
Your claim is an appeal to emotion trying to build support for a position the Linux community has largely rejected. Starting with the goal rather than looking unemotionally at the facts means that you’re confusing your goal with the attackers’ – they don’t care about a quixotic attempt to remove systemd, they care about compromising systems.
Given control of a package which is on most Linux systems and a direct dependency of many things which are not systemd - run apt-cache rdepends liblzma5! – they can choose whatever they want to accomplish that goal. That could be things like a malformed archive which many things directly open or using something similar to this same hooking strategy to compromise a different system component. For example, that includes things like kmod and dpkg so they could target sshd through either of those or, if their attack vector wasn’t critically dependent on SSH, any other process running on the target. Attacking systemd for this is like saying Toyotas get stolen a lot without recognizing that you’re just describing a popularity contest.
Given control of a package which is on most Linux systems and a direct dependency of many things which are not systemd - run apt-cache rdepends liblzma5! – they can choose whatever they want to accomplish that goal. That could be things like a malformed archive which many things directly open or using something similar to this same hooking strategy to compromise a different system component. For example, that includes things like kmod and dpkg so they could target sshd through either of those or, if their attack vector wasn’t critically dependent on SSH, any other process running on the target. Attacking systemd for this is like saying Toyotas get stolen a lot without recognizing that you’re just describing a popularity contest.
Those other libraries dependend on by sshd are hopefully more closely monitored. The upstream sshd developers probably did not even consider that liblzma could end up being loaded in the process.
Make excuses for systemd all you want but loading multiple additional libraries into crytical system deamons just to write a few bytes into a socket is inexcusable and directly enabled this attack vector.
Make excuses for systemd all you want but loading multiple additional libraries into crytical system deamons just to write a few bytes into a socket is inexcusable and directly enabled this attack vector.
> systemd's call to dlopen() liblzma library (CVE-2024-3094)
That's technically wrong, but no surprise. Anti-systemd trolls usually don't understand technical details after all.
That's technically wrong, but no surprise. Anti-systemd trolls usually don't understand technical details after all.
我已经有十多年经历过这种人身攻击了。
你如此迅速地给一个可识别的专业人士贴上巨魔的标签，同时隐藏在你一次性的身份背后，我相信读者能够辨别出来。
同时让我们精确并添加更多事实https://github.com/systemd/systemd/pull/31550
我们的社区充满了像你这样的人，所以我将避免回答进一步的挑衅，相信我已经提供了足够的细节来支持我的主张。
你如此迅速地给一个可识别的专业人士贴上巨魔的标签，同时隐藏在你一次性的身份背后，我相信读者能够辨别出来。
同时让我们精确并添加更多事实https://github.com/systemd/systemd/pull/31550
我们的社区充满了像你这样的人，所以我将避免回答进一步的挑衅，相信我已经提供了足够的细节来支持我的主张。
That MR is not part of any released version of systemd. That is simply to verify: there has been no new systemd release.
So much for the "facts".
As for trolling: just look at the usual contributions from your community like https://twitter.com/DevuanOrg/status/1619013961629995008 Excellent work with the ad-hominem attacks there.
So much for the "facts".
As for trolling: just look at the usual contributions from your community like https://twitter.com/DevuanOrg/status/1619013961629995008 Excellent work with the ad-hominem attacks there.
It's already accepted and merged into master so it will be released in a future systemd release. What's your point?
LP in da house?
LP in da house?
The MR linked to would actually prevent the backdoor from working, but that doesn't stop some people from claiming it enables the backdoor.
But as already said: no surprise given where the comment comes from.
But as already said: no surprise given where the comment comes from.
That's not the point I'm replying to. You were lying and I pointed that out.
Can you explain in simple words that even a non programmer can understand, what the linked PR does?
Actually you have a point. A collection of shell scripts (like the classical init systems) have obviously a smaller attack surface. In this case the attacker used some integration code with systemd to attack the ssh daemon. So sshd without systemd integration is safe against this specific attack.
In general, I’m not convinced that systemd makes things less secure. I have the suspicion that the attacker would just have used a different vector, if there was no systemd integration. After all it looks like the attacker was also trying to integrate exploits in owner libraries, like zstd.
Still I would appreciate it, if systemd developers would find a better protection against supply chain attacks.
In general, I’m not convinced that systemd makes things less secure. I have the suspicion that the attacker would just have used a different vector, if there was no systemd integration. After all it looks like the attacker was also trying to integrate exploits in owner libraries, like zstd.
Still I would appreciate it, if systemd developers would find a better protection against supply chain attacks.
I really appreciate your tone and dialectic reasoning, thanks for your reply. And yes, as simple as it sounds, I believe that shell scripts help a lot to maintain mission critical tools. One hands-on example is https://dyne.org/software/tomb where I took this approach to replace whole disk encryption which is nowadays also dependent on systemd-cryptsetup.
Is this an example of a simple and clean solution via shell script? I have some stylistic doubts:
1. What "exitcode" is set for:
1. What "exitcode" is set for:
exitcode=1
exit 1
lklfuse -o type=ext4 "${loop}" "$mnt"
return $?
...
veracrypt --text --non-interactive -d "$file"
return $?
...
mount "$loop" "$mnt"
return $?
[ $? = 0 ]
[ $? != 0 ]
[ $exitcode = 0 ]
tomb_init() {
system="`uname -s`"
case "$system" in
FreeBSD)
cat <<-EOF
create=posix_create
format=posix_format
map=posix_map
mount=freebsd_mount
close=freebsd_close
EOF
;;
Linux)
感谢您的评论！不过，您指的是 tomb-portable 未完成的实验，该实验即将被驳回，因为 veracrypt 的跨平台实验显示出非常糟糕的性能。
欢迎您分享对 tomb 脚本的评论，但请注意，我们使用了许多 zsh 特定功能。该脚本已经运行了 15 年以上，因此它有大量的拼凑以避免回归。
欢迎您分享对 tomb 脚本的评论，但请注意，我们使用了许多 zsh 特定功能。该脚本已经运行了 15 年以上，因此它有大量的拼凑以避免回归。
It’s also tricky to reason about risk: for example, ShellShock caused a bunch of vulnerabilities in things which used shell scripts and the classic SysV Init system was a factor in a ton of vulnerabilities over the years because not having a standard way to do things like drop privileges or namespace things, manage processes, difficulties around managing chroot, etc. meant that you had a bunch of people implementing code which ran with elevated privileges because it needed to do things like bind to a low network port and they either had vulnerabilities in the privileged part or messed up some detail. I think in general it’s been much better in the systemd era where so much of that is builtin but I have been happy to see them starting to trim some of the things like the compression format bindings and I expect this will spur more.
Looks like Lasse Collin has commented on LKML: https://lkml.org/lkml/2024/3/30/188
Also, some info here: https://tukaani.org/xz-backdoor/
Also, some info here: https://tukaani.org/xz-backdoor/
Or if you can't stand the lkml.org UI:
https://lore.kernel.org/lkml/20240330144848.102a1e8c@kaneli/
https://lore.kernel.org/lkml/20240330144848.102a1e8c@kaneli/
In the future: automated `diff` or any other A/B check to see whether or not the tarball matches the source repo (if not, auto-flag with a mismatch warning attribute), is that feasible to implement?
So, it's been almost 24 hours since I read this yesterday. Is it confirmed that Jia Tan is the perpetrator? do we know who he/she really is? Or are we going to live for the rest of our lives only knowing the pseudo name? just like Satoshi Nakamoto did to us. ;)
This is why we never upgrade software versions. I’ve been asked by our customers why we use such an old AMI version. This is why.
This feels like the exact opposite of the takeaway you should have. Old software isn't inherently more secure; you're missing thousands of security and bug fixes. Yes, this was bad, but look how quickly the community came together to catch it and fix it.
It only took 6 days for it to be found and fixed.
It only took 6 days for it to be found and fixed.
- * _ring ring_ *
- "Hello?"
- "It's Lasse Collin."
- "Why are you collin me? Why not just use the backdoor?"
Debian is considering that their infrastructure may be compromised[1].
[1] https://fulda.social/@Ganneff/112184975950858403
[1] https://fulda.social/@Ganneff/112184975950858403
Which OS are affected by this compromise??
Is Ubuntu affected?
Anyone have any idea what the code in the malicious liblzma_la-crc64-fast.o is actually doing? It's difficult to follow statically.
[deleted]
[deleted]
When I search for "digital masquerade" on Google, the first result is a book with this title from the author Jia Tan. I assume that is how the attackers got their fake name. Or they think using this author's name is a joke.
Windows 版 Python 捆绑了该项目中的 liblzma，但它似乎是于 2022 年 4 月 18 日 [1] 供应到 Python 项目存储库中的版本 5.2.5 [0]，所以应该没问题，对吧？
[0] https://github.com/python/cpython/blob/main/PCbuild/get_exte...
[1] https://github.com/python/cpython-source-deps/tree/xz
[0] https://github.com/python/cpython/blob/main/PCbuild/get_exte...
[1] https://github.com/python/cpython-source-deps/tree/xz
哪个民族国家（如果有）最有可能是幕后黑手？中国是基于名称，还是这是转移注意力？
犯罪者在 UTC 时间 10 点到 18 点之间进行了大部分 GitHub 操作，这在一定程度上排除了美国的可能性，除非这些消息是预定的。与欧洲至亚洲一致。
请参阅 clickhouse 获取数据：https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPT...
犯罪者在 UTC 时间 10 点到 18 点之间进行了大部分 GitHub 操作，这在一定程度上排除了美国的可能性，除非这些消息是预定的。与欧洲至亚洲一致。
请参阅 clickhouse 获取数据：https://play.clickhouse.com/play?user=play#U0VMRUNUICogRlJPT...
Could easily be someone in the EST time zone. There aren't that many events that would be earlier than 8am EST.
Why are projects like xz and sshd still active? Just freeze it, it works fine. Only changes should be fixes for vulnerabilities. None of this complicated new functionality. If you want something like that make a new project. If it is truly better people will use it.
Is it time to deprecate the ability for code to implement linker symbols in other libraries? Shouldn't there be a strict namespace separation between binaries/libraries? liblzma being to implement openssh symbols seems like a symptom of a much larger problem.
大家好。
我正在主动收集有关后门可能的前体和肇事者的更多信息。
本评论的目的是关注开源信息 (OSINT)。
我不是对任何人或可能发生的任何行动的判断，此评论的目的是通过准确而快速的信息来帮助受影响软件包的核心开发人员，从而帮助 Linux 内核（可能已间接或直接受影响）针对所发生的事实采取必要的行动。
注意：此评论将始终带有“编辑”字样，因此请务必查看它以获取信息。
我目前掌握的信息。
摘要：
1.GitHub账户暂停：
- @JiaT75 和 @Larhzu 的帐户已被 GitHub 暂停。
- 所有 Tukaani 存储库（包括下载）均被禁用。
- 调查帐户被暂停的原因以及是否与可疑活动有任何关联。
2. xz/liblzma 中可能存在的后门：
- 人们担心 xz/liblzma 中存在后门。
- 调查源代码和最近的更新中是否有妥协的证据。
- 检查潜在影响，尤其是在关键系统中使用该软件时。
3. 包中的更新和补丁：
- 请注意 MinGW w64、pacman-static、Alpine 和 OpenSUSE 等软件包的最新更新。
- 查看更改日志以了解这些更新是否与安全修复相关。
4. 贾跃亭在平台和项目上的活动：
- 调查 Jia 对不同项目和平台的贡献，例如 Arch Linux、Alpine Linux 和 OpenSUSE。
- 检查贾的活动与报告的安全问题之间的相关性。
5.Libera注册信息：
- 分析贾在 Libera 上的注册详细信息，以确定其在线活动的时间表。
- 考虑将此信息与贾的其他在线活动相关联。
6.VPN使用：
- 确认贾使用VPN并评估其对安全调查的影响。
- 探索使用 VPN 的可能原因以及它如何影响在线活动的识别和跟踪。
与用户JiaT75相关的链接
[xz] 删除 JiaT75 作为联系人，确定正确的联系人 #11760 - Google/oss-fuzz
https://github.com/google/oss-fuzz/issues/11760
Tuktest 索引哈希 #7 - tukaani-project/xz/pull/7
https://web.archive.org/web/20240329230522/https://github.co...
我正在主动收集有关后门可能的前体和肇事者的更多信息。
本评论的目的是关注开源信息 (OSINT)。
我不是对任何人或可能发生的任何行动的判断，此评论的目的是通过准确而快速的信息来帮助受影响软件包的核心开发人员，从而帮助 Linux 内核（可能已间接或直接受影响）针对所发生的事实采取必要的行动。
注意：此评论将始终带有“编辑”字样，因此请务必查看它以获取信息。
我目前掌握的信息。
摘要：
1.GitHub账户暂停：
- @JiaT75 和 @Larhzu 的帐户已被 GitHub 暂停。
- 所有 Tukaani 存储库（包括下载）均被禁用。
- 调查帐户被暂停的原因以及是否与可疑活动有任何关联。
2. xz/liblzma 中可能存在的后门：
- 人们担心 xz/liblzma 中存在后门。
- 调查源代码和最近的更新中是否有妥协的证据。
- 检查潜在影响，尤其是在关键系统中使用该软件时。
3. 包中的更新和补丁：
- 请注意 MinGW w64、pacman-static、Alpine 和 OpenSUSE 等软件包的最新更新。
- 查看更改日志以了解这些更新是否与安全修复相关。
4. 贾跃亭在平台和项目上的活动：
- 调查 Jia 对不同项目和平台的贡献，例如 Arch Linux、Alpine Linux 和 OpenSUSE。
- 检查贾的活动与报告的安全问题之间的相关性。
5.Libera注册信息：
- 分析贾在 Libera 上的注册详细信息，以确定其在线活动的时间表。
- 考虑将此信息与贾的其他在线活动相关联。
6.VPN使用：
- 确认贾使用VPN并评估其对安全调查的影响。
- 探索使用 VPN 的可能原因以及它如何影响在线活动的识别和跟踪。
与用户JiaT75相关的链接
[xz] 删除 JiaT75 作为联系人，确定正确的联系人 #11760 - Google/oss-fuzz
https://github.com/google/oss-fuzz/issues/11760
Tuktest 索引哈希 #7 - tukaani-project/xz/pull/7
https://web.archive.org/web/20240329230522/https://github.co...
This is exactly why I fight the windmills so hard when it comes automatic updates in Linux software.
So much damage is caused just by adding a single maintainer to a project - imagine how much power you would have to wield the remote execution systems put in place by naive developers for "automatic updates".
All it takes is a single malicious maintainer given access to the new version update of some popular user software, and they have a new botnet of thousands of devices at their disposal. Better yet, after the backdoor installation, they can just release the real update and cover their tracks forever.
Automatic updates are like running web applications, but without any sandboxing or protection usually implemented by the browser.
So much damage is caused just by adding a single maintainer to a project - imagine how much power you would have to wield the remote execution systems put in place by naive developers for "automatic updates".
All it takes is a single malicious maintainer given access to the new version update of some popular user software, and they have a new botnet of thousands of devices at their disposal. Better yet, after the backdoor installation, they can just release the real update and cover their tracks forever.
Automatic updates are like running web applications, but without any sandboxing or protection usually implemented by the browser.
For someone who does not understand the packages used, could you please summarize in layman non technical terms. Thanks I did read the main post.
这个链接有点帮助。 https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...
我添加了一些关于可能计划的内核攻击的内容，但尚未提及太多。
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...
This is perfect summary https://research.swtch.com/xz-timeline
Also the attacker included in the 5.6.0 release the support for the long-awaited multi-threading decompression (and - broken - sandbox) making it very attractive to upgrade to...
It was probably a tactic to give a reason to upgrade. It's not always a fault for those who did or tried to do.
It was probably a tactic to give a reason to upgrade. It's not always a fault for those who did or tried to do.