Live data from Hacker News

Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

github.com

441–450 of 500 posts

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#441

Earlier quoted context omitted.

I work on oss-fuzz. I don't think it's plausible OSS-Fuzz could have found this. The backdoor required a build configuration that was not used in OSS-Fuzz. I'm guessing "Jia Tan" knew this and made changes to XZ's use of OSS-Fuzz for the purposes of cementing their position as the new maintainer of XZ, rather than out of worry OSS-Fuzz would find the backdoor as people have speculated.

How many oss-fuzz packages have a Dockerfile that runs apt-get install liblzma-dev first? Had this not been discovered, the backdoored version of xz could have eventually ended up in the ubuntu version oss-fuzz uses for its docker image - and linked into all those packages being tested as well. Except now there's an explanation if fuzzing starts to fail - honggfuzz uses -fsanitize which is incompatible with xz's use…

This is interesting, but do you think this would have aroused enough suspicion to find the backdoor (after every Ubuntu user was owned by it)? I don't see why this is the case. It wasn't a secret that ifuncs were being used in XZ.

And if that's the case, it was sloppy of "Jia" to disable it in OSS-Fuzz and not do this:

``` __attribute__((__used__,__no_sanitize_address__)) ```

to the XZ source code to fix the false positive and turn off the compilation warning, no attention would have been drawn to this at all since no one would have to change their build script.

With or without this PR, it's very unlikely OSS-Fuzz would have found the bug. OSS-Fuzz also happens to be on Ubuntu 20. I'm not very familiar with Ubuntu release cycles, but I think it would have been a very long time before backdoored packages made their way into Ubuntu 20.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#442

Earlier quoted context omitted.

> build-to-host.m4 I wasn't aware that the rogue maintainer was able to commit himself without any PR review (or he snuck it through PR review) rogue steps in the build process as well that went unnoticed so that he could bundle decompressed `xz` streams from test data, that also patched output .so files well enough to add hooking code to them. How many "process failures" are described in that process that exist in e…

The changes to build-to-host.m4 weren't in the source repo, so there was no commit. The attacker had permissions to create GitHub releases, so they simply added it to the GitHub release tarball.

How would this have made it into Debian? Part of the Debian build is to pull down a release tarball (and then build from source) and not `git clone` a repo at a specific tag and build from source?

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#443

Earlier quoted context omitted.

By whom? The attacker have assumed the maintainer role. Nobody is reviewing.

There’s a severe and dangerous lack of paranoia in this dev space. If I was letting someone maintain my codebase, I would 1 Billion percent be reviewing everything… if there was a binary added, I’d be building it myself and comparing the checksums. Trust absolutely no-one. If you can give a close friend or a loved one a loan of money and it is so easy for them to never pay you back, it should be a reminder that devs…

pretty unhealthy attitude to live by tbh. almost better being burned by a malicious payload once every 10 years than live in perpetual fear of being constantly scammed

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#444
post #406

This whole thing makes me wonder if AI could detect "anomalies" like the human who found the actual hack did. Observe a system (lots of systems) and use that data to spot anomylous behavior from "new" versions of packages being added, throw up a red flag that is like "this really doesn't act like it did in the past because parameter(s) are unusual given previous versions"

Anomaly, fraud, outlier detection... AI has been trying to solve that for several decades and in my experience in production these systems usually end up being a set of expert written rules saying "if X is greater than Y, notify someone to check".

The issue is that fraud is anti-inductive: when it's discovered, it changes.

Statistical AI systems are just naive induction, and so largely useless.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#445

Earlier quoted context omitted.

Intended levity, gee you sound miserable. Try some exercise in the mornings?

Read the room... This ain't Reddit.

Well this very reply you made is very much like something I would see on Reddit.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#446

Earlier quoted context omitted.

Do you have a source for the claim that this isn't a crime because it didn't succeed? As a sanity check, checking the plain text of the CFAA, it covers attempted hacking as you'd expect. So distributing a system with a backdoor, introducing a backdoor, etc all seem quite comfortably covered by existing statues. Which makes sense since like, I don't want to say 'duh' because I think that probably wouldn't meet HN guid…

I'm not claiming the attempt didn't succeed. I'm claiming that the attempt didn't occur, and that distributing the backdoor more widely would only have created the preconditions for an attempt. We don't know who the intended target was, or what the intended payload was. Yes, subsection (b) of the CFAA covers attempts at acts described in subsection (a) of the CFAA. Which specific act under subsection (a) do you claim…

All of them? It's a backdoor into Linux to gain unauthorized access to computers that even specifically only works for that attackers specific private key. We have trial by jury where I guess you could argue that this carefully crafted backdoor was just some sort weird accident, but we also have prosecutors to make the obvious counterargument and investigate what these folks were going for. Though frankly they're probably state actors that we're never gonna catch. But literally all of part a. I still don't understand if I'm actually just missing something obvious about our criminal justice system that would mean the US has no ability to prosecute even moderately complex crimes by slightly sophisticated actors that didn't reach fruition, since by your reasoning we'd also never be able to prosecute essentially any organized crime anywhere as long as they keep their targets a secret? If the attempt didn't occur then did someone just trip and fall on their keyboard over a period of months to accidentally carry out sophisticated social engineering to write a carefully hidden backdoor into a package targeted at hijacking widely used operating systems?

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#449

Earlier quoted context omitted.

There’s a severe and dangerous lack of paranoia in this dev space. If I was letting someone maintain my codebase, I would 1 Billion percent be reviewing everything… if there was a binary added, I’d be building it myself and comparing the checksums. Trust absolutely no-one. If you can give a close friend or a loved one a loan of money and it is so easy for them to never pay you back, it should be a reminder that devs…

pretty unhealthy attitude to live by tbh. almost better being burned by a malicious payload once every 10 years than live in perpetual fear of being constantly scammed

I think that depends on the context. If you're maintaining one of the most widely used packages that is directly linked to by libsystemd and is included by pretty much every Linux distro as part of the base system? Then maybe some measure of paranoia is justified.

I think the OpenBSD developers are right to be as paranoid as they are. Anyone who is maintaining a security critical system should be on guard against these kinds of attacks.

Re: Xzbot: Notes, honeypot, and exploit demo for the xz backdoor

#450

Earlier quoted context omitted.

pretty unhealthy attitude to live by tbh. almost better being burned by a malicious payload once every 10 years than live in perpetual fear of being constantly scammed

I think that depends on the context. If you're maintaining one of the most widely used packages that is directly linked to by libsystemd and is included by pretty much every Linux distro as part of the base system? Then maybe some measure of paranoia is justified. I think the OpenBSD developers are right to be as paranoid as they are. Anyone who is maintaining a security critical system should be on guard against the…

Oh absolutely true for things like OpenBSD and such
Post reply on HN