Half a Second: How a Tiny Delay Revealed the XZ Utils Backdoor
Half a Second – a book about the XZ backdoor
I tell the story of how a Microsoft engineer's curiosity about a half-second delay uncovered a two-year infiltration of XZ Utils. This narrative exposes how critical open-source infrastructure often relies on exhausted, unpaid volunteers, leaving the digital world vulnerable to hidden threats that only luck and instinct can detect.
The same economy that funds the big, visible pieces leaves many of the small, unglamorous ones that everything also depends on to a handful of volunteers, often unpaid and overstretched.
- this_user
Well, the "About the Author" section should probably just be a link to claude.ai.
- skippyfish
Here's the tool developed by the author that was almost certainly used to generate this book in its entirety - "A structured pipeline for writing long-form nonfiction, packaged as a Claude Code skill":
https://github.com/AdrianMastronardi/bookwright
There's nowhere near enough public information about the xz vuln to be worth turning into a book, so the merits of AI-generated text aside, this is just a very inefficient way to learn about the topic.
- OldMatey
Given the time and effort that went into this, and the luck that one diligent person noticed, investigated and discovered what was going on before it could get further... it seems very likely to me that this has happened already in other libraries without being discovered.
- dhx
See [1] for April 2024 Clickhouse Github activity analysis of the xz backdoor.
I haven't seen anyone write up a proper analysis that includes consideration of:
- GitHub activity (e.g. all API actions on GitHub side including replying to comments) _and_ mailing list activity _and_ other public facing activity all considered together.
- Complexity of public actions e.g. was there a queue of code changes that would have taken 20 hours effort to put together that were all committed at once? Were there any long streaks of high activity where it might reveal how many people were involved?
- Latency of public actions e.g. if an issue was raised by some random person, how long did it take for the attacker to respond, and later resolve/commit a patch? Similar to the complexity of public actions, it might reveal how many people were involved by estimation of the time needed for an experienced developer to fix an issue vs. actual time taken, both in terms of level of effort and duration.
- International dispersement of a team in different timezones with some core hours for collaboration, review and public facing activity.
- Public holidays, country/region-specific work habits, etc--e.g. consideration of "summer holiday" periods or similar common holiday periods, consideration of unusual days of no/low activity versus snow days, power outages, etc which might have been experienced by the attacker.
Distribution of actions from Github indicates the attacker used a 6 day work week excluding […]
- kreyenborgi
> The catch is where the book begins, not what it is about.