3 ms·

Shame on me for not reading more before my now removed comment. Shout-out for doing this level of analysis and guessing, as with everything in this incident, fa

by k8svet 3y ago

Shame on me for not reading more before my now removed comment. Shout-out for doing this level of analysis and guessing, as with everything in this incident, fascinating and tantalizing to wonder about. It is interesting, at least one of the things listed as suspicious is something I do with some frequency. I will sometimes work on what is logically three commits and not chunk them out until the very end. A bit random, but has there been speculation on why this seemed to only target rpm/deb packaging?

Twirrim 3y ago
> A bit random, but has there been speculation on why this seemed to only target rpm/deb packaging? I don't think much speculation is needed. RPM and deb catches every Enterprise Linux distribution, to the best of my knowledge. rpm catches Red Hat and all derivatives like CentOS, Alma Linux etc, as well as SuSE, Amazon Linux, and even Microsoft's Mariner Linux (now renamed Azure Linux). deb catches Debian and Ubuntu. That's a huge global install base just through those two targets.
- k8svet 3y ago
  Sure, but why go to the effort to exclude others? Did they think it would help avoid detection on systems that they didn't care to backdoor?
  - thrdbndndn 3y ago
    Obviously it would help avoiding detection since the backdoor has the side effect of slowing down things. So you only target the ones you really want. And to me it's less that they don't care, more that their script probably only works or only has been tested on the ones using .rpm/.deb.
    - k8svet 3y ago
      > Obviously it would help avoiding detection since the backdoor has the side effect of slowing down things. My understanding was that this was the result of a bug? But I understand that part less than any of it, so I well could be wrong. >And to me it's less that they don't care, more that their script probably only works or only has been tested on the ones using .rpm/.deb. Now that, strikes me as more likely. Maybe they wanted to be relatively sure that they wouldn't be detected and needed to select a test matrix to test against (SELinux/landlock config across rpm/deb distros, versus across every distro.) I guess what I'm getting at is... did they have an intended set of targets and knew they were running deb/rpm, on top of any other factors?
  - cozzyd 3y ago
    Because random people testing an unpackaged version will not find a problem
  - Twirrim 3y ago
    I don't think it was specific effort to exclude others, they took efforts to ensure it happened at packaging time, to reduce chances of detection. So eg other xz devs didn't notice it when compiling it, and so on.
sihe 3y ago
> A bit random, but has there been speculation on why this seemed to only target rpm/deb packaging? The payload only works on systems that connect their sshd to systemd-notify -- which is not true for many Linux distributions beyond Debian-based and RH-based anyway (e.g. Arch Linux doesn't do this).

by k8svet 3y ago

Twirrim 3y ago

> A bit random, but has there been speculation on why this seemed to only target rpm/deb packaging? I don't think much speculation is needed. RPM and deb catches every Enterprise Linux distribution, to the best of my knowledge. rpm catches Red Hat and all derivatives like CentOS, Alma Linux etc, as well as SuSE, Amazon Linux, and even Microsoft's Mariner Linux (now renamed Azure Linux). deb catches Debian and Ubuntu. That's a huge global install base just through those two targets.

k8svet 3y ago
Sure, but why go to the effort to exclude others? Did they think it would help avoid detection on systems that they didn't care to backdoor?
- thrdbndndn 3y ago
  Obviously it would help avoiding detection since the backdoor has the side effect of slowing down things. So you only target the ones you really want. And to me it's less that they don't care, more that their script probably only works or only has been tested on the ones using .rpm/.deb.
  - k8svet 3y ago
    > Obviously it would help avoiding detection since the backdoor has the side effect of slowing down things. My understanding was that this was the result of a bug? But I understand that part less than any of it, so I well could be wrong. >And to me it's less that they don't care, more that their script probably only works or only has been tested on the ones using .rpm/.deb. Now that, strikes me as more likely. Maybe they wanted to be relatively sure that they wouldn't be detected and needed to select a test matrix to test against (SELinux/landlock config across rpm/deb distros, versus across every distro.) I guess what I'm getting at is... did they have an intended set of targets and knew they were running deb/rpm, on top of any other factors?
- cozzyd 3y ago
  Because random people testing an unpackaged version will not find a problem
- Twirrim 3y ago
  I don't think it was specific effort to exclude others, they took efforts to ensure it happened at packaging time, to reduce chances of detection. So eg other xz devs didn't notice it when compiling it, and so on.

sihe 3y ago

> A bit random, but has there been speculation on why this seemed to only target rpm/deb packaging? The payload only works on systems that connect their sshd to systemd-notify -- which is not true for many Linux distributions beyond Debian-based and RH-based anyway (e.g. Arch Linux doesn't do this).