Last week, the internet dodged a major nation-state attack that would have had catastrophic cybersecurity repercussions worldwide. It’s a catastrophe that didn’t happen, so it won’t get much attention—but it should. There’s an important moral to the story of the attack and its discovery : The security of the global internet depends on countless obscure pieces of software written and maintained by even more obscure unpaid, distractible, and sometimes vulnerable volunteers. It’s an untenable situation, and one that is being exploited by malicious actors. Yet precious little is being done to remedy it.

Programmers dislike doing extra work. If they can find already-written code that does what they want, they’re going to use it rather than recreate the functionality. These code repositories, called libraries, are hosted on sites like GitHub. There are libraries for everything: displaying objects in 3D, spell-checking, performing complex mathematics, managing an e-commerce shopping cart, moving files around the internet—everything. Libraries are essential to modern programming; they’re the building blocks of complex software. The modularity they provide makes software projects tractable. Everything you use contains dozens of these libraries: some commercial, some open source and freely available. They are essential to the functionality of the finished software. And to its security.

You’ve likely never heard of an open-source library called XZ Utils, but it’s on hundreds of millions of computers. It’s probably on yours. It’s certainly in whatever corporate or organizational network you use. It’s a freely available library that does data compression. It’s important, in the same way that hundreds of other similar obscure libraries are important.

Many open-source libraries, like XZ Utils, are maintained by volunteers. In the case of XZ Utils, it’s one person, named Lasse Collin. He has been in charge of XZ Utils since he wrote it in 2009. And, at least in 2022, he’s had some “ longterm mental health issues. ” (To be clear, he is not to blame in this story. This is a systems problem.)

Beginning in at least 2021, Collin was personally targeted . We don’t know by whom, but we have account names: Jia Tan, Jigar Kumar, Dennis Ens. They’re not real names. They pressured Collin to transfer control over XZ Utils. In early 2023, they succeeded. Tan spent the year slowly incorporating a backdoor into XZ Utils: disabling systems that might discover his actions, laying the groundwork, and finally adding the complete backdoor earlier this year. On March 25, Hans Jansen—another fake name—tried to push the various Unix systems to upgrade to the new version of XZ Utils.

And everyone was poised to do so. It’s a routine update. In the span of a few weeks, it would have been part of both Debian and Red Hat Linux, which run on the vast majority of servers on the internet. But on March 29, another unpaid volunteer, Andres Freund—a real person who works for Microsoft but who was doing this in his spare time—noticed something weird about how much processing the new version of XZ Utils was doing. It’s the sort of thing that could be easily overlooked, and even more easily ignored. But for whatever reason, Freund tracked down the weirdness and discovered the backdoor.

It’s a masterful piece of work . It affects the SSH remote login protocol, basically by adding a hidden piece of functionality that requires a specific key to enable. Someone with that key can use the backdoored SSH to upload and execute an arbitrary piece of code on the target machine. SSH runs as root, so that code could have done anything. Let your imagination run wild.

This isn’t something a hacker just whips up. This backdoor is the result of a years-long engineering effort. The ways the code evades detection in source form, how it lies dormant and undetectable until activated, and its immense power and flexibility give credence to the widely held assumption that a major nation-state is behind this.

If it hadn’t been discovered, it probably would have eventually ended up on every computer and server on the internet. Though it’s unclear whether the backdoor would have affected Windows and Mac, it would have worked on Linux. Remember in 2020, when Russia planted a backdoor into SolarWinds that affected 14,000 networks? That seemed like a lot, but this would have been orders of magnitude more damaging. And again, the catastrophe was averted only because a volunteer stumbled on it. And it was possible in the first place only because the first unpaid volunteer, someone who turns out to be a national security single point of failure, was personally targeted and exploited by a foreign actor.

This is no way to run critical national infrastructure. And yet, here we are. This was an attack on our software supply chain . This attack subverted software dependencies. The SolarWinds attack targeted the update process. Other attacks target system design, development, and deployment. Such attacks are becoming increasingly common and effective, and also are increasingly the weapon of choice of nation-states.

It’s impossible to count how many of these single points of failure are in our computer systems. And there’s no way to know how many of the unpaid and unappreciated maintainers of critical software libraries are vulnerable to pressure. (Again, don’t blame them. Blame the industry that is happy to exploit their unpaid labor.) Or how many more have accidentally created exploitable vulnerabilities. How many other coercion attempts are ongoing? A dozen? A hundred? It seems impossible that the XZ Utils operation was a unique instance.

Solutions are hard. Banning open source won’t work; it’s precisely because XZ Utils is open source that an engineer discovered the problem in time. Banning software libraries won’t work, either; modern software can’t function without them. For years security engineers have been pushing something called a “ software bill of materials ”: an ingredients list of sorts so that when one of these packages is compromised, network owners at least know if they’re vulnerable. The industry hates this idea and has been fighting it for years, but perhaps the tide is turning .

The fundamental problem is that tech companies dislike spending extra money even more than programmers dislike doing extra work. If there’s free software out there, they are going to use it—and they’re not going to do much in-house security testing. Easier software development equals lower costs equals more profits. The market economy rewards this sort of insecurity.

We need some sustainable ways to fund open-source projects that become de facto critical infrastructure. Public shaming can help here. The Open Source Security Foundation (OSSF), founded in 2022 after another critical vulnerability in an open-source library—Log4j—was discovered, addresses this problem . The big tech companies pledged $30 million in funding after the critical Log4j supply chain vulnerability, but they never delivered. And they are still happy to make use of all this free labor and free resources, as a recent Microsoft anecdote indicates. The companies benefiting from these freely available libraries need to actually step up, and the government can force them to.

There’s a lot of tech that could be applied to this problem, if corporations were willing to spend the money. Liabilities will help. The Cybersecurity and Infrastructure Security Agency’s (CISA’s) “secure by design” initiative will help, and CISA is finally partnering with OSSF on this problem. Certainly the security of these libraries needs to be part of any broad government cybersecurity initiative.

We got extraordinarily lucky this time, but maybe we can learn from the catastrophe that didn’t happen. Like the power grid, communications network, and transportation systems, the software supply chain is critical infrastructure , part of national security, and vulnerable to foreign attack. The U.S. government needs to recognize this as a national security problem and start treating it as such.

This essay originally appeared in Lawfare .

The cybersecurity world got really lucky last week. An intentionally placed backdoor in XZ Utils, an open-source compression utility, was pretty much accidentally discovered by a Microsoft engineer—weeks before it would have been incorporated into both Debian and Red Hat Linux. From ArsTehnica :

Malicious code added to XZ Utils versions 5.6.0 and 5.6.1 modified the way the software functions. The backdoor manipulated sshd, the executable file used to make remote SSH connections. Anyone in possession of a predetermined encryption key could stash any code of their choice in an SSH login certificate, upload it, and execute it on the backdoored device. No one has actually seen code uploaded, so it’s not known what code the attacker planned to run. In theory, the code could allow for just about anything, including stealing encryption keys or installing malware.

It was an incredibly complex backdoor . Installing it was a multi-year process that seems to have involved social engineering the lone unpaid engineer in charge of the utility. More from ArsTechnica:

In 2021, someone with the username JiaT75 made their first known commit to an open source project. In retrospect, the change to the libarchive project is suspicious, because it replaced the safe_fprint function with a variant that has long been recognized as less secure. No one noticed at the time.

The following year, JiaT75 submitted a patch over the XZ Utils mailing list, and, almost immediately, a never-before-seen participant named Jigar Kumar joined the discussion and argued that Lasse Collin, the longtime maintainer of XZ Utils, hadn’t been updating the software often or fast enough. Kumar, with the support of Dennis Ens and several other people who had never had a presence on the list, pressured Collin to bring on an additional developer to maintain the project.

There’s a lot more. The sophistication of both the exploit and the process to get it into the software project scream nation-state operation. It’s reminiscent of Solar Winds, although (1) it would have been much, much worse, and (2) we got really, really lucky.

I simply don’t believe this was the only attempt to slip a backdoor into a critical piece of Internet software, either closed source or open source. Given how lucky we were to detect this one, I believe this kind of operation has been successful in the past. We simply have to stop building our critical national infrastructure on top of random software libraries managed by lone unpaid distracted—or worse—individuals.

In discovering malicious code that endangered global networks in open-source software, Andres Freund exposed our reliance on insecure, volunteer-maintained tech

On Good Friday, a Microsoft engineer named Andres Freund noticed something peculiar. He was using a software tool called SSH for securely logging into remote computers on the internet, but the interactions with the distant machines were significantly slower than usual. So he did some digging and found malicious code embedded in a software package called XZ Utils that was running on his machine. This is a critical utility for compressing (and decompressing) data running on the Linux operating system, the OS that powers the vast majority of publicly accessible internet servers across the world. Which means that every such machine is running XZ Utils.

Freund’s digging revealed that the malicious code had arrived in his machine via two recent updates to XZ Utils, and he alerted the Open Source Security list to reveal that those updates were the result of someone intentionally planting a backdoor in the compression software. It was what is called a “supply-chain attack” (like the catastrophic SolarWinds one of 2020 ) – where malicious software is not directly injected into targeted machines, but distributed by infecting the regular software updates to which all computer users are wearily accustomed. If you want to get malware out there, infecting the supply chain is the smart way to do it.

Continue reading...

Figurez-vous que le géant Microsoft, oui oui, le monstre de Redmond, se retrouve à genoux devant la communauté open source de FFmpeg .

Et pourquoi donc ? Parce que ces satanés codecs multimédias leur donnent du fil à retordre !

Mais attention, ne croyez pas que Microsoft va gentiment demander de l’aide comme tout le monde. Non non non, eux ils exigent, ils ordonnent, ils veulent que les petites mains de FFmpeg réparent illico presto les bugs de leur précieux produit Teams . Bah oui, faut pas déconner, c’est pour un lancement imminent et les clients râlent !

Sauf que voilà, les gars de FFmpeg ils ont pas trop apprécié le ton. Ils sont là, tranquilles, à développer leur truc open source pour le bien de l’humanité, et là Microsoft débarque en mode « Eho les mecs, faudrait voir à bosser un peu plus vite là, on a besoin de vous là, maintenant, tout de suite ». Super l’ambiance.

Alors ok, Microsoft a daigné proposer quelques milliers de dollars pour les dédommager. Mais bon, les développeurs FFmpeg ont un peu de fierté quand même et souhaitent un vrai contrat de support sur le long terme, pas une aumône ponctuelle balancée comme on jette un os à un chien.

Et là, c’est le choc des cultures mes amis ! D’un côté Microsoft, habitué à régner en maître sur son petit monde propriétaire , à traiter les développeurs comme de la chair à code. De l’autre, la communauté open source , des passionnés qui bouffent du codec matin midi et soir, qui ont la vidéo dans le sang et le streaming dans les veines.

Microsoft fait moins le malin maintenant puisqu’ils réalisent que leur précieux Teams, ça marche pas terrible sans FFmpeg et que leurs armées de développeurs maison, n’y connaissent pas grand chose en codecs multimédia . Et surtout que la communauté open source, bah elle a pas trop envie de se faire exploiter comme ça.

Moralité de l’histoire : faut pas prendre les gars de FFmpeg pour des poires. Ils ont beau être « open » , ils ont leur dignité et Microsoft va devoir apprendre à respecter ça, à collaborer d’égal à égal, à lâcher des billets et des contrats de support au lieu de jouer au petit chef.

Parce que sinon, Teams risque de sonner un peu creux sans codecs qui fonctionnent. Et là, ça va être dur d’expliquer aux clients que la visio ça sera en version mime, parce que Microsoft a pas voulu mettre la main au portefeuille pour avoir de l’audio qui marchent.

Et, si vous voulez en savoir plus sur ce choc des titans, foncez sur https://sopuli.xyz/post/11143769 , vous n’allez pas être déçu du voyage !

Vous aimez créer des stickers pour épater vos amis sur les réseaux sociaux ? Mais vous en avez marre de passer des heures sur Photoshop pour un résultat pas toujours au top ? J’ai ce qu’il vous faut !

Le site web StickerBaker est une vraie petite pépite pour générer des stickers personnalisés en quelques clics grâce à l’intelligence artificielle.

Concrètement, vous uploadez une photo de votre trombine, vous entrez une petite description façon prompt et bim , l’IA vous génère un sticker sur-mesure avec un rendu digne des plus grands graphistes. Pas besoin d’être un crack en dessin ou en retouche d’image, StickerBaker s’occupe de tout !

Mais alors StickerBaker, ça peut servir à quoi concrètement ? Et bien comme je le disais, créer des stickers complètement barrés à partir de vos photos pour amuser la galerie et mettre l’ambiance dans la conversation WhatsApp du jeudi soir ! Mais ça peut aussi permettre à des artistes, graphistes ou même des marques de prototyper rapidement des designs de stickers avant une prod plus poussée. Plutôt que de partir d’une feuille blanche, autant utiliser l’IA pour générer des premiers jets et itérer à partir de là. Ça peut faire gagner un temps fou.

Sous le capot, le site utilise le modèle Albedo XL et des techniques de machine learning comme les LoRA (Learning Rate Adaptation) pour comprendre votre prompt et générer un visuel qui déchire. Les plus geeks d’entre vous apprécieront les performances de l’engin : un sticker généré en 10 secondes max grâce aux cartes graphiques Nvidia A40 . Ça envoie du lourd !

Et le must du must, c’est que StickerBaker est un projet open source , le code est dispo sur GitHub . Ça veut dire que la communauté peut mettre la main à la pâte pour améliorer l’outil. Vous pouvez par exemple bidouiller le code pour modifier les styles de stickers générés. Un vrai bonheur pour les devs qui veulent comprendre comment ça marche derrière.

Autre bon point, vos photos sont supprimées direct après le traitement. Pas de stockage chelou des données ou d’utilisations douteuses derrière, StickerBaker est clean de ce côté là. C’est toujours appréciable de nos jours.

Après, faut pas se leurrer, on est encore loin d’une app grand public. L’interface est rudimentaire et il faut un minimum biberonné à l’anglais et à l’univers des IA générative pour pas être largué. Mais c’est un premier pas encourageant vers la démocratisation de ces technologies.

Au final, StickerBaker c’est une chouette démo techno qui montre tout le potentiel de l’IA générative appliquée au domaine des stickers et du graphisme. Le projet n’en est qu’à ses débuts mais mérite clairement d’être suivi de près. Ça pourrait bien révolutionner notre manière de créer des visuels à l’avenir, qui sait ? En tout cas, moi j’ai hâte de voir les prochaines évolutions de ce genre d’outils !

Merci à Lorenper pour l’info.

Read 10 remaining paragraphs | Comments

Après plusieurs de ses rivaux, Proton s'ouvre enfin aux passkeys (clés d'accès), qui ont pour ambition de remplacer les mots de passe. À l'image de ses autres initiatives, Proton précise que sa prise en charge des passkeys couvre toutes ses formules, y compris l'offre gratuite, et respecte les principes de l'open source.

Elon Musk a annoncé la publication du code source de Grok, son IA générative rivale de ChatGPT. Un choix de l'open source qui permet en creux à l'entrepreneur américain de s'en prendre encore à OpenAI, dont les orientations ne lui plaisent pas.

La tentative d'AMD d'intégrer les fonctions du HDMI 2.1 dans son pilote graphique Linux open source a abouti à une impasse. Il existe de fortes tensions entre les besoins de l'open source et les exigences de conformité dictées par le HDMI Forum. Ce blocage, qui résulte de restrictions légales, inquiète pour l'avenir du support matériel dans les environnements open source.