How did the exploit do this at runtime?
I know the chain was:
opensshd -> systemd for notifications -> xz included as transient dependency
How did liblzma.so.5.6.1 hook/patch all the way back to openssh_RSA_verify when it was loaded into memory?
How was this part obfuscated/undetected?
In a compression/decompression test suite, a subtly broken allegedly compressed binary blob is not out of place.
This suggests we need to audit information flow during builds - the shipping production binary package should be reproduceably buildable without reading test data or test code.
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78b...
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 every OSS repo with volunteer unknown untrusted maintainers?
> volunteer That's the majority of OSS. Only a handful of the projects we use today as a part of the core set of systems in the OSS world actually have corporate sponsorship by virtue of maintainers/contributors on the payroll. > unknown The actor built up a positive reputation by assisting with maintaining the repo at a time when the lead dev was unable to take an active role. In this sense, although we did not have some kind of full chain of authentication that "Jia Tan" was a real human that existed, that's about as good as it gets, and there's plenty of real world examples of espionage in both the open and closed source software world that can tell us that identity verification may not have prevented anything. > untrusted The actor gained trust. The barrier to gaining trust may have been low due to the mental health of the lead maintainer, but trust was earned and received. The lead maintainer communicated to distros that they should be added.
That's the rub here. It's _really easy_ to say this is a process problem. It's not. This was a social engineering attack first and foremost before anything else. It unlocked the way forward for the threat actor to take many actions unilaterally.
What process failures actually happened here? What changes in process do you think would have stopped this?
The attacker had permissions to create GitHub releases, so they simply added it to the GitHub release tarball.