top 50 comments

sorted by: hot top controversial new old
[–] 150 points 2 years ago* (2 children)

They noticed that some ssh sessions took 0.5 seconds too long under certain circumstances. 😲

Holy hell that's good QA.

  • source
  • hideshow 4 child comments
  • [–] 27 points 2 years ago (2 children)
  • [–] 25 points 2 years ago (1 child)

    Don't see why you're being downvoted, the person in question who discovered this is a postgres maintainer employed by Microsoft.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 18 points 2 years ago (2 children)

    Probably people think this is a troll or something.

    I wrote it because I was surprised, especially since I'm not a fan of microsoft and their policies. Lately, I have the feeling Microsoft is better than Google (relative terms) when it comes to oss.

    What is additionally surprising is the breaches of Microsoft services in the last year. There is one every few weeks or so... And then they pick up a backdoor because login took 0.5 instead of 0.1s.

    Anyway, his findings are amazing.

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (2 replies)
  • [–] 97 points 2 years ago (9 children)

    Damn, it is actually scary that they managed to pull this off. The backdoor came from the second-largest contributor to xz too, not some random drive-by.

  • source
  • hideshow 11 child comments
  • [–] 51 points 2 years ago (1 child)

    They've been contributing to xz for two years, and commited various "test" binary files.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 60 points 2 years ago (1 child)

    It's looking more like a long game to compromise an upstream.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 18 points 2 years ago (1 child)

    Either that or the attacker was very good at choosing their puppet…

  • source
  • parent
  • hideshow 2 child comments
  • [–] 36 points 2 years ago (2 children)

    Well the account is focused on one particular project which makes sense if you expect to get burned at some point and don't want all your other exploits to be detected. It looks like there was a second sock puppet account involved in the original attack vector support code.

    We should certainly audit other projects for similar changes from other psudoanonymous accounts.

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (2 replies)
  • load more comments (7 replies)
    [–] 73 points 2 years ago (1 child)

    This is a fun one we're gonna be hearing about for a while...

    It's fortunate it was discovered before any major releases of non-rolling-release distros were cut, but damn.

  • source
  • hideshow 1 child comment
  • load more comments (1 reply)
    [–] 71 points 2 years ago (2 children)
  • [–] 63 points 2 years ago
    [–] 58 points 2 years ago (10 children)

    If you're using xz version 5.6.0 or 5.6.1, please upgrade asap, especially if you're using a rolling-release distro like Arch or its derivatives. Arch has rolled out the patched version a few hours ago.

  • source
  • hideshow 11 child comments
  • load more comments (9 replies)
    [–] 49 points 2 years ago
    [–] 40 points 2 years ago (4 children)

    Time to bring back the reproducible build hype

  • source
  • hideshow 5 child comments
  • [–] 57 points 2 years ago (2 children)

    Won't help here; this backdoor is entirely reproducible. That's one of the scary parts.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 28 points 2 years ago* (2 children)

    The backdoor wasn't in the source code, only in the distributed binary. So reproducible builds would have flagged the tar as not coming from what was in Git

  • source
  • parent
  • hideshow 3 child comments
  • [–] 41 points 2 years ago (1 child)

    Reproducible builds generally work from the published source tarballs, as those tend to be easier to mirror and archive than a Git repository is. The GPG-signed source tarball includes all of the code to build the exploit.

    The Git repository does not include the code to build the backdoor (though it does include the actual backdoor itself, the binary "test file", it's simply disused).

    Verifying that the tarball and Git repository match would be neat, but is not a focus of any existing reproducible build project that I know of. It probably should be, but quite a number of projects have legitimate differences in their tarballs, often pre-compiling things like autotools-based configure scripts and man pages so that you can have a relaxed ./configure && make && make install build without having to hunt down all of the necessary generators.

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (1 reply)
  • load more comments (3 replies)
    [–] 34 points 2 years ago

    Reading the comments here https://news.ycombinator.com/item?id=39865810 it appears that libarchive may be tainted as well.

  • source
  • [–] 30 points 2 years ago

    This is pretty insane. Can't wait for the Darknet Diaries on this one.

  • source
  • [–] 27 points 2 years ago (2 children)

    ELI5 what does this mean for the average Linux user? I run a few Ubuntu 22.04 systems (yeah yeah, I know, canonical schmanonical) - but they aren’t bleeding edge, so they shouldn’t exhibit this vulnerability, right?

  • source
  • hideshow 4 child comments
  • [–] 25 points 2 years ago
    [–] 19 points 2 years ago

    Here is the official statement from OpenSUSE: https://news.opensuse.org/2024/03/29/xz-backdoor/

  • source
  • [–] 18 points 2 years ago (10 children)

    t y for sharing.

    #showerthoughts The problem is in upstream and has only entered Debian Sid/unstable. Does this mean that for example bleeding edge Arch (btw) sshd users are compromised already ?

  • source
  • hideshow 13 child comments
  • [–] 29 points 2 years ago* (1 child)

    Looks like the 5.6.1-2 release on Arch moved from using the published GitHub releases to just using the git repository directly, which as I understand avoids the exploit (because the obfuscated script to inject the exploit is only present in the packaged tarballs and not the git repo itself)

    https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad

  • source
  • parent
  • hideshow 2 child comments
  • [–] 34 points 2 years ago* (last edited 2 years ago) (2 children)

    They also believe we (Arch users) are unaffected because this backdoor targeted Debian and Redhat type packaging specifically and also relied on a certain SSH configuration Arch doesn't use. To be honest while it's nice to know we're unaffected, it's not at all comforting that had the exploiter targeted Arch they would have succeeded. Just yesterday I was talking to someone about how much I love rolling release distros and now I'm feeling insecure about it.

    More details here: https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/2

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (2 replies)
  • [–] [S] 19 points 2 years ago* (1 child)

    Arch is on 5.6.1 as of now: https://archlinux.org/packages/core/x86_64/xz/

    We at Nixpkgs have barely evaded having it go to a channel used by users and we don't seem to be affected by the backdoor.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 13 points 2 years ago*

    Arch had a patch rolled out yesterday [1][2][3] that switches to the git repo. On top of that the logic in the runtime shim and build script modifier was orchestrated to target Debian and RPM build systems and environments [4].

    [1] https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/commit/881385757abdc39d3cfea1c3e34ec09f637424ad

    [2] https://gitlab.archlinux.org/archlinux/packaging/packages/xz/-/issues/2

    [3] https://security.archlinux.org/CVE-2024-3094

    [4] https://www.openwall.com/lists/oss-security/2024/03/29/4

  • source
  • parent
  • load more comments (7 replies)
    [–] 12 points 2 years ago*
    [–] 12 points 2 years ago

    Damn fine work all around.

    I know this is an issue fraught with potential legal and political BS, and it's impossible to check everything without automation these days, but is there an organization that trains and pays people to work as security researchers or QA for open source projects?

    Basically, a watchdog group that finds exploitable security vulnerabilities, and works with individuals or vendors to patch them? Maybe make it a publicly owned and operated group with mandatory reporting of some kind. An international project funded by multiple governments, where it's harder for a single point of influence to hide exploits, abuse secrets, or interfere with the researchers? They don't own or control any code, just find security issues and advise.

    I don't know.

    Just thinking that modern security is getting pretty complicated, with so many moving parts and all.

  • source
  • [–] 11 points 2 years ago (1 child)
    load more comments (1 reply)
    [–] 10 points 2 years ago (3 children)

    And you know what? Doing updates once a week saved me from updating to this version :)

  • source
  • hideshow 3 child comments
  • load more comments (3 replies)
    load more comments
    view more: next ›