Half a Second – a book about the XZ backdoor

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.

lucasRW

It's only going to recycle old news. The missing piece is attribution. Had it been the usuals (DPRK, Russia, China), the attribution would have been made publicly. The fact that is has not points as a friendly - especially when Microsoft (who owns Github) had all that telemetry and very likely has the means to find out. Some serious OSINT (consistency of timezone across months if not years of commits) pointed to the Middle East. An obvious Unit name comes to mind.

kreyenborgi

> The catch is where the book begins, not what it is about.

this_user

Well, the "About the Author" section should probably just be a link to claude.ai.

tryauuum

So Microsoft did something good? I thought they are too busy keeping my personal data in a prison and writing tight bash loops wasting 100 percent of a core

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 Sunday, and almost all activity conducted between UTC 12:00-16:00. Within these 6 days, activity was uneven at 0.5, 1, 1, 1, 1, 0.5 effort per day. There are low activity periods too that line up with summer solstice (southern hemisphere) or winter solstice (northern hemisphere). There are interesting patterns in the data not yet publicly analysed (I think?) that seemingly would reveal the true location of attackers, particularly because attacker actions are anchored to uncontrollable events such as a known-good contributor (such as Linux distro maintainer) raising a Github issue against a repository and the attacker replying an hour later. For such events with low latency of reply, it'd be well worth considering when a reply was made quickly, and when it wasn't, across a few years of data points. [1] https://news.ycombinator.com/item?id=39905375

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.

pflenker

It’s great to have the entire topic brought together into a cohesive book - but wow, I find it very annoying to read.