Ssh – die besten Beiträge

Hintertür in xz gefunden - Kann man überhaupt noch einer Software vertrauen, die man nicht selbst geschrieben hat?

xz ist ein unter Linux weit verbreitetes Datenkompressionsformat. Ein Entwickler der Referenzimplementierung xz-utils (https://github.com/tukaani-project/xz) hat vor kurzem eine Hintertür (CVE-2024-3094) eingebaut, mit der in manchen Linux Distributionen sshd kompromittiert werden kann. Bisher wurde noch kein CVE Score zugewiesen, aber ich schätze diese Hintertür als sehr kritisch ein. Bestimmt werden in den nächsten Tagen Heise, Golem, etc. darüber berichten, und vielleicht sogar die Mainstream Medien.

Die Hintertür wurde gefunden, weil der Schadcode Performanceprobleme in sshd verursacht hat. Glücklicherweise sind die betroffenen xz Versionen noch nicht weit verbreitet, da Pakete in vielen Distributionen nur sehr langsam aktualisiert werden. In Arch Linux wurde bereits eine betroffene xz Version ausgeliefert, aber da sshd in Arch Linux kein gz verwendet, ist ein Angriff in diesem Fall nicht möglich.

Dennoch ist dieser Vorfall äußerst besorgniserregend, da die Hintertür von einem xz Entwickler eingebaut wurde, der bereits mehrere Jahre am Projekt beteiligt war und als vertrauenswürdig galt.

Grundsätzlich galt Open Source Software als weniger anfällig für Hintertüren als Closed Source Software. Man ging davon aus, dass Hintertüren in Open Source Software gefunden werden, bevor sie überhaupt veröffentlicht werden, da der Code von vielen unabhängigen Experten überprüft wird. Ein häufig genanntes Beispiel, das diese These untermauern soll, ist ein 2003 gescheiterter Versuch, eine Hintertür in den Linux Kernel einzubauen.

Der aktuelle Vorfall zeigt, dass es sehrwohl möglich ist, Schadcode unentdeckt in weit verbreitete Open Source Software einzubauen. Dies wirft die Frage auf, inwieweit man fremder Software überhaupt noch vertrauen kann.

Seid ihr selbst von dieser Hintertür betroffen? Wie schützt ihr euch? Habt ihr Zweifel an der Sicherheit von Open Source Software? Denkt ihr, dass dieser Vorfall zu einem Umdenken bei der Vertrauenswürdigkeit von Open Source Entwicklern führen wird?

Weitere Informationen
  • https://lwn.net/Articles/967180/
  • https://lwn.net/ml/oss-security/20240329155126.kjjfduxw2yrlxgzm@awork3.anarazel.de/
  • https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094
  • https://archlinux.org/news/the-xz-package-has-been-backdoored/
  • https://arstechnica.com/security/2024/03/backdoor-found-in-widely-used-linux-utility-breaks-encrypted-ssh-connections/
  • https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
Computer, Software, Linux, Sicherheit, IT, Backdoor, Code, Hacker, Hackerangriff, Informatik, IT-Sicherheit, Open Source, Softwareentwicklung, ssh, Vertrauen, Vertrauensbruch, Exploit, Exploits, IT-Sicherheitsexperte, Schwachstellen, vertrauenswürdig, sshd

Problem mit PHP-Composer: Was ist schief gelaufen?

Versuche hier grade auf meinem Server 2 verschiedene Librarys mithilfe von Composer zu installieren.

Leider ist wohl irgendwas bei der Installation von Composer gehörig schief gelaufen: Ich konnte zwar zunächst eine Library erfolgreich installieren aber es fing damit an, dass ich alle Composerdateien im /root Verzeichnis hatte. Diese wollte ich dann via Terminal nach /var/www/html verschieben (dabei muss aus irgendwelchen Gründen eine dazugehörige autoload.php verloren gegangen sein) also den kompletten Composerordner gelöscht und alles versucht neu zu installieren und aus der noch vorhandenen composer.phar versucht die Dateien neu zu extrahieren und dabei laut Terminal sogar auf die neueste Composer Version upgegradet: Dies hat zum Teil geklappt, nur eine extrem wichtige "composer.json" wurde dabei nicht erstellt. Also zunächst mal mit mehreren verschiedenen Anleitungen versucht diese manuell zu erstellen (was ja anscheinend in 5 Minuten problemlos möglich ist).

Naja das Problem ist nun, dass ich irgendwo festsitze. Ich habe die Anleitungen im Netz befolgt, aber bisher hab ich weder genau kapiert wieso diese extrem wichtige Datei nach erneuter Installation fehlt, noch was genau in diese Datei reingeschrieben werden muss oder per Script reingeschrieben wird (Name des Projekts? die Pfade (Namespaces?) der Packages, die ich installieren möchte?), noch wie ich folgenden Fehler beheben kann:

In ArrayLoader.php line 44:

Unknown package has no name defined ([]).

Diesen Fehler bekomme ich nun seit Stunden, egal was ich mit Composer versuche, auch wenn ich einfach versuche zu debuggen oder eine erneute Installation probiere...

Irgendwelche Ideen oder Ahnungen was hier falsch gelaufen ist?

Internet, Linux, IT, Webseite, programmieren, PHP, Putty, Script, ssh, Terminal, Composer, Kommandozeile, Debian 10

Meistgelesene Beiträge zum Thema Ssh