https://github.com/tukaani-project/tukaani-project.github.io... Does this mean anything that it changed to a parameter??
Backdoor in upstream xz/liblzma leading to SSH server compromise
171–180 of 1001 posts
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#172The 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.
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
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#173Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#174@people who write github scanners for updates and security issues (dependabot and the like) Can we start including a blacklist of emails and names of contributors (with reasons/links to discussions)? I can't track them and I don't want them in my projects. Might not be very helpful as it is easy to create new identities, but I see no reason to make it easier for them. Also, I might approach differently someone with l…
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 '". On the internet nobody knows you're Joe Biden.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#175The 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.
So many malicious actors have been caught because they accidentally created a mild annoyance for someone that went on to bird-dog the problem.
Which is why a really good backdoor is a one line logic bug somewhere which is fiendishly difficult to trigger.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#176For 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 p…
> 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
.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.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#177For 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 p…
> 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
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.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#178> 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…
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 syste…
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.
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#179Looks like one of the backdoor authors even went and disabled the feature the exploit relied on directly on oss-fuzz to prevent accidental discovery: https://social.treehouse.systems/@Aissen/112180302735030319
https://github.com/google/oss-fuzz/pull/10667
But luckily there was some serendipity: "I accidentally found a security issue while benchmarking postgres changes." https://mastodon.social/@AndresFreundTec/112180083704606941
Re: Backdoor in upstream xz/liblzma leading to SSH server compromise
#180The latest commit from the user who committed those patches is weirdly a simplification of the security reporting process, to not request as much detail: https://github.com/tukaani-project/xz/commit/af071ef7702debe... Not sure what to make of this.
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".