4 ms·

Also thanks to Debian for modifying openssh.

cassianoleal 3y ago
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.
- fullstop 3y ago
  Right, the systemd notification framework is very simple and I've used it in my projects. I didn't even know that libsystemd provided an implementation. My Arch system was not vulnerable because openssh was not linked to xz. IMO every single commit from JiaT75 should be reviewed and maybe even rolled back, as they have obliterated their trust. edit: https://github.com/google/oss-fuzz/pull/10667 https://github.com/google/oss-fuzz/pull/10667 Even this might be nefarious.
  - gopher_space 3y ago
    > 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?
- SAI_Peregrinus 3y ago
  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.
  - sitkack 3y ago
    It takes a village.
  - cassianoleal 3y ago
    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 https://packages.debian.org/bookworm/xz-utils
    - fullstop 3y ago
      > Debian stable (bookworm) has xz-utils version 5.4.1: https://packages.debian.org/bookworm/xz-utils https://packages.debian.org/bookworm/xz-utils Guess who released 5.4.1? JiaT75!
      - cassianoleal 3y ago
        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
        fullstop 3y ago
        Neither does https://salsa.debian.org/debian/xz-utils/-/tree/v5.6.0/m4 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.
        sroussey 3y ago
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]

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.

fullstop 3y ago
Right, the systemd notification framework is very simple and I've used it in my projects. I didn't even know that libsystemd provided an implementation. My Arch system was not vulnerable because openssh was not linked to xz. IMO every single commit from JiaT75 should be reviewed and maybe even rolled back, as they have obliterated their trust. edit: https://github.com/google/oss-fuzz/pull/10667 https://github.com/google/oss-fuzz/pull/10667 Even this might be nefarious.
- gopher_space 3y ago
  > 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?
SAI_Peregrinus 3y ago
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.
- sitkack 3y ago
  It takes a village.
- cassianoleal 3y ago
  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 https://packages.debian.org/bookworm/xz-utils
  - fullstop 3y ago
    > Debian stable (bookworm) has xz-utils version 5.4.1: https://packages.debian.org/bookworm/xz-utils https://packages.debian.org/bookworm/xz-utils Guess who released 5.4.1? JiaT75!
    - cassianoleal 3y ago
      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
      - fullstop 3y ago
        Neither does https://salsa.debian.org/debian/xz-utils/-/tree/v5.6.0/m4 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.
        sroussey 3y ago
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]