News Ubuntu 24.04 LTS ("Noble Numbat"): Schädlicher Code sorgt für schlechte Nachrichten

[PCGH-Redaktion]

Jetzt ist Ihre Meinung gefragt zu Ubuntu 24.04 LTS ("Noble Numbat"): Schädlicher Code sorgt für schlechte Nachrichten

Wie der britische Linux-Distributor Canonical bekannt gegeben hat, muss die erste Beta von Ubuntu 24.04 LTS ("Noble Numbat"), die heute hätte erscheinen sollen, aufgrund eines schädlichen Codes um eine Woche verschoben werden.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: Ubuntu 24.04 LTS ("Noble Numbat"): Schädlicher Code sorgt für schlechte Nachrichten

 

[Misanthrop68]

Welche Böse Jungs haben das Hintertürchen eingebracht. USA, China, Israel oder sogar Russland? Ich Tipp auf USA. Die haben die Mittel und Interesse für so was und ich trau es den zu. China hat sein eigenes Linux, Israel ist nicht so aktiv in Linux involviert und Russland hat nicht die Möglichkeiten so tief in Linux einzugreifen.
Nur gut das es raus gekommen ist und schnell behoben wird. Das ist der Vorteil von Linux.

 

[Schnitzelnator]

Das war vermutlich ein staatlicher Akteur, Social Engineering wurde genutzt, die Angreifer waren vermutlich mehrere Personen und zudem war das Loch geschickt versteckt (im Quelltext-Repository auf Github war es jedenfalls nicht, sondern nur im Tarball, in dem das Release herausgegeben wurde). Die Angreifer haben es geschafft, in Distributionen, die die aktuellsten Pakete liefern - so zum Beispiel einige Rolling Release Distributionen, über mehrere Wochen hinweg eine Backdoor zu integrieren.
Aber prinzipiell brauchte der Angriff nicht extrem viele Ressourcen - es kann auch eine kleinere Gruppierung gewesen sein.

Das Tool xz wird eigentlich zum Komprimieren von Daten verwendet und stellt mit LZMA einen sehr effizienten Algorithmus bereit. Es ist relativ unscheinbar, kommt aber auch bei SSH-Verbindungen zum Einsatz.

Zum Glück wurde die Backdoor entdeckt, bevor sie in die Release-Versionen der Distributionen gekommen ist, die häufig auf Servern genutzt werden. Auch wenn das im Prinzip zeigt, dass Open Source funktioniert, und solche Lücken von jemandem entdeckt werden, sind die Angreifer mit dem Teilerfolg schon zu weit gekommen und jeder Distributor sollte sich überlegen, wie er in Zukunft noch zuverlässiger solche Angriffe aufdecken kann.

Jedenfalls sollte jeder Linuxnutzer, der sehr aktuelle Pakete auf seine Systeme bekommt, schnellstmöglich seine Rechner updaten und wer ganz sicher gehen möchte/muss, sogar den Rechner neu aufsetzen (zumindest, wenn er per SSH irgendwie erreichbar war)
Für die breite Masse der Linuxnutzer, auf die das nicht zutrifft, kann zum Glück Entwarnung gegeben werden.

 

[Mazrim_Taim]

irre.
da wird einfach nicht was durchgeboxt sondern verschoben und gefixt.
Schon irre das da ein Unternehmen Rücksicht auf die Nutzer hat.

(ggf. etwas Sarkassmus enthalten)

 

[raPid-81]

Das war vermutlich ein staatlicher Akteur, Social Engineering wurde genutzt, die Angreifer waren vermutlich mehrere Personen und zudem war das Loch geschickt versteckt (im Quelltext-Repository auf Github war es jedenfalls nicht, sondern nur im Tarball, in dem das Release herausgegeben wurde). Die Angreifer haben es geschafft, in Distributionen, die die aktuellsten Pakete liefern - so zum Beispiel einige Rolling Release Distributionen, über mehrere Wochen hinweg eine Backdoor zu integrieren.

Ich empfehle dazu den Heise Artikel: https://www.heise.de/hintergrund/Die-xz-Hintertuer-das-verborgene-Oster-Drama-der-IT-9673038.html

Tatsächlich war die Vorbereitung 2 Jahre am Laufen.

Aus dem Heise Artikel:

Jia Tan erarbeitete sich schließlich im Lauf von zwei Jahren das Vertrauen des xz-Maintainers und wurde recht schnell zum offiziellen Co-Maintainer, der selbstständig neuen Code in das Projekt einbringen konnte.

Aber prinzipiell brauchte der Angriff nicht extrem viele Ressourcen - es kann auch eine kleinere Gruppierung gewesen sein.

Das Tool xz wird eigentlich zum Komprimieren von Daten verwendet und stellt mit LZMA einen sehr effizienten Algorithmus bereit. Es ist relativ unscheinbar, kommt aber auch bei SSH-Verbindungen zum Einsatz.

Zum Glück wurde die Backdoor entdeckt, bevor sie in die Release-Versionen der Distributionen gekommen ist, die häufig auf Servern genutzt werden. Auch wenn das im Prinzip zeigt, dass Open Source funktioniert, und solche Lücken von jemandem entdeckt werden, sind die Angreifer mit dem Teilerfolg schon zu weit gekommen und jeder Distributor sollte sich überlegen, wie er in Zukunft noch zuverlässiger solche Angriffe aufdecken kann.

Tatsächlich fragt man sich seit einigen Vorkommnissen ob Open Source wirklich so sicher ist wie behauptet wird. Diese Lücke hier wurde durch Zufall entdeckt, nicht durch die Code-Prüfung.

Dass es nicht so weit kam, verdanken wir der Neugier des Software-Entwicklers Andres Freund, der Dingen gern auf den Grund geht. Wie er selbst erklärte, störte seltsame CPU-Last seine Messungen auf einem Testsystem. Weiteres Nachforschen ergab, dass auf den Systemen mit der Hintertür ein fehlgeschlagener Log-in-Versuch via SSH etwa 500 Millisekunden länger brauchte, als auf Systemen mit älteren Versionen von liblzma.

Und da kommt dann zwangsläufig auch die soziale Komponente aufs Tapet, nämlich dass unglaublich viele wichtige Projekte auf den Schultern einzelner lasten, die damit letztlich hoffnungslos überfordert sind. Das hat bereits der oben aufgeführte xkcd-Comic perfekt illustriert. Es wurde im Rahmen des Heartbleed-Debakels bei Openssl als Problem ausgemacht und im Zug der Nachbereitung der Log4j-Lücke ausführlich diskutiert. Ich bin sehr gespannt, ob diesmal mehr bei diesen Diskussionen herauskommt, als noch mehr Magic Security Dust.

Da sind "wir" wirklich haarscharf an einer weltweiten Katastrophe vorbei geschrammt.

irre.
da wird einfach nicht was durchgeboxt sondern verschoben und gefixt.
Schon irre das da ein Unternehmen Rücksicht auf die Nutzer hat.

(ggf. etwas Sarkassmus enthalten)

Hier geht es nicht um Rücksicht, sondern um wissentliches verbreiten von gemeldeten Backdoors.

 

[empy]

Zusammenfassend kann man schon mal sagen, dass das ganze fast nur Betas oder Rolling-Release-Systeme betrifft, die wohl hoffentlich niemand offen im Netz hängend betreibt, wenn da auch nur etwas entfernt kritisches drauf läuft. Mein Desktopsystem ist auch "betroffen", aber da es ein Desktop ist, läuft kein SSH-Server darauf und er steht natürlich hinter einer Firewall. Das ist ein recht gutes Beispiel, warum mehrfache Sicherheitschichten sinnvoll sind. Inwiefern das den Release von Debian 12.6 betrifft, erschließt sich mir allgemein und auch aus dem Link nicht ganz. Debian verteilt normalerweise keine Featureupgrades in Minor-Releases und Debian 12 nutzt xz-utils in der Version 5.4.1.

Tatsächlich fragt man sich seit einigen Vorkommnissen ob Open Source wirklich so sicher ist wie behauptet wird. Diese Lücke hier wurde durch Zufall entdeckt, nicht durch die Code-Prüfung.

Ich glaube nicht, dass Angriffe auf die geschlossene Codebase in Unternehmen wirklich so viel schwieriger sind und niemand kann garantieren, dass nicht auch völlig absichtlich Angriffswege implementiert werden. Auf der anderen Seite können deutlich weniger Leute nachforschen, wenn Ungereimtheiten auftreten und die Kooperation mit externen Leuten, die Probleme vermuten kann auch einfach komplett verweigert werden. Von daher würde ich mal sagen, dass Open-Source im Schnitt immer noch deutlich sicherer als die Alternative ist.

 

[Pilo]

China, Russland und/oder Nordkorea. Spricht diese Panne nun FÜR oder WIDER Open Source? Ich mein, der Code wurde ja von einer (nick)namentlich bekannten, aber eigentlich völlig anonymen Quelle erfolgreich eingeschleust. Wäre der Code niemandem aufgefallen, wären tausende Systeme kompromitiert worden, ausspähbar und manipulier gewesen.

 

[Contragen]

Entdeckt, behoben, gut! Wie viele offene Flanken gab und gibt es in MacOS und Windows, die trotz Kenntnis spät oder nie behoben werden? In meiner Welt ein klares pro Linux. Wir werden noch öfter und ähnliche Fälle haben, Linux ist Konkurrenz, eine stark zunehmende.

 

[Speedbone]

China, Russland und/oder Nordkorea. Spricht diese Panne nun FÜR oder WIDER Open Source? Ich mein, der Code wurde ja von einer (nick)namentlich bekannten, aber eigentlich völlig anonymen Quelle erfolgreich eingeschleust. Wäre der Code niemandem aufgefallen, wären tausende Systeme kompromitiert worden, ausspähbar und manipulier gewesen.

In jedem Fall Open Source nicht nur da diese Probleme wenigstens auffallen können sondern gerade deswegen dass man den Code wenn nötig auch mal anpassen kann. Wie gerne würde ich einiges aus dem Source Code von Windows rauswerfen

 

[x2K]

Entdeckt, behoben, gut! Wie viele offene Flanken gab und gibt es in MacOS und Windows, die trotz Kenntnis spät oder nie behoben werden? In meiner Welt ein klares pro Linux. Wir werden noch öfter und ähnliche Fälle haben, Linux ist Konkurrenz, eine stark zunehmende.

Also ich halte Linux auch für ein sicheres System, allerdings kann der Anwender extrem leicht Lücken reißen wenn die Konfiguration nicht korrekt gemacht wurde. Und diese Sammlung aus hunderten eigener config dateien, die jeh nach Paket mal hier mal dort liegen sind nicht so schön einheitlich, was meinen inneren Monk extrem nervt. Schön wäre so etwas wie die registry von windows nur besser umgesetzt und durchdacht.

 

[wurstkuchen]

Hier wird übrigens darauf hingeweisen, dass der Jia Tan xz Trojaner scheinbar auch auf jedem Windows 11 22h2 Rechner der Welt just in diesem Moment existiert, aber darüber berichten kaum Medien:

https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006600#gistcomment-5006600

https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27?permalink_comment_id=5006612#gistcomment-5006612

 

[empy]

Also ich halte Linux auch für ein sicheres System, allerdings kann der Anwender extrem leicht Lücken reißen wenn die Konfiguration nicht korrekt gemacht wurde.

Dafür müssen ja erstmal überhaupt Ports aufgemacht werden und man ist in der Regel schon sehr bemüht, dass die Standardkonfiguration sicher ist.

Und diese Sammlung aus hunderten eigener config dateien, die jeh nach Paket mal hier mal dort liegen sind nicht so schön einheitlich, was meinen inneren Monk extrem nervt.

Eigentlich liegt das doch alles unter /etc/.

Schön wäre so etwas wie die registry von windows nur besser umgesetzt und durchdacht.

Wäre das nicht die sysctl?

Hier wird übrigens darauf hingeweisen, dass der Jia Tan xz Trojaner scheinbar auch auf jedem Windows 11 22h2 Rechner der Welt just in diesem Moment existiert, aber darüber berichten kaum Medien:

Es ist halt noch nicht geklärt, ob dadurch eine Lücke vorliegt. Bis jetzt ist ja nur sicher, dass sshd, also der Linux-SSH-Server, angreifbar ist, wenn es eine dieser bestimmten Versionen von xz für die Kompression verwendet.

 

[Schnitzelnator]

Tatsächlich fragt man sich seit einigen Vorkommnissen ob Open Source wirklich so sicher ist wie behauptet wird. Diese Lücke hier wurde durch Zufall entdeckt, nicht durch die Code-Prüfung.

Es ist richtig, dass die Lücke durch Zufall entdeckt wurde und das ist auch gut so, aber eine Codeprüfung hätte sie eventuell vor dem Release einer z.B. durch Wartungsverträge bezahlten Distribution auch entdecken können.

Trotzdem kann man als Open Source-Gemeinschaft nicht zufrieden damit sein und sollte sich überlegen, die Prozesse zu verbessern - das habe ich ja bereits erwähnt.

Aus meiner Sicht kann das aber nicht als Argument für Closed-Source taugen, denn genau da gibt es ja solche Zufallsentdeckungen aus Mangel an Quelltext nicht, sondern - wenn überhaupt - nur interne Security-Audits, die es natürlich für Open Source-Code genauso gibt. Wenn also jemand zufällig Lücken entdeckt, ist das aus meiner Sicht ausschließlich ein Argument für die Sicherheit von Open Source Code und zeigt auch, warum genau das Zur-Verfügung-Stellen des Codes hilfreich ist.

 

[FCA]

Nur gut das es raus gekommen ist und schnell behoben wird. Das ist der Vorteil von Linux.

Microsoft-Ingenieur Andres Freund hat gute Arbeit geleistet

 

[raPid-81]

Aus meiner Sicht kann das aber nicht als Argument für Closed-Source taugen, denn genau da gibt es ja solche Zufallsentdeckungen aus Mangel an Quelltext nicht, sondern - wenn überhaupt - nur interne Security-Audits, die es natürlich für Open Source-Code genauso gibt.

Zu sagen dass "Open Source" nicht so sicher ist wie behauptet wird ist nicht automatisch ein Argument für "Closed Source".

 

[Schnitzelnator]

Zu sagen dass "Open Source" nicht so sicher ist wie behauptet wird ist nicht automatisch ein Argument für "Closed Source".

Sorry, wenn ich Dich missverstanden habe. In den Kommentaren unter dem von Dir verlinkten Heise-Artikel ist da teilweise in diese Kerbe geschlagen worden - Deshalb mein Beitrag.

 

[empy]

Zu sagen dass "Open Source" nicht so sicher ist wie behauptet wird ist nicht automatisch ein Argument für "Closed Source".

Unangreifbar ist leider nichts und solche Injektionen sind leider auch nichts neues. Aber allgemein würde ich die Tatsache, dass man so oft was von Lücken oder Angriffen hört, die gefunden und schnell unschädlich gemacht wurden, eher als positives Zeichen werten, auch wenn man intuitiv erstmal andersrum denkt.

 

[raPid-81]

Unangreifbar ist leider nichts und solche Injektionen sind leider auch nichts neues. Aber allgemein würde ich die Tatsache, dass man so oft was von Lücken oder Angriffen hört, die gefunden und schnell unschädlich gemacht wurden, eher als positives Zeichen werten, auch wenn man intuitiv erstmal andersrum denkt.

Das trifft aber auch auf "Closed Source" zu, oder nicht? Natürlich abgesehen von Hardware-Lücken die man nicht so einfach (oder gar nicht) per Update fixen kann.

Wenn eine Lücke in einer "Closed Source" Software gemeldet wird, dann ist der Hersteller gezwungen schnell einen Fix zu liefern. Ansonsten ist seine Software (und sein Unternehmen) schneller weg vom Fenster als die Aktionäre ihre Aktien loswerden können.

Darum dreht sich die Diskussion zwischen den Lagern ja (auch). Bei "Open Source" lastet häufig viel Arbeit auf einigen wenigen freiwilligen Programmierern, die teilweise unentgeltlich arbeiten. Das ist in diesem Fall der Grund für den "Super GAU" gewesen.

Wer weiss wie oft (und wo) so eine Backdoor bereits erfolgreich integriert wurde? Aktuell prüft daher die Community sämtlichen Code, was ewig dauern wird.

Und jetzt ist man auf demselben Stand wie bei "Closed Source" wo ggf. auch Geheimdienste Code eingeschleust haben. Man weiss nicht wo und in welchem Umfang das passiert ist.

 

[DJKuhpisse]

Zum Glück wurde die Backdoor entdeckt, bevor sie in die Release-Versionen der Distributionen gekommen ist, die häufig auf Servern genutzt werden. Auch wenn das im Prinzip zeigt, dass Open Source funktioniert, und solche Lücken von jemandem entdeckt werden, sind die Angreifer mit dem Teilerfolg schon zu weit gekommen und jeder Distributor sollte sich überlegen, wie er in Zukunft noch zuverlässiger solche Angriffe aufdecken kann.

Das ganze ist nur durch einen glücklichen Zufall aufgefallen, denn die Hintertür hat ein Performanceproblem ausgelöst und jemand hat das analysiert. Wäre eines davon nicht passiert, wäre der vermutlich in viele Produktivsysteme eingegangen.

Freie Software ist da zwar nicht immun dagegen, aber immer noch die beste Lösung, da man die Hürde, sowas erfolgreich durchzubringen, viel höher setzt. Hier wurde die aber überwunden.

 

[empy]

Das trifft aber auch auf "Closed Source" zu, oder nicht?

Naja, wer weiß schon, was da alles unter den Teppich gekehrt wird?

Wenn eine Lücke in einer "Closed Source" Software gemeldet wird, dann ist der Hersteller gezwungen schnell einen Fix zu liefern. Ansonsten ist seine Software (und sein Unternehmen) schneller weg vom Fenster als die Aktionäre ihre Aktien loswerden können.

Das kommt immer ein bisschen auf die Lücke an, in diesem Fall hätte man die Lücke ohne den Schlüssel z.B. nur schlecht nachweisen können und auch allgemein ist es einfach ungleich schwerer eine Lücke zu finden oder nachzuweisen, wenn man keinen Zugriff auf den Code hat. Ein Angreifer, der in geschlossenem Code agiert, hat da schon deutlich bessere Chancen unentdeckt zu bleiben, als einer, der das in offenem Code tut.

Darum dreht sich die Diskussion zwischen den Lagern ja (auch). Bei "Open Source" lastet häufig viel Arbeit auf einigen wenigen freiwilligen Programmierern, die teilweise unentgeltlich arbeiten. Das ist in diesem Fall der Grund für den "Super GAU" gewesen.

Das ist sicher ein Problem, wenn kritische Infrastruktur darauf aufbaut. Dadurch, dass alles aber von vielen geprüft und auch in unkritischeren Szenarien verwendet wird, bevor es in die kritischeren Systeme wandert, sind die Chancen aber recht hoch, dass so was noch rechtzeitig erkannt wird. Das hätte jetzt z.B. noch über ein Jahr lang unbemerkt bleiben müssen, um in den ersten Debiansystemen zu landen.

Wer weiss wie oft (und wo) so eine Backdoor bereits erfolgreich integriert wurde? Aktuell prüft daher die Community sämtlichen Code, was ewig dauern wird.

Das passiert ja mehr oder weniger durchgehend. Jetzt wird erst mal von diesen Paket ausgehend nachgeforscht und vermutlich werden Maintainer mal scharf nachdenken, ob sie schon mal was unter der Nase hatten, was ähnliche Möglichkeiten eröffnen würde und das noch mal nachprüfen. Dadurch, dass da sehr viele ein Interesse daran haben, das zu lösen, schätze ich die Menge an Mitarbeitern bei der Suche und die Motivation deutlich höher ein als bei geschlossenem Code, wo eine einzelne Firma Leute abstellen müsste.

Und jetzt ist man auf demselben Stand wie bei "Closed Source" wo ggf. auch Geheimdienste Code eingeschleust haben. Man weiss nicht wo und in welchem Umfang das passiert ist.

Naja, es ist nicht so, als wäre man sich der Gefahr erst jetzt bewusst geworden, aber wie gesagt, absolute Sicherheit gibt es natürlich nicht.

Freie Software ist da zwar nicht immun dagegen, aber immer noch die beste Lösung, da man die Hürde, sowas erfolgreich durchzubringen, viel höher setzt. Hier wurde die aber überwunden.

Man ist schon extrem weit gekommen, ein wirklicher Schaden sollte aber nicht entstanden sein. Von daher müsste man es nicht unbedingt als Erfolg werten.