On The 'xz' Fiasco
The Market Ticker - Commentary on The Capital Markets
Login or register to improve your experience
Main Navigation
Sarah's Resources You Should See
Full-Text Search & Archives
Leverage, the book
Legal Disclaimer

The content on this site is provided without any warranty, express or implied. All opinions expressed on this site are those of the author and may contain errors or omissions. For investment, legal or other professional advice specific to your situation contact a licensed professional in your jurisdiction.


Actions you undertake as a consequence of any analysis, opinion or advertisement on this site are your sole responsibility; author(s) may have positions in securities or firms mentioned and have no duty to disclose same.

Market charts, when present, used with permission of TD Ameritrade/ThinkOrSwim Inc. Neither TD Ameritrade or ThinkOrSwim have reviewed, approved or disapproved any content herein.

The Market Ticker content may be sent unmodified to lawmakers via print or electronic means or excerpted online for non-commercial purposes provided full attribution is given and the original article source is linked to. Please contact Karl Denninger for reprint permission in other media, to republish full articles, or for any commercial use (which includes any site where advertising is displayed.)

Submissions or tips on matters of economic or political interest may be sent "over the transom" to The Editor at any time. To be considered for publication your submission must be complete (NOT a "pitch"; those get you blocked as a spammer), include full and correct contact information and be related to an economic or political matter of the day. All submissions become the property of The Market Ticker.

Considering sending spam? Read this first.

2024-04-01 07:00 by Karl Denninger
in Technology , 339 references Ignore this thread
On The 'xz' Fiasco
[Comments enabled]

This may well be one of the most-complex, well-thought-out and insidious "hack attempts" in the computer age's history -- so far.

The person or persons involved (while the code has been traced to a "person" there is no evidence, at this point, that said "person" is one person -- more on that in a bit) were essentially a "single committer" maintaining a commonly-used compression tool had an intentional compromise included into it.

It would at first blush seem to be a rather odd place to try to put a security compromise, in that compressing or decompressing files is more-or-less a utility function and rarely, if ever, implicates security directly (you might destroy data, but actually using it to break into something sounds like quite a stretch.)

You'd be right except for a practice that has gotten disturbingly common: The building of such utility functions into libraries, and then the linking of said libraries into all manner of other things including those running with privilege.

In this case that "thing" is called systemd on Linux machines and the target of it is sshd, which is the system utility that accepts secure, encrypted connections at a character terminal level -- and enables encrypted file copies as well.  It appears the intent of the code is to steal the private key on the server side which would enable someone to break into the machine quite possibly, depending on how it is configured, with "root" (administrative) access giving them full, unfettered access to everyone and everything on that system.

It really doesn't get any worse than that when it comes to security problems, by the way.

This points out the folly of privileged tools that perform administrative tasks (in this case supervising executables that must have privilege in order to do their job) being linked with all manner of "convenience" functions aggregated into libraries.  Some of this is unavoidable -- "libc", for example, contains all the common and bog-standard routines to, for example, do basic file I/O to textual streams.  Why is file compression considered important enough to link against such tools?  That seems rather stupid to me, but here we are.

But this incident also points out that one of the big improvements in open source software is that it was caught before getting into wide distribution through enterprises, that is, during the "beta" phase where people are cautioned against using same in production, specifically because said software is in open use and someone noted that the code produced anomalous behavior, specifically that after the upgrade logins were a bit slower without a reasonable explanation as to why.

The "why" was the code "hooking" the routines in question and altering them to perform its nefarious acts.

Another point that should be noted is that the reason this was able to get into the code in the first place was including of a binary blob.  Obviously if said code had been included in source what it did would have been observed prior to the commit and pull request being approved. There are, in some cases, good reasons to include a binary blob but this certainly wasn't one of them and those doing said approval ought to demand the source and a traceable and reproduceable build process before accepting them, especially when said code is going to wind up in a sharable library and thus be linkable against almost-literally anything.

Another problem is the identity of the committer.  Who was it and why haven't they been run down and jailed? Open source projects by definition can have people from anywhere submit improvements and bug fixes but that doesn't mean the maintaining party has to accept them and when it comes to things that are going to be included in system libraries some sort of chain of identity as pertains those who have the ability to approve said changes needs to be examined.  Obviously that was not the case here in that the person who did so hasn't been identified and may not exist -- that is, from the information we have publicly at this point it may well have been a "pseudo person" that was in fact a state-level organization actor.  This risk becomes very severe when only one or two people are "maintaining" something and it winds up in a published library that is then linked against system code that runs with privilege, which is exactly what occurred in this case.  In other words as of right now we don't even know who did it despite there being no evidence that the commit and merge process itself was compromised.

And finally, while this probably won't stop the insanity of "include everything by container" in modern languages that are increasingly used for elevated privilege functions it should slam the door on it conclusively, including retroactively, right here and now.  I'm staring you straight in the face, Rust, although by no means only there.  The "container" and "oh someone did this and its on Stack Overflow so we'll just grab that blob" problem has "powered" much of so-called "modern software" and its fundamentally a cheat code to evade not just the time of implementation but even the understanding of exactly how something works and its potential attack surface.  This incident is an object lesson in why that's stupid and it had the very real potential to get into literally millions of Linux-powered things all over the world including those handling various financial and operational things with real impact on real people.  It didn't, this time, but that was more by luck that discovery occurred before it could get out into the wild on that basis than anything else.

Go to responses (registration required to post)

No Comments Yet.....
Login Register Top Blog Top Blog Topics FAQ
Page 1 of 44  First123456789Last
Login Register Top Blog Top Blog Topics FAQ
Page 1 of 44  First123456789Last