On Sun, Mar 31, 2024 at 09:12:30AM -0700, Adam Williamson wrote:
Thanks Arthur, yes, that was *exactly* the point.
I would argue there's a danger of getting too tied up in very specific technical details of this attack. Yes, it's reasonable to think of ways to mitigate those specific mechanisms, at least at the appropriate levels (arguably, most of this is really directly an issue upstream of us). But it has been - for me - persuasively argued that the specific technical details were decided based on the wider goals of the attack.
I buy the scenario where the starting point was "how can we poison the major distributions?" and everything from there derived from that starting point. xz was picked as the target because of all the specific technical stuff about systemd and ssh links which people are keen to dive deep into the details of, but *if that vector hadn't existed the attacker would just have chosen the next best one*. The specific form of the attack was then customized to the specific properties of xz, very cunningly - the whole thing about hiding the payload in binary test files. But if the attacker had chosen to attack a different project with different properties, they would have customized their attack to *that* environment with equal cunning, and it would probably look quite different.
I think even stepping further back from the technical details is worth considering. I think xz was picked because it had one maintainer who had personal issues and low time/desire to continue work, and they were a good target to be bullied into adding another maintainer. Are there other critical packages we ship in similar situations?
Worrying *only* about binary blobs in source repos or the specific details of how systemd opens compression libraries feels a bit narrow, to me - and especially so when we do it down at the distribution level where it's not necessarily primarily our responsibility, and I would argue is definitely not the *lowest* hanging fruit if we take a broader view of "what should we as a project be doing to raise the difficulty of supply chain attacks?"
Agreed. I think theres lots of places we should improve, and focusing on our own backyard first might be wise. But we can also work on the other parts too!
There are lots of things we _could_ do... we should discuss and consider what ones make sense in what order. We should just do something because we can. ;)
Also, a reminder... nothing is ever 'secure'. security is a process. We consider likelt threats, we try and mitigate them, and we keep doing it. Things change and we should too.
kevin