Backdoor in xz

[Martin Klaiber]

Aufgeschreckt von folgender Security-E-Mail von Debian:

<https://lists.debian.org/debian-security-announce/2024/msg00057.html>

stöberte ich etwas weiter im web und fand

<https://lwn.net/Articles/967180/>

Ich muss gestehen, dass ich schockiert bin. Dass diese Person (oder
mehrere, die sich hinter dem Namen Jia Tan verbergen) es geschafft
hat, den Rang eines Maintainers zu erreichen und über mehrere Jahre
Schadcode einbauen konnte, ohne entdeckt zu werden.

Nun frage ich mich, ob ob in Linux vielleicht schon etliche Backdoors
existieren, ohne dass man davon weiß.

Hier hat sich jemand den zeitlichen Ablauf angeschaut:

<https://boehs.org/node/everything-i-know-about-the-xz-backdoor>

Demnach wurde offenbar bei dem xz-Projekt, bei dem der ursprüngliche
Maintainer überlastet war, Druck ausgeübt, einen weiteren Maintainer
zu installieren, wobei diese Person vorher schon off-list mit dem
ursprünglichen Maintainer zusammengearbeitet hat und sich vermutlich
so ein gewisses Vertrauen erarbeiten konnte.

Der neue Maintainer ging dabei wohl auch ziemlich perfide vor, indem er
bat, entdeckte Sicherheitslücken erstmal nur privat ihm zu melden und
nicht öffentlich zu machen, mit dem Hinweis, dass so weniger Gefahr
bestünde, dass der Exploit ausgenützt werden kann, bevor der Patch
fertig ist. Im Nachhinein wird natürlich klar, dass das vermutlich
einen ganz anderen Grund hatte. Siehe:

<https://news.ycombinator.com/item?id=39866275>

Alles ziemlich krass, finde ich. Und ich frage mich, ob wir in der
Opensource-Community vielleicht zu blauäugig sind und zu sehr davon
ausgehen, dass alle Beteiligten die uneigennützigen Ziele teilen?

Oder habt ihr mit so etwas gerechnet und bin nur ich zu blauäugig
gewesen? Ich muss gestehen, mit so viel krimineller Energie hatte
ich nicht gerechnet.

Martin

P.S. Ich war unsicher, ob das nach dcoulm oder dcsm soll. Habe mich
dann für dcoulm entschieden, weil es ja doch linux-spezifisch ist.

[Marco Moock]

Post by Martin Klaiber
Ich muss gestehen, dass ich schockiert bin. Dass diese Person (oder
mehrere, die sich hinter dem Namen Jia Tan verbergen) es geschafft
hat, den Rang eines Maintainers zu erreichen und über mehrere Jahre
Schadcode einbauen konnte, ohne entdeckt zu werden.

Das ist krass, aber wenn ich ehrlich bin, nicht verwunderlich. Die
Menge an Code ist sehr, sehr groß und bei manchen Projekten arbeiten
nur wenige Personen mit, die sich damit auskennen und eine Codeanalyse
dann sinnvoll durchführen können.
Die Pakete werden halt trotzdem übernommen, weil es nicht genügend
Leute gibt, die bei jedem Projekt wirklich jeden Commit angucken.

Post by Martin Klaiber
Nun frage ich mich, ob ob in Linux vielleicht schon etliche Backdoors
existieren, ohne dass man davon weiß.

Kann gut sein bei der Menge an Code, den es in den Repos so gibt.
Vorteil des Ganzen ist und bleibt jedoch, dass die Hintertüren da
schwerer zu installieren und geheimzuhalten sind. Letzteres ist in
diesem Fall jetzt erledigt. Bei proprietärer Software wäre das
vermutlich nie passiert.

Post by Martin Klaiber
Alles ziemlich krass, finde ich. Und ich frage mich, ob wir in der
Opensource-Community vielleicht zu blauäugig sind und zu sehr davon
ausgehen, dass alle Beteiligten die uneigennützigen Ziele teilen?

Böse Leute gibt es immer und überall. Nur mehr Kontrolle kann das
eindämmen. Dazu braucht es aber Leute, die die entsprechenden
Programmiersprachen können und das Programm verstehen, die dann Zeit
investieren, solche Hintertüren zu suchen.

Post by Martin Klaiber
Oder habt ihr mit so etwas gerechnet und bin nur ich zu blauäugig
gewesen?

Wenn ich ehrlich bin, nein. Wenn ich aber drüber nachdenke, hätte ich
das tun müssen. Die Wahrscheinlichkeit, dass sowas bei der Fülle an
Leuten und Software mit Verbreitungsgrad nicht passiert, ist einfach zu
gering.

[Peter J. Holzer]

Post by Marco Moock

Post by Martin Klaiber
Ich muss gestehen, dass ich schockiert bin. Dass diese Person (oder
mehrere, die sich hinter dem Namen Jia Tan verbergen) es geschafft
hat, den Rang eines Maintainers zu erreichen und über mehrere Jahre
Schadcode einbauen konnte, ohne entdeckt zu werden.

Das ist krass, aber wenn ich ehrlich bin, nicht verwunderlich.

ACK. Kein kleines Open-Source-Projekt macht einen Background-Check,
bevor man einen neuen Maintainer akzeptiert. Man schaut sich die
bisherigen Contributions an, und wenn jemand über längere Zeit gute
Arbeit macht, fragt man ihn irgendwann, ob er nicht Co-Maintainer werden
will. (Abgesehen davon ist unklar, wie effektiv ein solcher Check wäre.)

Post by Marco Moock
Die Menge an Code ist sehr, sehr groß und bei manchen Projekten
arbeiten nur wenige Personen mit, die sich damit auskennen und eine
Codeanalyse dann sinnvoll durchführen können.
Die Pakete werden halt trotzdem übernommen, weil es nicht genügend
Leute gibt, die bei jedem Projekt wirklich jeden Commit angucken.

Ich glaube, du vermischt hier das Projekt (xz-utils) und die
Distribution (Debian). Zweifellos beides wichtig, aber deutlich anderes
Problem.

Post by Marco Moock

Post by Martin Klaiber
Nun frage ich mich, ob ob in Linux vielleicht schon etliche Backdoors
existieren, ohne dass man davon weiß.

Kann gut sein bei der Menge an Code, den es in den Repos so gibt.
Vorteil des Ganzen ist und bleibt jedoch, dass die Hintertüren da
schwerer zu installieren und geheimzuhalten sind.

Wie man hier ja auch gesehen hat. Die betroffenen Versionen sind noch
nicht in den Stable/LTS-Versionen von Debian und Ubuntu und Redhat.
Das Problem wurde während der Testing-Phase entdeckt: Mission
accomplished, würde ich sagen.

Post by Marco Moock
Letzteres ist in diesem Fall jetzt erledigt. Bei proprietärer Software
wäre das vermutlich nie passiert.

Vielleicht, vielleicht auch nicht. Jedenfalls hätte es jemanden mit
spezialisierteren Skills gebraucht als hier (Andres ist, wie er selbst
schreibt "*not* a security researcher, nor a reverse engineer" - er ist
einer der Core-Developer von PostgreSQL). Andererseits garantiert Open
Source auch nicht, dass das Backdoors rechtzeitig gefunden werden. Es
sind schon security-relevante Bugs entdeckt worden, die jahrelang
vorhanden waren. Genauer schaut man halt nur hin, wenn etwas auffällig
ist (wie hier die drastisch schlechtere Performance).

hp

[Marco Moock]

Post by Peter J. Holzer

Post by Marco Moock
Kann gut sein bei der Menge an Code, den es in den Repos so gibt.
Vorteil des Ganzen ist und bleibt jedoch, dass die Hintertüren da
schwerer zu installieren und geheimzuhalten sind.

Wie man hier ja auch gesehen hat. Die betroffenen Versionen sind noch
nicht in den Stable/LTS-Versionen von Debian und Ubuntu und Redhat.
Das Problem wurde während der Testing-Phase entdeckt: Mission
accomplished, würde ich sagen.

Nicht ganz, denn das Teil hat es auf Produktivsysteme geschafft -
manche setzen die Entwicklerversionen ein und Rolling-Release gibt es
bei so manchem OS auch.

Post by Peter J. Holzer

Post by Marco Moock
Letzteres ist in diesem Fall jetzt erledigt. Bei proprietärer
Software wäre das vermutlich nie passiert.

Vielleicht, vielleicht auch nicht. Jedenfalls hätte es jemanden mit
spezialisierteren Skills gebraucht als hier (Andres ist, wie er selbst
schreibt "*not* a security researcher, nor a reverse engineer" - er
ist einer der Core-Developer von PostgreSQL). Andererseits garantiert
Open Source auch nicht, dass das Backdoors rechtzeitig gefunden
werden. Es sind schon security-relevante Bugs entdeckt worden, die
jahrelang vorhanden waren. Genauer schaut man halt nur hin, wenn
etwas auffällig ist (wie hier die drastisch schlechtere Performance).

Und das zeigt, dass eben in der Praxis in vielen Fällen nicht alles von
vielen unabhängigen Leuten geprüft wird, sondern in manchen Fällen gar
nicht. Erst, wenn es dann zu einem Problem kommt, wird geschaut. Hier
ist es zufällig aufgefallen. Hätte die Backdoor nicht zum
Performance-Problem geführt, wäre die wohl heute noch drin.

[Peter J. Holzer]

Post by Marco Moock

Post by Peter J. Holzer

Post by Marco Moock
Kann gut sein bei der Menge an Code, den es in den Repos so gibt.
Vorteil des Ganzen ist und bleibt jedoch, dass die Hintertüren da
schwerer zu installieren und geheimzuhalten sind.

Wie man hier ja auch gesehen hat. Die betroffenen Versionen sind noch
nicht in den Stable/LTS-Versionen von Debian und Ubuntu und Redhat.
Das Problem wurde während der Testing-Phase entdeckt: Mission
accomplished, würde ich sagen.

Nicht ganz, denn das Teil hat es auf Produktivsysteme geschafft -
manche setzen die Entwicklerversionen ein

Was meinst Du mit "Entwicklerversion"? Den Upstream-Tarball oder das
Git-Repo? Da hatte man das Problem nicht, denn die Sicherheitslücke
wurde nur eincompiliert, wenn man ein .deb oder .rpm-Paket baut.

Debian Testing? Ja, da hatte man die Sicherheitslücke. Aber wenn man das
auf Produktivsystemen einsetzt, sollte man sich der Risiken bewusst
sein.

In aller Deutlichkeit: Der Zweck von Debian Testing ist es, Bugs zu
entdecken und zu beheben, bevor sie in Debian Stable kommen. Das hat
hier funktioniert.

Post by Marco Moock
und Rolling-Release gibt es bei so manchem OS auch.

Wenn man das einsetzt, muss man halt damit rechnen, dass man wenig
getesteten Code bekommt. Dafür aber schneller.

Hat aber nichts damit zu tun, dass Debian Testing hier seine Funktion
erfüllt hat.

Post by Marco Moock

Post by Peter J. Holzer

Post by Marco Moock
Letzteres ist in diesem Fall jetzt erledigt. Bei proprietärer
Software wäre das vermutlich nie passiert.

Vielleicht, vielleicht auch nicht. Jedenfalls hätte es jemanden mit
spezialisierteren Skills gebraucht als hier (Andres ist, wie er selbst
schreibt "*not* a security researcher, nor a reverse engineer" - er
ist einer der Core-Developer von PostgreSQL). Andererseits garantiert
Open Source auch nicht, dass das Backdoors rechtzeitig gefunden
werden. Es sind schon security-relevante Bugs entdeckt worden, die
jahrelang vorhanden waren. Genauer schaut man halt nur hin, wenn
etwas auffällig ist (wie hier die drastisch schlechtere Performance).

Und das zeigt, dass eben in der Praxis in vielen Fällen nicht alles von
vielen unabhängigen Leuten geprüft wird, sondern in manchen Fällen gar
nicht. Erst, wenn es dann zu einem Problem kommt, wird geschaut. Hier
ist es zufällig aufgefallen. Hätte die Backdoor nicht zum
Performance-Problem geführt, wäre die wohl heute noch drin.

Sage ich ja.

hp

[Marco Moock]

Post by Peter J. Holzer

Post by Marco Moock

Post by Peter J. Holzer

Post by Marco Moock
Kann gut sein bei der Menge an Code, den es in den Repos so gibt.
Vorteil des Ganzen ist und bleibt jedoch, dass die Hintertüren da
schwerer zu installieren und geheimzuhalten sind.

Wie man hier ja auch gesehen hat. Die betroffenen Versionen sind
noch nicht in den Stable/LTS-Versionen von Debian und Ubuntu und
Mission accomplished, würde ich sagen.

Nicht ganz, denn das Teil hat es auf Produktivsysteme geschafft -
manche setzen die Entwicklerversionen ein

Was meinst Du mit "Entwicklerversion"?

Debian Unstable/Testing, Slackware current, RHEL-next usw.

Post by Peter J. Holzer
Den Upstream-Tarball oder das Git-Repo? Da hatte man das Problem
nicht, denn die Sicherheitslücke wurde nur eincompiliert, wenn man
ein .deb oder .rpm-Paket baut.

Also war der Angriff auf Systeme mit genau diesem Paketformat gedacht.

Post by Peter J. Holzer
Debian Testing? Ja, da hatte man die Sicherheitslücke. Aber wenn man
das auf Produktivsystemen einsetzt, sollte man sich der Risiken
bewusst sein.

Da ist nur deswegen nicht in stable gekommen, weil das
Performance-Problem bemerkt wurde. Wäre das nicht passiert, hätte
da keiner Zweifel gehabt und es ist einfach zeitlich glücklich gelaufen.

Post by Peter J. Holzer
In aller Deutlichkeit: Der Zweck von Debian Testing ist es, Bugs zu
entdecken und zu beheben, bevor sie in Debian Stable kommen. Das hat
hier funktioniert.

Auf eine Art und Weise, wie man solche Backdoors aber nicht zweifels
findet, sondern nur dann, wenn diese andere Probleme verursachen.

Mein Fazit: Bei manchen Projekten gucken zu wenige Leute die Änderungen
an. Ich mache da aber niemandem einen Vorwurf, denn das basiert halt
alles auf Freiwilligkeit.

Post by Peter J. Holzer

Post by Marco Moock
und Rolling-Release gibt es bei so manchem OS auch.

Wenn man das einsetzt, muss man halt damit rechnen, dass man wenig
getesteten Code bekommt. Dafür aber schneller.

Testen hilft hier aber nicht zwingend, denn die Backdoor ist nur
aufgefallen, weil die ein Problem verursacht hat. Wäre das nicht
passiert, wäre die sicher auch in den stable-Varianten gelandet.

[Peter J. Holzer]

Post by Marco Moock
Mein Fazit: Bei manchen Projekten gucken zu wenige Leute die Änderungen
an.

Nicht bei einigen. Bei ALLEN, die irgendeine Art von Upstream haben.

Das weiß man aber seit Jahrzehnten.

hp

[Marco Moock]

Post by Peter J. Holzer

Post by Marco Moock
Mein Fazit: Bei manchen Projekten gucken zu wenige Leute die
Änderungen an.

Nicht bei einigen. Bei ALLEN, die irgendeine Art von Upstream haben.
Das weiß man aber seit Jahrzehnten.

Wobei das irgendwie immer noch besser ist als eine Software, bei der
das gar nicht erst möglich ist.

[Peter J. Holzer]

Post by Marco Moock

Post by Peter J. Holzer

Post by Marco Moock
Mein Fazit: Bei manchen Projekten gucken zu wenige Leute die
Änderungen an.

Nicht bei einigen. Bei ALLEN, die irgendeine Art von Upstream haben.
Das weiß man aber seit Jahrzehnten.

Wobei das irgendwie immer noch besser ist als eine Software, bei der
das gar nicht erst möglich ist.

Ja, aber da waren wir auch schon. Mir ist vollkommen unklar, was du
eigentlich sagen willst.

hp

[Thomas Hochstein]

Post by Marco Moock

Post by Peter J. Holzer
Nicht bei einigen. Bei ALLEN, die irgendeine Art von Upstream haben.
Das weiß man aber seit Jahrzehnten.

Wobei das irgendwie immer noch besser ist als eine Software, bei der
das gar nicht erst möglich ist.

Das lässt sich so allgemein nicht sagen.

Closed source mit funktionierender QA ist besser als open source ohne QA.

[Marco Moock]

Post by Thomas Hochstein
Closed source mit funktionierender QA ist besser als open source ohne QA.

Der Kreis der Einseher ist da aber begrenzt und oft auch im Handeln
limitiert.
Wenn die Firma da Hintertüren einbauen will, ist das viel einfacher,
weil der Kreis der Leute, die davon Kenntnis erlangen (können), viel
kleiner ist.

[Thomas Hochstein]

Post by Marco Moock
Wenn die Firma da Hintertüren einbauen will, ist das viel einfacher,
weil der Kreis der Leute, die davon Kenntnis erlangen (können), viel
kleiner ist.

Klar. Wenn eine Firma oder Distribution irgendwo Hintertüren einbauen
will, ist das aber etwas anderes als Fehler oder Hintertüren durch einen
einzelnen Entwickler.

[Marc Haber]

Post by Thomas Hochstein
Closed source mit funktionierender QA ist besser als open source ohne QA.

Nur dass man nicht sieht ob die QA funktioniert.

Selbst Microsoft leistet sich da - insbesondere bei den
Security-Updates - nahezu monatlich Dinge die eigentlich gar nicht
gehen.

Grüße
Marc

[Thomas Hochstein]

Post by Marc Haber

Post by Thomas Hochstein
Closed source mit funktionierender QA ist besser als open source ohne QA.

Nur dass man nicht sieht ob die QA funktioniert.

Keine Frage.

Es ist eben nur auch nicht umgekehrt so, dass open source ggü. closed
source grundsätzlich überlegen wäre. Das ist in der Theorie so, nicht aber
in der Praxis.

[Marc Haber]

Post by Thomas Hochstein
Es ist eben nur auch nicht umgekehrt so, dass open source ggü. closed
source grundsätzlich überlegen wäre. Das ist in der Theorie so, nicht aber
in der Praxis.

Ich ziehe es trotzdem vor, solche Dinge beim Bekanntwerden zeitnah von
neutraler Seite analysiert zu bekommen und den Bugfix zu sehen.

Grüße
Marc

[Kay Martinen]

Post by Thomas Hochstein

Post by Marc Haber

Post by Thomas Hochstein
Closed source mit funktionierender QA ist besser als open source ohne QA.

Nur dass man nicht sieht ob die QA funktioniert.

Keine Frage.
Es ist eben nur auch nicht umgekehrt so, dass open source ggü. closed
source grundsätzlich überlegen wäre. Das ist in der Theorie so, nicht aber
in der Praxis.

Wie Marc schon meinte ist die Closed-Source Seite da keinen Deut besser.

Und seit Heartbleed bekannt wurde frage ich mich durch welche Änderungen
man "Wieder" dahin kommen könnte das Open-Source diesem "Versprechen"
besser zu sein; oder sein zu können; wieder näher kommen könnte.

Die Leute die den Code schreiben, aktualisieren oder überprüfen sind ja
entweder Freiwillige, Enthusiasten, Angestellt und dafür freigestellt
oder andere - wie hier offenbart zu sein scheint.

Freiwillige kann man nicht auf bestimmtes ansetzen, Angestellte sind
möglicherweise von der Agenda ihres AG abhängig und dann bleibt doch nur
Unabhängige Bezahlte Arbeit als möglicher Lösungsweg.

Unabhängig von Staatlichen Einflüssen und Wirtschaftlichen Forder- und
Förderungen die evtl. mit Hintergedanken verbundenen sind. Denn das
würde sicher irgendwann in Richtung Staatstrojaner oder Tracking und
Datenschnorchelei wandern.

Unter dem Stichwort "Öffentlich Gefördert = Öffentlicher Code" ist ja
schon mal eine Initiative da. Aber wer würde Geld zur Verfügung stellen
das einzig zu dem Zweck verwendet werden dürfe andere bestehende
Weiträumig Genutzte Open Source Software auf Fehler zu Prüfen und zu
Reparieren - und damit einen Mangel in dieser Richtung zu mildern?

Wenn man einem Smombie erklären wollte das sein Android im Kern ein
Linux ist das von Google modifiziert wird und das er doch etwas Spenden
solle um der Qualität der Entwicklung von Linux-Software (die er
sicherlich auch auf seinem Gerät hätte) zu fördern... der Kuckt einen
doch nur Blöde grinsend an (vermute ich) und geht seiner Wege.

Die Bürger interessieren sich doch schlicht nicht dafür was für Ranzige
und Verwanzte Hard- und Soft-ware sie täglich mit sich herum tragen.

Könnte man nicht wie die GEMA bei Datenträgern eine Art Pflichtabgabe
bei jedem Kauf eines mit Software versehenen Gerätes einführen? So als
Unabhängige Software-aktualisierungs Bonus. Ein Stück Hardware das nur
mit der Software funktioniert ist auch nur ein Vervielfältigungsstück.
Aber im Gegensatz zu Papier (Kopiererabgabe?) und Musik o.a. kann es
sehr wohl veralten und damit unsicher werden. Und die Hersteller stehlen
sich nach der Gewährleistung ja gern mal aus der Pflicht. Neues
Gerät=Neue Software. Ist auch nicht nachhaltig, selbst mit
Altgerät-rücknahme und Recycling bleibt immer noch ein Finanzieller
Verlust für den Nutzer der für etwas bessere HW, aktuellere Software und
eventuell weniger Fehler ein oft über-teures Neugerät kaufen mußte - wo
das alte mit Updates noch Jahre lang nutzbar gewesen wäre.


Bye/
/Kay

[Marco Moock]

Post by Kay Martinen
Könnte man nicht wie die GEMA bei Datenträgern eine Art Pflichtabgabe
bei jedem Kauf eines mit Software versehenen Gerätes einführen? So
als Unabhängige Software-aktualisierungs Bonus. Ein Stück Hardware
das nur mit der Software funktioniert ist auch nur ein
Vervielfältigungsstück. Aber im Gegensatz zu Papier (Kopiererabgabe?)
und Musik o.a. kann es sehr wohl veralten und damit unsicher werden.
Und die Hersteller stehlen sich nach der Gewährleistung ja gern mal
aus der Pflicht.

Nein danke, auf noch so einen Mist kann ich gerne verzichten.
Bereits der GEMA-Irrsinn bedeutet, dass an die geld geht, auch wenn nie
Privatkopien GEMA-urheberrechtlich geschützter Werke dort gespeichert
werden. Was soll der Mist?

[Martin Schnitkemper]

Post by Marco Moock

Post by Peter J. Holzer
Den Upstream-Tarball oder das Git-Repo? Da hatte man das Problem
nicht, denn die Sicherheitslücke wurde nur eincompiliert, wenn man
ein .deb oder .rpm-Paket baut.

Also war der Angriff auf Systeme mit genau diesem Paketformat gedacht.

Da verstehe ich den Zusammenhang nicht, was die Sicherheitslücke mit dem
Paketformat zu tun hat.

Es geht doch um die liblzma, die mit dem xz-Paket ausgeliefert wird,
unabhängig von dessen Format. Nach dem, was bisher bekannt ist, betrifft es
einen unbefugten Fernzugriff über SSH durch Umgehung der SSHD-
Authentifizierung. Beispielsweise linkt Arch openssh nicht direkt zur
liblzma, daher ist diese Angriffsmethode hier nicht möglich.

Post by Marco Moock
Da ist nur deswegen nicht in stable gekommen, weil das
Performance-Problem bemerkt wurde. Wäre das nicht passiert, hätte
da keiner Zweifel gehabt und es ist einfach zeitlich glücklich gelaufen.

Das sehe ich auch so

Post by Marco Moock
Mein Fazit: Bei manchen Projekten gucken zu wenige Leute die Änderungen
an. Ich mache da aber niemandem einen Vorwurf, denn das basiert halt
alles auf Freiwilligkeit.

Trotzdem hätte auch ich gedacht, dass alle Änderungen oder Erweiterungen
nach dem Vier-Augen-Prinzip einen Audit durchlaufen, bei dem mindestens ein
weiterer erfahrener Entwickler die Änderungen vor Freigabe überprüft. Das
jemand, egal welchen Vertrauensstatus er genießt, unbemerkt vor den Augen
der anderen Entwickler und Mitwirkenden an einer Backdoor basteln kann,
sollte doch das Sicherheitskonzept in Frage stellen.

Post by Marco Moock
Testen hilft hier aber nicht zwingend, denn die Backdoor ist nur
aufgefallen, weil die ein Problem verursacht hat. Wäre das nicht
passiert, wäre die sicher auch in den stable-Varianten gelandet.

Genau so isses

[Thomas Noll]

Post by Martin Schnitkemper

Post by Marco Moock
Mein Fazit: Bei manchen Projekten gucken zu wenige Leute die Änderungen
an. Ich mache da aber niemandem einen Vorwurf, denn das basiert halt
alles auf Freiwilligkeit.

Trotzdem hätte auch ich gedacht, dass alle Änderungen oder Erweiterungen
nach dem Vier-Augen-Prinzip einen Audit durchlaufen, bei dem mindestens ein
weiterer erfahrener Entwickler die Änderungen vor Freigabe überprüft. Das
jemand, egal welchen Vertrauensstatus er genießt, unbemerkt vor den Augen
der anderen Entwickler und Mitwirkenden an einer Backdoor basteln kann,
sollte doch das Sicherheitskonzept in Frage stellen.

Und wer sollte das tun? Die anderen Entwickler und Mitwirkenden?
Die grad froh sind, das jemand Dinge tut, zu denen sie keine
Zeit/Lust/Kompetenz haben?
Und wenn das Sicherheitskonzept in Frage steht, was soll dann passieren?

[Martin Schnitkemper]

Post by Thomas Noll
Und wer sollte das tun? Die anderen Entwickler und Mitwirkenden?

Ja… nur so geht es, wenn man überhaupt einen minimalen Sicherheitsstandard
erreichen möchte. Uneingeschränktes Vertrauen in nur einen einzigen
Entwickler zu setzen ist jedenfalls die schlechteste aller Strategien, wenn
es um Sicherheitsfragen geht.

Post by Thomas Noll
Die grad froh sind, das jemand Dinge tut, zu denen sie keine
Zeit/Lust/Kompetenz haben?

Wer keine Zeit oder keine Lust hat, sollte sich nicht in ein Projekt
einbringen. Und wenn das gesamte Projekte nur aus Leuten besteht, die keine
Zeit und keine Lust haben, sollte man es besser ganz einstellen.

Sonst werden wir nämlich irgendwann vor der Situation stehen, dass sich
Angreifer vorzugsweise in Projekte einnisten von denen bekannt ist, dass
sie von überlasteten und unmotivierten Mitwirkenden betreut werden, um von
dort ungestört ihre Angriffe vorbereiten und ausführen können.

Post by Thomas Noll
Und wenn das Sicherheitskonzept in Frage steht, was soll dann passieren?

Es an die Bedrohungslage anpassen. Wenn man aus dem Vorfall keinerlei
Konsequenzen zieht und alles so weiterlaufen lässt wie bisher, wäre das im
Sinne der Sicherheit wirklich bedauerlich.

Auch wenn es eine hundertprozentige Sicherheit nie geben wird so denke ich
aber schon, dass das jetzt so eine Art Weckruf für die Verantwortlichen
war, damit so etwas nicht noch einmal passiert.

[Thomas Hochstein]

Post by Martin Schnitkemper
Wer keine Zeit oder keine Lust hat, sollte sich nicht in ein Projekt
einbringen. Und wenn das gesamte Projekte nur aus Leuten besteht, die keine
Zeit und keine Lust haben, sollte man es besser ganz einstellen.

Aha.

Post by Martin Schnitkemper
Sonst werden wir nämlich irgendwann vor der Situation stehen, dass sich
Angreifer vorzugsweise in Projekte einnisten von denen bekannt ist, dass
sie von überlasteten und unmotivierten Mitwirkenden betreut werden, um von
dort ungestört ihre Angriffe vorbereiten und ausführen können.

Ja, und? Wer keine Zeit oder Lust hat, den Sourcocode der Software, die er
installiert, zu prüfen, sollte das lassen - oder jemanden dafür bezahlen,
der das tut.

Post by Martin Schnitkemper
Auch wenn es eine hundertprozentige Sicherheit nie geben wird so denke ich
aber schon, dass das jetzt so eine Art Weckruf für die Verantwortlichen
war, damit so etwas nicht noch einmal passiert.

Lieber Himmel.

[Marco Moock]

Post by Martin Schnitkemper
Wer keine Zeit oder keine Lust hat, sollte sich nicht in ein Projekt
einbringen. Und wenn das gesamte Projekte nur aus Leuten besteht, die
keine Zeit und keine Lust haben, sollte man es besser ganz
einstellen.

So manches Projekt entsteht einfach, weil wer mal was baut und es dann
freundlicherweise für andere zur Verfügung stellt. Daraus ergibt sich
dann ggf., dass neue Leute dazukommen, die auch dazu beitragen wollen.
Dazu kommt, dass man aktuell genügend Ressourcen zur Verfügung hat, in
der Zukunft aber mal nicht mehr. Spätestens dann kommen entweder neue
Leute oder die Software wird halt nicht mehr weiterentwickelt.

[Peter J. Holzer]

Post by Martin Schnitkemper

Post by Marco Moock

Post by Peter J. Holzer
Den Upstream-Tarball oder das Git-Repo? Da hatte man das Problem
nicht, denn die Sicherheitslücke wurde nur eincompiliert, wenn man
ein .deb oder .rpm-Paket baut.

Also war der Angriff auf Systeme mit genau diesem Paketformat gedacht.

Da verstehe ich den Zusammenhang nicht, was die Sicherheitslücke mit dem
Paketformat zu tun hat.
Es geht doch um die liblzma, die mit dem xz-Paket ausgeliefert wird,
unabhängig von dessen Format.

Und jemand (entweder einer der Maintainer oder jemand mit dessen
Credentials) hat das Build-Script so manipuliert, dass das Backdoor nur
einkompiliert wird, dass es in einer dpkg- oder rpm-Build-Umgebung
aufgerufen wird (plus ein paar andere Checks, z.B. Zielarchitektur
(x86_64), verwendeter Compiler und Linker). Außerdem war das nur im
Tarball, nicht im Git-Repo.

Die Attacke war also auf bestimmte Distributionen zugeschnitten und so
gestaltet, dass sie auf anderen nicht nur inaktiv sondern auch schwer zu
entdecken ist.

Post by Martin Schnitkemper

Post by Marco Moock
Da ist nur deswegen nicht in stable gekommen, weil das
Performance-Problem bemerkt wurde. Wäre das nicht passiert, hätte
da keiner Zweifel gehabt und es ist einfach zeitlich glücklich gelaufen.

Das sehe ich auch so

Post by Marco Moock
Mein Fazit: Bei manchen Projekten gucken zu wenige Leute die Änderungen
an. Ich mache da aber niemandem einen Vorwurf, denn das basiert halt
alles auf Freiwilligkeit.

Trotzdem hätte auch ich gedacht, dass alle Änderungen oder Erweiterungen
nach dem Vier-Augen-Prinzip einen Audit durchlaufen, bei dem mindestens ein
weiterer erfahrener Entwickler die Änderungen vor Freigabe überprüft.

Bei zwei Maintainern gibt halt genau einen anderen, der das machen kann.
Da sind die Personalresourcen schon recht begrenzt. Und wenn dann - wie
hier - entscheidende Teile des Exploits gar nicht im Repo sind, sondern
erst beim Erstellen des Tarballs eingeschleust werden, wird das
schwierig.

Ja, natürlich wäre das alles vermeidbar gewesen. Aber wieviele
zwei-Personen-Teams gehen davon aus, dass der andere im Team bösartige
Absichten haben könnte?

hp

[Ralph Aichinger]

Post by Peter J. Holzer
Bei zwei Maintainern gibt halt genau einen anderen, der das machen kann.
Da sind die Personalresourcen schon recht begrenzt. Und wenn dann - wie
hier - entscheidende Teile des Exploits gar nicht im Repo sind, sondern
erst beim Erstellen des Tarballs eingeschleust werden, wird das
schwierig.

Theoretisch gäbe es ja noch die Möglichkeit, dass es dem
Debian-Maintainer beim Verpacken aufgefallen wäre, oder auch dass bei
irgendeinem exernen Security-Audit einer Firma die diese Library in
eigene Produkte einbaut (wo das Backdoor abgeschaltet ist, aber in den
Paketsourcen sollte man es trotzdem sehen) was auffällt.

Vermutlich wär es nicht blöd, wenn Sicherheitsteams nach dem
Zufallsprinzip mal "irgendwelche" Software tief unten im Stack
durchsehen. Klar, sowas ist teuer, personalintensiv, und irgendwer muß
es zahlen oder machen.

/ralph

[Peter J. Holzer]

Post by Ralph Aichinger

Post by Peter J. Holzer
Bei zwei Maintainern gibt halt genau einen anderen, der das machen kann.
Da sind die Personalresourcen schon recht begrenzt. Und wenn dann - wie
hier - entscheidende Teile des Exploits gar nicht im Repo sind, sondern
erst beim Erstellen des Tarballs eingeschleust werden, wird das
schwierig.

Theoretisch gäbe es ja noch die Möglichkeit, dass es dem
Debian-Maintainer beim Verpacken aufgefallen wäre, oder auch dass bei
irgendeinem exernen Security-Audit einer Firma die diese Library in
eigene Produkte einbaut (wo das Backdoor abgeschaltet ist, aber in den
Paketsourcen sollte man es trotzdem sehen) was auffällt.

Klar. Aber das sind Externe, so wie Andres Freund ein externer ist.

Mein Vorposter hat aber argumentiert, dass das XZ-Team selbst ein
"Security-Konzept" mit Vier-Augen-Prinzip etc. haben sollte. Und das
halt bei einem Freizeitprojekt mit zwei Maintainern eher unrealistisch.

Funktioniert schon im bezahlten Umfeld oft eher schlecht. Wir haben auch
eine "Code muss reviewt werden, bevor er in den Master gemergt
wird"-Policy, aber die Reviews sind oft eher oberflächlich. Ich bin
nicht besonders zuversichtlich, dass es auffallen würde, wenn einer
meiner Kollegen etwas ähnliches macht.

Post by Ralph Aichinger
Vermutlich wär es nicht blöd, wenn Sicherheitsteams nach dem
Zufallsprinzip mal "irgendwelche" Software tief unten im Stack
durchsehen.

Machen sie ja. Aber es gibt viel Software ...

hp

[Ralph Aichinger]

Post by Peter J. Holzer
Mein Vorposter hat aber argumentiert, dass das XZ-Team selbst ein
"Security-Konzept" mit Vier-Augen-Prinzip etc. haben sollte. Und das
halt bei einem Freizeitprojekt mit zwei Maintainern eher unrealistisch.

Ah, ok, sorry, dann hab ich nicht aufmerksam gelesen. Ja, seh ich auch
so, vor allem war bei den zwei Maintainern nicht einer schon der
eigentliche Übeltäter? Dann wär es noch schwieriger.

Letztendlich kann das keine Einzelperson schaffen, auch zwei nicht.

Post by Peter J. Holzer
Funktioniert schon im bezahlten Umfeld oft eher schlecht. Wir haben auch
eine "Code muss reviewt werden, bevor er in den Master gemergt
wird"-Policy, aber die Reviews sind oft eher oberflächlich. Ich bin
nicht besonders zuversichtlich, dass es auffallen würde, wenn einer
meiner Kollegen etwas ähnliches macht.

Ich bin kein Entwickler, aber wenn ich so im Großraumbüro bei
derartigen Pull-Requests und schnellen Reviews zugehört habe, dann hab
ich oft das Gefühl gekriegt, dass halt jeder seine Pet-Peeves hat, die
er gerne gefixt hätte, aber vieles substanzielleres eher erst bei externen
Reviews aufgefallen ist.

Post by Peter J. Holzer
Machen sie ja. Aber es gibt viel Software ...

Ja, und das vollkommen erschreckende ist ja, dass das in einer völlig
urtümlich in C programmierten Komponente passiert zu sein scheint, nicht z.B. im
node.js-Ökosystem mit oft hunderten Dependencies, die auch in größeren
Projekten niemand versteht oder auditieren kann (schon alleine wegen der
Zahl), da würde mich nicht überraschen, wenn ähnliches noch vielfach
irgendwo schlummert.

/ralph

[Thomas Hochstein]

Post by Ralph Aichinger
Ah, ok, sorry, dann hab ich nicht aufmerksam gelesen. Ja, seh ich auch
so, vor allem war bei den zwei Maintainern nicht einer schon der
eigentliche Übeltäter?

Ja. Derjenige, der wegen der völligen Überlastung des ursprünglichen
Maintainers hinzugestoßen ist.

Post by Ralph Aichinger
Letztendlich kann das keine Einzelperson schaffen, auch zwei nicht.

xz ist jetzt kein Sonderfall; das ist vielmehr - aßer bei riesigen
Projekten - die Regel. Letztere setzen dann aber auf ungezählte
Versatzstücke auf, die von Einzelpersonen oder Mini-Teams entwickelt und
betreut werden.

Im größeren Maßstab ist das nicht anders. Debian hat rund 1.000 Mitglieder
und rund 1.500 Personen, die im letzten Jahr in irgendeiner Weise aktiv
waren, die insgesamt rund 35.000 Pakete betreuen. Das für
Sicherheitsupdates zuständige Team ist recht groß und umfasst 10 Peronen
(die das natürlich auch alle nebenbei in ihrer Freizeit machen).

Post by Ralph Aichinger
Ja, und das vollkommen erschreckende ist ja, dass das in einer völlig
urtümlich in C programmierten Komponente passiert zu sein scheint, nicht z.B. im
node.js-Ökosystem mit oft hunderten Dependencies, die auch in größeren
Projekten niemand versteht oder auditieren kann (schon alleine wegen der
Zahl), da würde mich nicht überraschen, wenn ähnliches noch vielfach
irgendwo schlummert.

Das sowieso. Da kann ja jeder hochladen, was er will - und nicht jeder
prüft, was er in seine Projekte einbindet.
https://www.securityweek.com/lofygang-cybercrime-group-used-200-malicious-npm-packages-supply-chain-attacks/

Dabei geht es noch nicht einmal um Böswilligkeit; nicht jeder Hobbyist hat
professionelle Ansprüche an die Sicherheit seiner Entwicklersysteme, oder
kümmert sich gar um andere potentielle Schwachstellen. Es genügt ja, dass
man keine Zeit mehr hat und sich anderen Bereichen zuwendet (oder
verstirbt ...) - man gibt seine Domain auf, jemand anderes registriert sie
neu, und *schwups*
<https://docs.npmjs.com/threats-and-mitigations#by-registering-an-expired-email-domain>.

Oder jemand kauft bestehende Projekte auf. Welcher Hobbyist freut sich
nicht, wenn jemand anbietet, seine Software für einen vierstelligen Betrag
zu übernehmen?

Oder ...

-thh

[Thomas Hochstein]

Post by Martin Schnitkemper
Trotzdem hätte auch ich gedacht, dass alle Änderungen oder Erweiterungen
nach dem Vier-Augen-Prinzip einen Audit durchlaufen, bei dem mindestens ein
weiterer erfahrener Entwickler die Änderungen vor Freigabe überprüft.

Stell Dir vor, Du entwickelst und pflegst allein (!) hobbymäßig eine
Software. Irgendwann schaffst Du das zeitlich nicht mehr. Du hast Berge
unbeantworteter E-Mail; Bugreports; Patches; Featurewünsche. Du kommst
nicht dazu, das aufzuholen, weil anderes - Dein bezahlter Job, Deine
Familie, die Steuererklärung, ein Hausbau, eine Erkrankung, ... - Vorrang
hat. Es geht nicht voran, jahrelang. Du leidest darunter. Deine Nutzer
beschweren sich. Du überlegst, das Projekt aufzugeben oder Dir Hilfe zu
suchen. Da meldet sich jemand, der anfängt, Bugreports durchzugehen und zu
sichten und Patches zu schicken. Die Arbeit sieht gut aus. Du bekommst
Dein Projekt wieder etwas besser in den Griff. Der Helfer ist bereit,
mitzuwirken. Du räumst ihm entsprechende Rechte ein.

Wenn Du alles, was er tut, kontrollieren könntest, könntest Du die Arbeit
im Zweifel auch selber leisten.

Post by Martin Schnitkemper
Das
jemand, egal welchen Vertrauensstatus er genießt, unbemerkt vor den Augen
der anderen Entwickler und Mitwirkenden an einer Backdoor basteln kann,

Welche "anderen Entwickler und Mitwirkenden"? Im konkreten Fall gibt es
einen anderen Maintainer, der jahrelang überlastet war und deshalb einen
weiteren Maintainer akzeptiert hat.

Post by Martin Schnitkemper
sollte doch das Sicherheitskonzept in Frage stellen.

Welches "Sicherheitskonzept"?

xz wird (wie ungezählte andere Projekte auch) von Einzelpersonen alleine -
oder in kleinen Gruppen - nebenbei in der Freizeit entwickelt und
gepflegt. Da gibt es keine "Sicherheitskonzepte" oder "andere Entwickler
und Mitwirkende".

-thh

[Thomas Hochstein]

Post by Marco Moock
Mein Fazit: Bei manchen Projekten gucken zu wenige Leute die Änderungen
an.

Bei allen.

In diesem konkreten Fall wird der einzige andere Maintainer die Änderungen
im Zweifel gar nicht groß anschauen, denn die fehlende Zeit für den Review
von Patches war ja gerade der Grund für die Aufnahme eines Co-Maintainers.

Und irgendwelches Testmaterial schaut sich sowieso niemand an - und
Tarballs auch nicht. Der Hook für die Ausführung des Schadcodes war ja
vorliegend gerade nicht im Git-Repository eingecheckt und daher dort auch
nicht zu bemerken, sondern nur im Tarball.

-thh

[Ralph Aichinger]

Post by Thomas Hochstein
Und irgendwelches Testmaterial schaut sich sowieso niemand an - und
Tarballs auch nicht. Der Hook für die Ausführung des Schadcodes war ja
vorliegend gerade nicht im Git-Repository eingecheckt und daher dort auch
nicht zu bemerken, sondern nur im Tarball.

Ich könnte mir vorstellen, dass das automatisierte Erstellen der
tarballs aus einer Pipeline in Zukunft bei viel mehr Projekten
vorausgesetzt werden wird. Das löst zwar immer noch nicht das Problem
mit den binären(?) Testdaten, aber zumindest fällt es eher auf, wenn der
Tarball mit dem im git eingecheckten Stand nix zu tun hat.

/ralph

[Marc Haber]

Post by Ralph Aichinger

Post by Thomas Hochstein
Und irgendwelches Testmaterial schaut sich sowieso niemand an - und
Tarballs auch nicht. Der Hook für die Ausführung des Schadcodes war ja
vorliegend gerade nicht im Git-Repository eingecheckt und daher dort auch
nicht zu bemerken, sondern nur im Tarball.

Ich könnte mir vorstellen, dass das automatisierte Erstellen der
tarballs aus einer Pipeline in Zukunft bei viel mehr Projekten
vorausgesetzt werden wird. Das löst zwar immer noch nicht das Problem
mit den binären(?) Testdaten, aber zumindest fällt es eher auf, wenn der
Tarball mit dem im git eingecheckten Stand nix zu tun hat.

Es wäre heute schon möglich den Inhalt des Tarballs mit dem Tag aus
dem VCS zu vergleichen und den Build ggf zu failen.

Grüße
Marc

[Thomas Noll]

Post by Marc Haber
Es wäre heute schon möglich den Inhalt des Tarballs mit dem Tag aus
dem VCS zu vergleichen und den Build ggf zu failen.

Wenn der Tarball keine Abweichung zu einem VCS Stand haben darf, wäre er
dann nicht komplett überflüssig?

[Ralph Aichinger]

Post by Thomas Noll
Wenn der Tarball keine Abweichung zu einem VCS Stand haben darf, wäre er
dann nicht komplett überflüssig?

Manche Downstream-Projekte wollen ein Tarfile, sicher auch als
Gegenprobe ganz praktisch, aber ja, mehr oder weniger überflüssig.

/ralph

[Tim Landscheidt]

Post by Ralph Aichinger

Post by Thomas Noll
Wenn der Tarball keine Abweichung zu einem VCS Stand haben darf, wäre er
dann nicht komplett überflüssig?

Manche Downstream-Projekte wollen ein Tarfile, sicher auch als
Gegenprobe ganz praktisch, aber ja, mehr oder weniger überflüssig.

Einen Nachteil der VCS-Lösung sieht man ja gerade bei xz: Da
knipst GitHub das Repository aus, und man steht erst einmal
in dem Dunkeln. Das ist letztendlich die gleiche Situation
wie bei Wikipedia vs. (Fach-)Büchern: Jeder Leser wirkt mit
minimalem Aufwand an einem verteilten „Backup“ mit (und kann
für dessen Unveränderung bürgen), ein MediaWiki-Klon mit ein
paar Millionen Artikeln ist da eine andere Hausnummer.

Tim

[Ralph Aichinger]

Post by Tim Landscheidt
Einen Nachteil der VCS-Lösung sieht man ja gerade bei xz: Da
knipst GitHub das Repository aus, und man steht erst einmal
in dem Dunkeln. Das ist letztendlich die gleiche Situation

Das git-Repository des eigentlichen Entwicklers scheint weiterhin
erreichbar, ob das ein Mirror von github war oder umgekehrt: Keine
Ahnung, das ist kein untypischer Fall. Vor allem hätte man ja
die getaggten Zwischenstände in den Debian und RedHat Source-Packages
weiterhin und könnte sie untersuchen.

/ralph

[Marc Haber]

Post by Thomas Noll

Post by Marc Haber
Es wäre heute schon möglich den Inhalt des Tarballs mit dem Tag aus
dem VCS zu vergleichen und den Build ggf zu failen.

Wenn der Tarball keine Abweichung zu einem VCS Stand haben darf, wäre er
dann nicht komplett überflüssig?

Die meisten Distributionen basieren darauf. Debian achtet zum Beispiel
darauf dass er sich nicht ändert, und kann auch detached signaturen
verwalten und prüfen.

Ja, das geht mit signierten release tags genauso, aber da müssten wir
halt erst was entwickeln.

Grüße
Marc

[Rupert Haselbeck]

Post by Marco Moock
Testen hilft hier aber nicht zwingend, denn die Backdoor ist nur
aufgefallen, weil die ein Problem verursacht hat. Wäre das nicht
passiert, wäre die sicher auch in den stable-Varianten gelandet.

Es ist allen Tests immanent, dass sie nicht in jedem Fall jedes Problem
aufdecken. Mehr testen kann helfen, muss aber nicht.
Das ist nun aber kein debian- oder sonstwie distributionsspezifisches
Phänomen.
Und das Schönste dabei ist, dass es im vorliegenden Fall allem Genöle
zum Trotz ja auch wirklich funktioniert und sein Ziel erreicht hat

MfG
Rupert

[Thomas Hochstein]

Post by Rupert Haselbeck
Und das Schönste dabei ist, dass es im vorliegenden Fall allem Genöle
zum Trotz ja auch wirklich funktioniert und sein Ziel erreicht hat

Wenn das alles ist.

<https://salsa.debian.org/ftp-team/xz-2024-incident/-/issues/1>
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068024>

[Stefan Reuther]

Post by Marco Moock

Post by Peter J. Holzer

Post by Marco Moock
und Rolling-Release gibt es bei so manchem OS auch.

Wenn man das einsetzt, muss man halt damit rechnen, dass man wenig
getesteten Code bekommt. Dafür aber schneller.

Testen hilft hier aber nicht zwingend, denn die Backdoor ist nur
aufgefallen, weil die ein Problem verursacht hat. Wäre das nicht
passiert, wäre die sicher auch in den stable-Varianten gelandet.

Im Grunde ist das ein Plädoyer für Abhängigkeitsminimierung und
Self-Sandboxing.

Soweit ich die Berichterstattung verstehe, ist der Code von xz doch nur
deswegen mit sshd zusammengekommen, weil sshd gegen libsystemd linkt, um
sd_notify aufzurufen. sd_notify sind so ca. 10 Zeilen Code. Deswegen
muss man nicht gegen dutzende Shared Libraries linken.

Self-Sandboxing wird ausgerechnet beim sshd leider schwierig, weil der
all die bösen Dinge im Normalbetrieb tatsächlich tut (exec für die
Shell, socket+listen für Portforwarding).

Insgeheim warte ich ja darauf, dass nächste Woche der Böhmermann aus dem
Busch gesprungen kommt und sagt "ich war's".


Stefan

[Marco Moock]

Post by Stefan Reuther
Insgeheim warte ich ja darauf, dass nächste Woche der Böhmermann aus
dem Busch gesprungen kommt und sagt "ich war's".

Ich glaube kaum, dass der zu sowas in der Lage wäre.

[Peter J. Holzer]

Post by Stefan Reuther
Im Grunde ist das ein Plädoyer für Abhängigkeitsminimierung und
Self-Sandboxing.
Soweit ich die Berichterstattung verstehe, ist der Code von xz doch nur
deswegen mit sshd zusammengekommen, weil sshd gegen libsystemd linkt, um
sd_notify aufzurufen. sd_notify sind so ca. 10 Zeilen Code. Deswegen
muss man nicht gegen dutzende Shared Libraries linken.

Ack. sshd auf Debian und RHEL linkt gegen 28 Shared Libraries. Für Rocky
Linux wurde das etwas anders gelöst: Dort ist das sd_notify in einen
eigenen Prozess augelagert und nur der zieht die libsystemd samt
Abhängigkeiten mit rein. Ich weiß nicht, ob das die einzige Änderung
war, aber jedenfalls linkt dort sshd "nur" gegen 13 Shared Libraries.
Aber auch Solar Designer (der das für Rocky Linux gemacht hat), meint,
dass es im Nachhinein betrachtet besser gewesen wäre, die paar Zeilen
von sd_notify zu kopieren (oder nachzuimplementieren), bzw. werde er
jetzt prüfen, ob man das überhaupt noch braucht (da gab es offenbar im
letzten halben Jahr Verbesserungen in systemd, die das unnötig machen
könnten).

Post by Stefan Reuther
Self-Sandboxing wird ausgerechnet beim sshd leider schwierig, weil der
all die bösen Dinge im Normalbetrieb tatsächlich tut (exec für die
Shell, socket+listen für Portforwarding).

Ja, aber sshd hat z.B. schon vor langem das Kryptozeugs in einen eigenen
(unprivilegierten) Prozess ausgelagert. Rocky-Linux hat das für
sd_notify gemacht. Da könnte man sicher noch mehr kompartmentalisieren.

hp

[Martin Schnitkemper]

Post by Peter J. Holzer
In aller Deutlichkeit: Der Zweck von Debian Testing ist es, Bugs zu
entdecken und zu beheben, bevor sie in Debian Stable kommen. Das hat
hier funktioniert.

Es geht in Testing vor allem um die Entdeckung und Beseitigung von Bugs
der Paketbetreuer, und der Systemintegration, und nicht um Programmfehler.

Es hat nur deswegen funktioniert, weil ein Sicherheitsforscher die
Sicherheitslücke entdeckt und publik gemacht hat, und nicht die Betreuer
von Debian Testing; sie konnten nur noch auf die Situation reagieren.

Ich bin davon überzeugt, dass der Schadcode genau so auch nach Debian Stable
gekommen wäre, wenn das Problem nicht während des Freeze (von anderen)
entdeckt wird.

Post by Peter J. Holzer
Wenn man das einsetzt, muss man halt damit rechnen, dass man wenig
getesteten Code bekommt. Dafür aber schneller.

Wer sollte das denn testen? Wenn ein Projekt upstream freigegeben wird,
dann wird es auch genau so in die Distribution übernommen. Da kann weder
ein Benutzer noch ein Paketbetreuer etwas testen; dazu sind sie weder
fachlich noch zeitlich in der Lage. Und da macht es auch keinen
Unterschied, ob Rolling Release oder festes Release; was zur deadline
vorliegt, wird auch so in die Distribution übernommen. Es waren ja auch
Fedora und openSUSE davon betroffen, die sich den Schadcode über die ganz
regulären Paketaktualisierungen eingefangen haben.

[Marco Moock]

Post by Martin Schnitkemper
Wer sollte das denn testen? Wenn ein Projekt upstream freigegeben
wird, dann wird es auch genau so in die Distribution übernommen. Da
kann weder ein Benutzer noch ein Paketbetreuer etwas testen; dazu
sind sie weder fachlich noch zeitlich in der Lage.

Das stimmt so nicht ganz. Wenn da z.B. Inkompatibilitäten zwischen
anderen Paketen erst erkannt werden, wird diese Version ggf. doch nicht
ausgeliefert. Auf die Backdoor hat das natürlich keinen Einfluss.

[Martin Schnitkemper]

Post by Marco Moock
Das stimmt so nicht ganz. Wenn da z.B. Inkompatibilitäten zwischen
anderen Paketen erst erkannt werden, wird diese Version ggf. doch nicht
ausgeliefert.

Das ist es aber doch auch, was ich mit "Systemintegration" meinte; sie
können eben nur auf das Einfluss nehmen, was in ihrem Verantwortungsbereich
liegt. Und dazu können keine Programmfehler und auch keine Entdeckung von
Schadsoftware gehören. Was später als Fehlern korrigiert oder an
Sicherheitslücken bekannt und entfernt wird, geht dann eben als
Paketaktualisierung raus, verhindert aber nicht die Aufnahme in eine
"stable"-Distribution.

[Marc Haber]

Post by Martin Schnitkemper
Ich bin davon überzeugt, dass der Schadcode genau so auch nach Debian Stable
gekommen wäre, wenn das Problem nicht während des Freeze (von anderen)
entdeckt wird.

Debian ist aktuell nicht im Freeze.

[Thomas Hochstein]

Post by Marc Haber
Debian ist aktuell nicht im Freeze.

Praktisch ist Debian derzeit tiefer eingefroren als im Freeze. ;)

[Marc Haber]

Post by Thomas Hochstein

Post by Marc Haber
Debian ist aktuell nicht im Freeze.

Praktisch ist Debian derzeit tiefer eingefroren als im Freeze. ;)

Zu einem Freeze gehört aber auch dass Bugs gefixt werden. Aber ja.

Grüße
Marc

[Thomas Hochstein]

Post by Peter J. Holzer
In aller Deutlichkeit: Der Zweck von Debian Testing ist es, Bugs zu
entdecken und zu beheben, bevor sie in Debian Stable kommen. Das hat
hier funktioniert.

Bislang scheint noch niemand sicher (!) zu wissen, was der Schadcode
tatsächlich im einzelnen tut.

Die Befürchtung war, dass eben nicht nur sshd betroffen sein könnte, und
(Debian-)Entwickler arbeiten regelmäßig mit Entwicklungsversionen, hier
konkret testing oder unstable. Das gefährdet potentiell die dort
entwickelte Software und die zur Signatur verwendeten Keys.

Post by Peter J. Holzer
Hat aber nichts damit zu tun, dass Debian Testing hier seine Funktion
erfüllt hat.

Diese Sicherheit scheint man nicht überall zu teilen. Ubuntu scheint einen
teilweisen Rebuild des Archivs mit xz-Versionen vor Februar 2024
angestoßen zu haben, Debian hat alle bisherigen amd64 buildds deaktiviert
und ist dabei, neue Maschinen auszurollen.

-thh

[Marco Moock]

Post by Thomas Hochstein
Bislang scheint noch niemand sicher (!) zu wissen, was der Schadcode
tatsächlich im einzelnen tut.

Gibt es denn dazu irgendwelche Information?

[Thomas Hochstein]

Post by Marco Moock

Post by Thomas Hochstein
Bislang scheint noch niemand sicher (!) zu wissen, was der Schadcode
tatsächlich im einzelnen tut.

Gibt es denn dazu irgendwelche Information?

Nein. In der ursprünglichen Mail gibt es Anhänge mit dem extrahierten
Patchcode <https://www.openwall.com/lists/oss-security/2024/03/29/4>. Es
wurde wohl diskutiert, eine spezialisierte Firma hinzuziehen
<https://lists.debian.org/debian-devel/2024/03/msg00338.html>.

Inzwischen ist aber mindestens eine weitere böswillige Änderung
aufgetaucht
<https://salsa.debian.org/ftp-team/xz-2024-incident/-/issues/5#note_478383>.

Debian hat daher jetzt zunächst einmal alles eingefroren
<https://lists.debian.org/debian-devel-announce/2024/03/msg00004.html> und
prüft, ob und wie man auf eine deutlich ältere Version vor dem Hinzustoßen
des böswilligen Akteurs zurückgehen kann. Das ist nicht ganz einfach, weil
u.a. zentrale Tools wie dpkg von einer aktuellen Version abhängen.

Da offenbar sowohl gesichert kompromottierte Versionen als auch
möglicherweise bedenkliche Versionen auf buildds installiert waren, ist es
nicht völlig ausgeschlossen, dass die dort gebauten Binarys kompromittiert
sind. (Deshalb hat man die amd64 buildds ja bereits komplett
rausgenommen.) Gleichfalls nicht völlig ausschließen können wird man
derzeit - bis man genauer weiß, was der Schadcode tut - eine
Kompromittierung von Entwicklermaschinen.

Es bleibt spannend. :-)

-thh

[Ralph Aichinger]

Post by Marco Moock
Gibt es denn dazu irgendwelche Information?

Tatsächlich scheinen einige Experten noch zu analysieren.
Der Code dürfte auch Gegenmaßnahmen gegen solche Forensik eingebaut
haben, z.B. unter manchen Debuggern sich tot stellen.

/ralph

[Michael Ablassmeier]

Post by Ralph Aichinger

Post by Marco Moock
Gibt es denn dazu irgendwelche Information?

Tatsächlich scheinen einige Experten noch zu analysieren.
Der Code dürfte auch Gegenmaßnahmen gegen solche Forensik eingebaut
haben, z.B. unter manchen Debuggern sich tot stellen.

weitere Erkenntnisse:

https://news.ycombinator.com/item?id=39877267
https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b
https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01

[Martin Ebert]

Post by Marco Moock

Post by Thomas Hochstein
Bislang scheint noch niemand sicher (!) zu wissen, was der Schadcode
tatsächlich im einzelnen tut.

Gibt es denn dazu irgendwelche Information?

Du kennst
<https://lwn.net/ml/oss-security/***@awork3.anarazel.de/> ?

Das Ganze passiert in den Testroutinen. Die sind teilweise
noch nicht völlig verstanden, weil da bei sed und tr mit
Maskierung gespielt wird, die erst durch den konkreten zu
bearbeitenden Content ergänzt wird. Die Payload wird später
an Stelle eines Keys übertragen. Inzwischen ist man so weit,
dass vermutlich nicht nur zwei Formate betroffen sind, es
gibt bereits zuvor eine versteckte Verzweigung. Unklar sind
im Moment noch Objektbibliotheken.

Es gibt zudem eine Diskussion, auf den letzten sauberen
Stand zurückzusetzen - das ist nicht so einfach, da einige
Projekte Symbole neuerer Versionen nutzen.

Was ich da sah respektive verstehe, ist schon erste Liga.
Das wurde zwei Jahre vorbereitet, scheint genial.

Mt

[gunter-kuehne]

Post by Martin Ebert

Post by Marco Moock

Post by Thomas Hochstein
Bislang scheint noch niemand sicher (!) zu wissen, was der Schadcode
tatsächlich im einzelnen tut.

Gibt es denn dazu irgendwelche Information?

Du kennst
Das Ganze passiert in den Testroutinen. Die sind teilweise
noch nicht völlig verstanden, weil da bei sed und tr mit
Maskierung gespielt wird, die erst durch den konkreten zu
bearbeitenden Content ergänzt wird. Die Payload wird später
an Stelle eines Keys übertragen. Inzwischen ist man so weit,
dass vermutlich nicht nur zwei Formate betroffen sind, es
gibt bereits zuvor eine versteckte Verzweigung. Unklar sind
im Moment noch Objektbibliotheken.
Es gibt zudem eine Diskussion, auf den letzten sauberen
Stand zurückzusetzen - das ist nicht so einfach, da einige
Projekte Symbole neuerer Versionen nutzen.
Was ich da sah respektive verstehe, ist schon erste Liga.
Das wurde zwei Jahre vorbereitet, scheint genial.
Mt

Ist aber nur bei sid und wen ich das richtig gelesen haben nur bei en-us
wirksam.
Naja bei meinen Mageia gibt es das so nicht. Anders implementiert.
Dürfte also nicht Funktionieren.

[Ralph Aichinger]

Post by gunter-kuehne
Ist aber nur bei sid und wen ich das richtig gelesen haben nur bei en-us
wirksam.

Nicht nur bei sid, auch bei testing. Und bei der Locale wird glaub ich
nur geprüft ob eine gesetzt ist (um zu unterscheiden können, ob das
ganze über systemd aufgerufen worden ist oder von einer interaktiven
Shell, d.h. potentiell von einem der es analysieren will).

/ralph

[Marc Haber]

Post by Thomas Hochstein
Bislang scheint noch niemand sicher (!) zu wissen, was der Schadcode
tatsächlich im einzelnen tut.
Die Befürchtung war, dass eben nicht nur sshd betroffen sein könnte, und
(Debian-)Entwickler arbeiten regelmäßig mit Entwicklungsversionen, hier
konkret testing oder unstable. Das gefährdet potentiell die dort
entwickelte Software und die zur Signatur verwendeten Keys.

Mich würde insbesondere interessieren, ob ein Connect auf einen mit
tcp-wrapper abgesicherten sshd durch hosts.deny früh genug abgeblockt
wird, dass der Exploit nicht mehr zum Tragen kommen kann.

Dann wären meine "unstables" nämlich allesamt safe ;-)

Nach meinem aktuellen Verständnis wird eine RSA-Funktion umgeleitet,
das macht mir Hoffnung dass die tcp-wrapper an dieser Stelle wirksam
genug sind.

Grüße
Marc

[Thomas Hochstein]

Post by Marc Haber
Nach meinem aktuellen Verständnis wird eine RSA-Funktion umgeleitet,
das macht mir Hoffnung dass die tcp-wrapper an dieser Stelle wirksam
genug sind.

So verstehe ich das.

[Thomas Hochstein]

Post by Marco Moock
Nicht ganz, denn das Teil hat es auf Produktivsysteme geschafft -

Vor allem auf Produktivsysteme von Entwicklern (!).

Post by Marco Moock
Und das zeigt, dass eben in der Praxis in vielen Fällen nicht alles von
vielen unabhängigen Leuten geprüft wird, sondern in manchen Fällen gar
nicht. Erst, wenn es dann zu einem Problem kommt, wird geschaut. Hier
ist es zufällig aufgefallen. Hätte die Backdoor nicht zum
Performance-Problem geführt, wäre die wohl heute noch drin.

So ist es.

[Eberhard W Lisse]

Ich benutze Macs und habe v 5.6.1 auf meinen Laptop gefunden, von
Homebrew installiert. Allerdings wird bei einem 'brew upgrade' auf die
Version 5.4.6 (!) hochgradiert.

Selbiges wird auch auf dem Desktop von 5.4.5 auf 5.4.6 getan, und dort
werden dann alle 27 davon abhängenden Pakete mit hochgradiert.

mfg, el
[...]

Post by Marco Moock

Das Problem wurde während der Testing-Phase entdeckt: Mission>>

accomplished, würde ich sagen.

Post by Marco Moock
Nicht ganz, denn das Teil hat es auf Produktivsysteme geschafft -
manche setzen die Entwicklerversionen ein und Rolling-Release gibt
es bei so manchem OS auch.

[...]

[Tim Landscheidt]

Post by Peter J. Holzer

Post by Marco Moock

Post by Martin Klaiber
Ich muss gestehen, dass ich schockiert bin. Dass diese Person (oder
mehrere, die sich hinter dem Namen Jia Tan verbergen) es geschafft
hat, den Rang eines Maintainers zu erreichen und über mehrere Jahre
Schadcode einbauen konnte, ohne entdeckt zu werden.

Das ist krass, aber wenn ich ehrlich bin, nicht verwunderlich.

ACK. Kein kleines Open-Source-Projekt macht einen Background-Check,
bevor man einen neuen Maintainer akzeptiert. Man schaut sich die
bisherigen Contributions an, und wenn jemand über längere Zeit gute
Arbeit macht, fragt man ihn irgendwann, ob er nicht Co-Maintainer werden
will. (Abgesehen davon ist unklar, wie effektiv ein solcher Check wäre.)
[…]

Snowden wurde ja schon angesprochen, und ein BND-Referats-
leiter bei der Technischen Aufklärung steht gerade in Berlin
vor Gericht, daher: Wohl eher nicht.

Und auch bei xz wäre der Schadcode aufgefallen, wenn jemand
(automatisiert) das Ergebnis von „make dist“ mit dem veröf-
fentlichten Tarball verglichen hätte.

Tim

[Ingolf H.]

...kriminelle Machenschaften, Backdoors, Kontrollsystem

Hallo Martin,

angesichts der momentanen Aufdeckungen über die Kontrollversuche
"gewisser Mächte" in allen Bereichen unseres Lebens (siehe auch das
C-Virus weltweit und seine Folgen bis hin zum knebelnden
WHO-Pandemievertrag) bin ich selbst recht wenig überrascht.
Was Linux im spezifischem betrifft, so bin ich vor wenigen Jahren
aufgrund seiner stetig wachsenden Intransparenz in Ubuntu zu Debian
gewechselt. Allein diese IMHO problematische snap-Architektur wieder los
zu werden war nicht sehr einfach und brachte mich schlussendlich zu
diesem Entschluß. Dass Debian viel sauberer/sicherer ist, glaube ich
übrigens kaum, doch zumindest etwas transparenter im Handling...
Apropos, gab es "einst" nicht sogar noch Reportagen in den
Mainstreammedien, dass alle populären "Sicherheitsarchitekturen",
einschliesslich PGP, von Geheimdienstlern unterwandert wurde, um auch
dort heimliche Backdoors einzubauen?
Erinnert sich daran noch jemand?

Brecht sagte: "Wehret den Anfängen"
Ich sage: (Fast schon) zu spät, 1984 wird gerade "erfolgreich" installiert.

LG
Ingolf (Ingsen) Haeusler

PS: nach sehr langer Pause (ca 20 Jahre) habe ich mich endlich wieder
dem Usenet zugewandt und ich glaube mich von früher an Deinen Namen
erinnern zu können. Martin, Du bist ein alter Hase oder bist Du ein anderer?
;-)

[Jörg Lorenz]

Post by Ingolf H.
...kriminelle Machenschaften, Backdoors, Kontrollsystem
Hallo Martin,
angesichts der momentanen Aufdeckungen über die Kontrollversuche
"gewisser Mächte" in allen Bereichen unseres Lebens (siehe auch das
C-Virus weltweit und seine Folgen bis hin zum knebelnden
WHO-Pandemievertrag) bin ich selbst recht wenig überrascht.

Einfach zur Richtigstellung: Verträge unterschreibt man freiwillig und
kann sie auch wieder kündigen.

"Gewisse Mächte" gehören in das Reich der Verschwörungstheorien. Du
trollst ganz gehörig.

Post by Ingolf H.
Was Linux im spezifischem betrifft, so bin ich vor wenigen Jahren
aufgrund seiner stetig wachsenden Intransparenz in Ubuntu zu Debian
gewechselt. Allein diese IMHO problematische snap-Architektur wieder los
zu werden war nicht sehr einfach und brachte mich schlussendlich zu
diesem Entschluß. Dass Debian viel sauberer/sicherer ist, glaube ich
übrigens kaum, doch zumindest etwas transparenter im Handling...
Apropos, gab es "einst" nicht sogar noch Reportagen in den
Mainstreammedien, dass alle populären "Sicherheitsarchitekturen",
einschliesslich PGP, von Geheimdienstlern unterwandert wurde, um auch
dort heimliche Backdoors einzubauen?
Erinnert sich daran noch jemand?

Du brauchst tendenziell professionelle Hilfe.

Post by Ingolf H.
Brecht sagte: "Wehret den Anfängen"
Ich sage: (Fast schon) zu spät, 1984 wird gerade "erfolgreich" installiert.
LG
Ingolf (Ingsen) Haeusler
PS: nach sehr langer Pause (ca 20 Jahre) habe ich mich endlich wieder
dem Usenet zugewandt und ich glaube mich von früher an Deinen Namen
erinnern zu können. Martin, Du bist ein alter Hase oder bist Du ein anderer?
;-)

Du brauchst wirklich professionelle Hilfe.

[Marco Moock]

Post by Jörg Lorenz

Post by Ingolf H.
...kriminelle Machenschaften, Backdoors, Kontrollsystem
Hallo Martin,
angesichts der momentanen Aufdeckungen über die Kontrollversuche
"gewisser Mächte" in allen Bereichen unseres Lebens (siehe auch das
C-Virus weltweit und seine Folgen bis hin zum knebelnden
WHO-Pandemievertrag) bin ich selbst recht wenig überrascht.

Einfach zur Richtigstellung: Verträge unterschreibt man freiwillig und
kann sie auch wieder kündigen.

Das geht aber nur dann, wenn du die selbst auch abschließt. Wenn das
ein Staat macht, hat dieser Vertrag u.a. Einfluss auf staatliche
Handlungen, denen du dich nicht entziehen kannst.

Post by Jörg Lorenz
"Gewisse Mächte" gehören in das Reich der Verschwörungstheorien. Du
trollst ganz gehörig.

Liegt vielleicht daran, dass du in der Schweiz bist und die immer
souverän und unabhängig sein will. In Deutschland ist das anders.
Selbst wenn da die USA die Telefone der Regierung ausspionieren, wird
dagegen nix unternommen. Es würde mich nicht wundern, wenn da noch mehr
Einfluss seitens der USA hier besteht.

Post by Jörg Lorenz

Post by Ingolf H.
Was Linux im spezifischem betrifft, so bin ich vor wenigen Jahren
aufgrund seiner stetig wachsenden Intransparenz in Ubuntu zu Debian
gewechselt. Allein diese IMHO problematische snap-Architektur
wieder los zu werden war nicht sehr einfach und brachte mich
schlussendlich zu diesem Entschluß. Dass Debian viel
sauberer/sicherer ist, glaube ich übrigens kaum, doch zumindest
etwas transparenter im Handling... Apropos, gab es "einst" nicht
sogar noch Reportagen in den Mainstreammedien, dass alle populären
"Sicherheitsarchitekturen", einschliesslich PGP, von
Geheimdienstlern unterwandert wurde, um auch dort heimliche
Backdoors einzubauen? Erinnert sich daran noch jemand?

Du brauchst tendenziell professionelle Hilfe.

Und warum?
Backdoors für Geheimdienste sind nun wirklich Alltag, gibt genügend
Artikel aus der Fachpresse.
Hier z.B. zu Cisco-Switchen:
https://www.golem.de/news/cisco-spionage-backdoor-in-amerikanischen-switches-geschlossen-1905-141025.html

[Jörg Lorenz]

Post by Marco Moock

Post by Jörg Lorenz

Post by Ingolf H.
...kriminelle Machenschaften, Backdoors, Kontrollsystem
Hallo Martin,
angesichts der momentanen Aufdeckungen über die Kontrollversuche
"gewisser Mächte" in allen Bereichen unseres Lebens (siehe auch das
C-Virus weltweit und seine Folgen bis hin zum knebelnden
WHO-Pandemievertrag) bin ich selbst recht wenig überrascht.

Einfach zur Richtigstellung: Verträge unterschreibt man freiwillig und
kann sie auch wieder kündigen.

Das geht aber nur dann, wenn du die selbst auch abschließt. Wenn das
ein Staat macht, hat dieser Vertrag u.a. Einfluss auf staatliche
Handlungen, denen du dich nicht entziehen kannst.

Dann ist ja klar, was der Bürger zu tun hat.

Post by Marco Moock

Post by Jörg Lorenz
"Gewisse Mächte" gehören in das Reich der Verschwörungstheorien. Du
trollst ganz gehörig.

Liegt vielleicht daran, dass du in der Schweiz bist und die immer
souverän und unabhängig sein will. In Deutschland ist das anders.
Selbst wenn da die USA die Telefone der Regierung ausspionieren, wird
dagegen nix unternommen. Es würde mich nicht wundern, wenn da noch mehr
Einfluss seitens der USA hier besteht.

Man liegt immer so, wie man sich bettet. Mit dem Ende der NATO unter
Trump wird ja dann erneut eine der deutschen inflationären Zeitenwenden
passieren. *SCNR*

Post by Marco Moock

Post by Jörg Lorenz

Post by Ingolf H.
Was Linux im spezifischem betrifft, so bin ich vor wenigen Jahren
aufgrund seiner stetig wachsenden Intransparenz in Ubuntu zu Debian
gewechselt. Allein diese IMHO problematische snap-Architektur
wieder los zu werden war nicht sehr einfach und brachte mich
schlussendlich zu diesem Entschluß. Dass Debian viel
sauberer/sicherer ist, glaube ich übrigens kaum, doch zumindest
etwas transparenter im Handling... Apropos, gab es "einst" nicht
sogar noch Reportagen in den Mainstreammedien, dass alle populären
"Sicherheitsarchitekturen", einschliesslich PGP, von
Geheimdienstlern unterwandert wurde, um auch dort heimliche
Backdoors einzubauen? Erinnert sich daran noch jemand?

Du brauchst tendenziell professionelle Hilfe.

Und warum?
Backdoors für Geheimdienste sind nun wirklich Alltag, gibt genügend
Artikel aus der Fachpresse.
https://www.golem.de/news/cisco-spionage-backdoor-in-amerikanischen-switches-geschlossen-1905-141025.html

Wir reden hier aber von einem FOSS-Projekt.
Aber lassen wir das.

[Marco Moock]

Post by Jörg Lorenz

Post by Marco Moock

Post by Jörg Lorenz

Post by Ingolf H.
...kriminelle Machenschaften, Backdoors, Kontrollsystem
Hallo Martin,
angesichts der momentanen Aufdeckungen über die Kontrollversuche
"gewisser Mächte" in allen Bereichen unseres Lebens (siehe auch
das C-Virus weltweit und seine Folgen bis hin zum knebelnden
WHO-Pandemievertrag) bin ich selbst recht wenig überrascht.

Einfach zur Richtigstellung: Verträge unterschreibt man freiwillig
und kann sie auch wieder kündigen.

Das geht aber nur dann, wenn du die selbst auch abschließt. Wenn das
ein Staat macht, hat dieser Vertrag u.a. Einfluss auf staatliche
Handlungen, denen du dich nicht entziehen kannst.

Dann ist ja klar, was der Bürger zu tun hat.

Ob das aber gut ist, ist eine andere Frage. Es gab und gibt da immer
wieder solche Situationen, in denen ich das mit "nein" beantworte.

Post by Jörg Lorenz

Post by Marco Moock

Post by Jörg Lorenz

Post by Ingolf H.
Was Linux im spezifischem betrifft, so bin ich vor wenigen Jahren
aufgrund seiner stetig wachsenden Intransparenz in Ubuntu zu
Debian gewechselt. Allein diese IMHO problematische
snap-Architektur wieder los zu werden war nicht sehr einfach und
brachte mich schlussendlich zu diesem Entschluß. Dass Debian viel
sauberer/sicherer ist, glaube ich übrigens kaum, doch zumindest
etwas transparenter im Handling... Apropos, gab es "einst" nicht
sogar noch Reportagen in den Mainstreammedien, dass alle populären
"Sicherheitsarchitekturen", einschliesslich PGP, von
Geheimdienstlern unterwandert wurde, um auch dort heimliche
Backdoors einzubauen? Erinnert sich daran noch jemand?

Du brauchst tendenziell professionelle Hilfe.

Und warum?
Backdoors für Geheimdienste sind nun wirklich Alltag, gibt genügend
Artikel aus der Fachpresse.
https://www.golem.de/news/cisco-spionage-backdoor-in-amerikanischen-switches-geschlossen-1905-141025.html

Wir reden hier aber von einem FOSS-Projekt.

Auch da gibt es von staatlicher Seite aus verschiedenen Ecken der Welt
sicher Interesse, Sicherheitsprobleme oder gar Hintertüren zu haben.
Staatliche Überwachung und Manipulation soll auch da möglich, denn
gerade mit FOSS versuchen sich ja einige Leute dieser zu entziehen.

Post by Jörg Lorenz
Aber lassen wir das.

Warum willst du jetzt nicht mehr? Keine Argumente mehr?

[Jörg Lorenz]

Post by Marco Moock

Post by Jörg Lorenz

Post by Marco Moock

Post by Jörg Lorenz

Post by Ingolf H.
...kriminelle Machenschaften, Backdoors, Kontrollsystem
Hallo Martin,
angesichts der momentanen Aufdeckungen über die Kontrollversuche
"gewisser Mächte" in allen Bereichen unseres Lebens (siehe auch
das C-Virus weltweit und seine Folgen bis hin zum knebelnden
WHO-Pandemievertrag) bin ich selbst recht wenig überrascht.

Einfach zur Richtigstellung: Verträge unterschreibt man freiwillig
und kann sie auch wieder kündigen.

Das geht aber nur dann, wenn du die selbst auch abschließt. Wenn das
ein Staat macht, hat dieser Vertrag u.a. Einfluss auf staatliche
Handlungen, denen du dich nicht entziehen kannst.

Dann ist ja klar, was der Bürger zu tun hat.

Ob das aber gut ist, ist eine andere Frage. Es gab und gibt da immer
wieder solche Situationen, in denen ich das mit "nein" beantworte.

Post by Jörg Lorenz

Post by Marco Moock

Post by Jörg Lorenz

Post by Ingolf H.
Was Linux im spezifischem betrifft, so bin ich vor wenigen Jahren
aufgrund seiner stetig wachsenden Intransparenz in Ubuntu zu
Debian gewechselt. Allein diese IMHO problematische
snap-Architektur wieder los zu werden war nicht sehr einfach und
brachte mich schlussendlich zu diesem Entschluß. Dass Debian viel
sauberer/sicherer ist, glaube ich übrigens kaum, doch zumindest
etwas transparenter im Handling... Apropos, gab es "einst" nicht
sogar noch Reportagen in den Mainstreammedien, dass alle populären
"Sicherheitsarchitekturen", einschliesslich PGP, von
Geheimdienstlern unterwandert wurde, um auch dort heimliche
Backdoors einzubauen? Erinnert sich daran noch jemand?

Du brauchst tendenziell professionelle Hilfe.

Und warum?
Backdoors für Geheimdienste sind nun wirklich Alltag, gibt genügend
Artikel aus der Fachpresse.
https://www.golem.de/news/cisco-spionage-backdoor-in-amerikanischen-switches-geschlossen-1905-141025.html

Wir reden hier aber von einem FOSS-Projekt.

Auch da gibt es von staatlicher Seite aus verschiedenen Ecken der Welt
sicher Interesse, Sicherheitsprobleme oder gar Hintertüren zu haben.
Staatliche Überwachung und Manipulation soll auch da möglich, denn
gerade mit FOSS versuchen sich ja einige Leute dieser zu entziehen.

Post by Jörg Lorenz
Aber lassen wir das.

Warum willst du jetzt nicht mehr? Keine Argumente mehr?

Nein. Eher *Du* bist schon gehörig OT und das ganze hat was Esotherisches.

[Marco Moock]

Post by Jörg Lorenz

Post by Marco Moock

Post by Jörg Lorenz

Post by Marco Moock

Post by Jörg Lorenz

Post by Ingolf H.
...kriminelle Machenschaften, Backdoors, Kontrollsystem
Hallo Martin,
angesichts der momentanen Aufdeckungen über die Kontrollversuche
"gewisser Mächte" in allen Bereichen unseres Lebens (siehe auch
das C-Virus weltweit und seine Folgen bis hin zum knebelnden
WHO-Pandemievertrag) bin ich selbst recht wenig überrascht.

Einfach zur Richtigstellung: Verträge unterschreibt man
freiwillig und kann sie auch wieder kündigen.

Das geht aber nur dann, wenn du die selbst auch abschließt. Wenn
das ein Staat macht, hat dieser Vertrag u.a. Einfluss auf
staatliche Handlungen, denen du dich nicht entziehen kannst.

Dann ist ja klar, was der Bürger zu tun hat.

Ob das aber gut ist, ist eine andere Frage. Es gab und gibt da immer
wieder solche Situationen, in denen ich das mit "nein" beantworte.

Post by Jörg Lorenz

Post by Marco Moock

Post by Jörg Lorenz

Post by Ingolf H.
Was Linux im spezifischem betrifft, so bin ich vor wenigen
Jahren aufgrund seiner stetig wachsenden Intransparenz in
Ubuntu zu Debian gewechselt. Allein diese IMHO problematische
snap-Architektur wieder los zu werden war nicht sehr einfach und
brachte mich schlussendlich zu diesem Entschluß. Dass Debian
viel sauberer/sicherer ist, glaube ich übrigens kaum, doch
zumindest etwas transparenter im Handling... Apropos, gab es
"einst" nicht sogar noch Reportagen in den Mainstreammedien,
dass alle populären "Sicherheitsarchitekturen", einschliesslich
PGP, von Geheimdienstlern unterwandert wurde, um auch dort
heimliche Backdoors einzubauen? Erinnert sich daran noch
jemand?

Du brauchst tendenziell professionelle Hilfe.

Und warum?
Backdoors für Geheimdienste sind nun wirklich Alltag, gibt
genügend Artikel aus der Fachpresse.
https://www.golem.de/news/cisco-spionage-backdoor-in-amerikanischen-switches-geschlossen-1905-141025.html

Wir reden hier aber von einem FOSS-Projekt.

Auch da gibt es von staatlicher Seite aus verschiedenen Ecken der
Welt sicher Interesse, Sicherheitsprobleme oder gar Hintertüren zu
haben. Staatliche Überwachung und Manipulation soll auch da
möglich, denn gerade mit FOSS versuchen sich ja einige Leute dieser
zu entziehen.

Post by Jörg Lorenz
Aber lassen wir das.

Warum willst du jetzt nicht mehr? Keine Argumente mehr?

Nein. Eher *Du* bist schon gehörig OT und das ganze hat was
Esotherisches.

Ich weiß ja nicht, in welcher Welt du so unterwegs bist, aber der
Umstand, dass viele Staaten der Welt Interesse daran haben, per
Hintertür in Systeme einzudringen, sollte lange bekannt sein.

[Jörg Lorenz]

Post by Marco Moock

Post by Jörg Lorenz
Nein. Eher *Du* bist schon gehörig OT und das ganze hat was
Esotherisches.

Ich weiß ja nicht, in welcher Welt du so unterwegs bist, aber der
Umstand, dass viele Staaten der Welt Interesse daran haben, per
Hintertür in Systeme einzudringen, sollte lange bekannt sein.

Ich weiss ja nicht, was Du von mir hältst: Aber das weiss ich
tatsächlich. Schaue ich um mich herum, habe ich eher das Gefühl, die
meisten anderen wissen das nicht.

Snowden haben die meisten schon längst wieder vergessen: Inklusive der
zeitengewendeten Bundeswehr, die gleich die Russen zu Besprechungen des
Luftwaffen-Stabes über die Taurus einlädt.

Aber das sind alles keine Linux-Probleme sondern politische und
gesellschaftliche.

[Marco Moock]

Post by Jörg Lorenz

Post by Marco Moock

Post by Jörg Lorenz
Nein. Eher *Du* bist schon gehörig OT und das ganze hat was Esotherisches.

Ich weiß ja nicht, in welcher Welt du so unterwegs bist, aber der
Umstand, dass viele Staaten der Welt Interesse daran haben, per
Hintertür in Systeme einzudringen, sollte lange bekannt sein.

Ich weiss ja nicht, was Du von mir hältst: Aber das weiss ich
tatsächlich. Schaue ich um mich herum, habe ich eher das Gefühl, die
meisten anderen wissen das nicht.
Snowden haben die meisten schon längst wieder vergessen: Inklusive der
zeitengewendeten Bundeswehr, die gleich die Russen zu Besprechungen
des Luftwaffen-Stabes über die Taurus einlädt.
Aber das sind alles keine Linux-Probleme sondern politische und
gesellschaftliche.

Die können aber zu Linux-Problemen werden, wenn die entsprechenden
Geheimdienste sich dort einnisten wollen und das schaffen.

[Rupert Haselbeck]

Post by Marco Moock
Warum willst du jetzt nicht mehr? Keine Argumente mehr?

Lustig. Du warst doch derjenige, der mit dem Verbreiten von
Verschwörungstheorien anfing...

MfG
Rupert

[Marco Moock]

Post by Rupert Haselbeck

Post by Marco Moock
Warum willst du jetzt nicht mehr? Keine Argumente mehr?

Lustig. Du warst doch derjenige, der mit dem Verbreiten von
Verschwörungstheorien anfing...

Diese wären?

[Jörg Lorenz]

Post by Marco Moock

Post by Rupert Haselbeck

Post by Marco Moock
Warum willst du jetzt nicht mehr? Keine Argumente mehr?

Lustig. Du warst doch derjenige, der mit dem Verbreiten von
Verschwörungstheorien anfing...

Diese wären?

Die eigenen Postings lesen reicht völlig.

[Marco Moock]

Post by Jörg Lorenz

Post by Marco Moock

Post by Rupert Haselbeck

Post by Marco Moock
Warum willst du jetzt nicht mehr? Keine Argumente mehr?

Lustig. Du warst doch derjenige, der mit dem Verbreiten von
Verschwörungstheorien anfing...

Diese wären?

Die eigenen Postings lesen reicht völlig.

Du musst mir jetzt noch erklären, was daran Verschwörung sein soll.
Oder denkst du, dass Geheimdienste kein Interesse daran haben, geheimen
Zugang zu Linux-Systemen zu bekommen?

[Marc Haber]

Post by Marco Moock
Du musst mir jetzt noch erklären, was daran Verschwörung sein soll.
Oder denkst du, dass Geheimdienste kein Interesse daran haben, geheimen
Zugang zu Linux-Systemen zu bekommen?

Ihr dürft auch nicht vergessen, dass die aktuell primär betroffene
Zielgruppe dieses Angriffs diejenigen sein dürften, die Debian
unstable einsetzen. Das sind unter anderem auch die Mitglieder des
Debian-Projekts, die kraft ihrer Wassersuppe Code schreiben dürfen,
der mit root-Rechten auf Millionen von Installationen in der ganzen
Welt laufen, bis hin zu militärischen Einrichtungen und den
zukünftigen Mondrovern.

Grüße
Marc

[Marco Moock]

Post by Marc Haber

Post by Marco Moock
Du musst mir jetzt noch erklären, was daran Verschwörung sein soll.
Oder denkst du, dass Geheimdienste kein Interesse daran haben,
geheimen Zugang zu Linux-Systemen zu bekommen?

Ihr dürft auch nicht vergessen, dass die aktuell primär betroffene
Zielgruppe dieses Angriffs diejenigen sein dürften, die Debian
unstable einsetzen. Das sind unter anderem auch die Mitglieder des
Debian-Projekts, die kraft ihrer Wassersuppe Code schreiben dürfen,
der mit root-Rechten auf Millionen von Installationen in der ganzen
Welt laufen, bis hin zu militärischen Einrichtungen und den
zukünftigen Mondrovern.

Zudem ist das jetzt aufgeflogen. Der Code wäre, wenn das
Performanceproblem nicht existiert hätte, höchstwahrscheinlich
niemandem aufgefallen und in die stable-Varianten so ziemlich aller
Linux-Distributionen eingeflossen.

Dazu kommt, dass ich auch auf Produktivsystemen Fedora und Debian Sid
einsetze. Die gelten nun streng genommen als kompromittiert, denn sshd
ist da überall installiert.

[Marc Haber]

Post by Marco Moock
Dazu kommt, dass ich auch auf Produktivsystemen Fedora und Debian Sid
einsetze. Die gelten nun streng genommen als kompromittiert, denn sshd
ist da überall installiert.

Da bist Du allerdings selbst dran schuld und darfst jetzt selbst
auffegen.

Grüße
Marc

[Marco Moock]

Post by Marc Haber

Post by Marco Moock
Dazu kommt, dass ich auch auf Produktivsystemen Fedora und Debian Sid
einsetze. Die gelten nun streng genommen als kompromittiert, denn
sshd ist da überall installiert.

Da bist Du allerdings selbst dran schuld und darfst jetzt selbst
auffegen.

Das ist richtig. Wäre das aber nicht aufgefallen, weil die backdoor
flott gewesen wäre, würde der Satz vielleicht auch in Zukunft für
Debian stable, Ubuntu LTS und RHEL gelten. ]:-)

[Marc Haber]

Post by Marco Moock

Post by Marc Haber

Post by Marco Moock
Dazu kommt, dass ich auch auf Produktivsystemen Fedora und Debian Sid
einsetze. Die gelten nun streng genommen als kompromittiert, denn
sshd ist da überall installiert.

Da bist Du allerdings selbst dran schuld und darfst jetzt selbst
auffegen.

Das ist richtig. Wäre das aber nicht aufgefallen, weil die backdoor
flott gewesen wäre, würde der Satz vielleicht auch in Zukunft für
Debian stable, Ubuntu LTS und RHEL gelten. ]:-)

Das ist richtig.

Aber es würde mich überraschen wenn wir nicht schon längst solche
Backdoors in unseren Systemen hätten.

Grüße
Marc

[Ingolf H.]

Post by Jörg Lorenz
Du brauchst wirklich professionelle Hilfe.

Komisch, dass e immer wieder Leute gibt, die Verschwörungstheorien, die
sich bereits und inzwischen schon nach relativ kurzer Zeit in der Praxis
etabliert haben, beflissentlich ignoriert werden.
Allenthalben, als Systemanalytiker muss man einfach zu dem Schluss
kommen, dass die systematischen Vorzeichen ,wie "Geld regiert die Welt"
und ff. zu solchen soziopolitischen Verwerfungen führen müssen, erst
recht, wenn sich Politiker Immunität verschaffen. Jede Verweigerung der
analytischen Betrachtung der Randbedingungen unseres westlichen Systems
betrachte ich eher als kindliche Naivität. Somit biete ich eher meine
Hilfe an.
Offene und schrankenfreie Diskussion als Trolling zu bezeichnen gehören
übrigens in das Reich absolutistischer Gesellschaftssysteme.
soweit e.o.d.

[Martin Schnitkemper]

Post by Ingolf H.
Komisch, dass e immer wieder Leute gibt, die Verschwörungstheorien, die
sich bereits und inzwischen schon nach relativ kurzer Zeit in der Praxis
etabliert haben, beflissentlich ignoriert werden.

Weil es eben Theorien sind, die sich vielleicht etabliert haben, aber
dennoch Theorien bleiben, da die aufgestellten Thesen in der Regel nicht
seriös zu belegen sind, sonst wären es keine Theorien sondern Fakten.

[Jörg Lorenz]

Post by Ingolf H.

Post by Jörg Lorenz
Du brauchst wirklich professionelle Hilfe.

Komisch, dass e immer wieder Leute gibt, die Verschwörungstheorien, die
sich bereits und inzwischen schon nach relativ kurzer Zeit in der Praxis
etabliert haben, beflissentlich ignoriert werden.
Allenthalben, als Systemanalytiker muss man einfach zu dem Schluss
kommen, dass die systematischen Vorzeichen ,wie "Geld regiert die Welt"
und ff. zu solchen soziopolitischen Verwerfungen führen müssen, erst
recht, wenn sich Politiker Immunität verschaffen. Jede Verweigerung der
analytischen Betrachtung der Randbedingungen unseres westlichen Systems
betrachte ich eher als kindliche Naivität. Somit biete ich eher meine
Hilfe an.
Offene und schrankenfreie Diskussion als Trolling zu bezeichnen gehören
übrigens in das Reich absolutistischer Gesellschaftssysteme.

QED: Du hast einen an der Waffel.

Post by Ingolf H.
soweit e.o.d.

Hoffentlich.

[Marco Moock]

Post by Jörg Lorenz

Post by Ingolf H.

Post by Jörg Lorenz
Du brauchst wirklich professionelle Hilfe.

Komisch, dass e immer wieder Leute gibt, die Verschwörungstheorien,
die sich bereits und inzwischen schon nach relativ kurzer Zeit in
der Praxis etabliert haben, beflissentlich ignoriert werden.
Allenthalben, als Systemanalytiker muss man einfach zu dem Schluss
kommen, dass die systematischen Vorzeichen ,wie "Geld regiert die
Welt" und ff. zu solchen soziopolitischen Verwerfungen führen
müssen, erst recht, wenn sich Politiker Immunität verschaffen. Jede
Verweigerung der analytischen Betrachtung der Randbedingungen
unseres westlichen Systems betrachte ich eher als kindliche
Naivität. Somit biete ich eher meine Hilfe an.
Offene und schrankenfreie Diskussion als Trolling zu bezeichnen
gehören übrigens in das Reich absolutistischer
Gesellschaftssysteme.

QED: Du hast einen an der Waffel.

Mit Beleidigungen machst du dich nur lächerlich.

[Jörg Lorenz]

Post by Marco Moock

Post by Jörg Lorenz

Post by Ingolf H.

Post by Jörg Lorenz
Du brauchst wirklich professionelle Hilfe.

Komisch, dass e immer wieder Leute gibt, die Verschwörungstheorien,
die sich bereits und inzwischen schon nach relativ kurzer Zeit in
der Praxis etabliert haben, beflissentlich ignoriert werden.
Allenthalben, als Systemanalytiker muss man einfach zu dem Schluss
kommen, dass die systematischen Vorzeichen ,wie "Geld regiert die
Welt" und ff. zu solchen soziopolitischen Verwerfungen führen
müssen, erst recht, wenn sich Politiker Immunität verschaffen. Jede
Verweigerung der analytischen Betrachtung der Randbedingungen
unseres westlichen Systems betrachte ich eher als kindliche
Naivität. Somit biete ich eher meine Hilfe an.
Offene und schrankenfreie Diskussion als Trolling zu bezeichnen
gehören übrigens in das Reich absolutistischer
Gesellschaftssysteme.

QED: Du hast einen an der Waffel.

Mit Beleidigungen machst du dich nur lächerlich.

Aha. Kannst Du so bewerten, wenn Du willst.

"Absolutistische Gesesllschatssysteme" und "Verweigerung der
analytischen Betrachtung der Randbedingungen unseres westlichen Systems
betrachte ich eher als kindliche Naivität" sind hier *absolut OT* und
ich denke nicht mal im Traum daran, in dieser Gruppe darüber zu
diskutieren. Solche Trollpostings sind eine Beleidigung und verschwenden
die Zeit der User hier.

FUP2 de.alt.gruppenkasper

[Rupert Haselbeck]

Post by Ingolf H.
angesichts der momentanen Aufdeckungen über die Kontrollversuche
"gewisser Mächte" in allen Bereichen unseres Lebens (siehe auch das
C-Virus weltweit und seine Folgen bis hin zum knebelnden
WHO-Pandemievertrag) bin ich selbst recht wenig überrascht.

Welch Unfug. Es handelt sich nicht um "Aufdeckungen", es handelt sich um
Verschwörungstheorien...

Post by Ingolf H.
Was Linux im spezifischem betrifft, so bin ich vor wenigen Jahren
aufgrund seiner stetig wachsenden Intransparenz in Ubuntu zu Debian
gewechselt.

Ist Ubuntu denn neuerdings nicht mehr Debian?

Post by Ingolf H.
Allein diese IMHO problematische snap-Architektur wieder los
zu werden war nicht sehr einfach und brachte mich schlussendlich zu
diesem Entschluß. Dass Debian viel sauberer/sicherer ist, glaube ich
übrigens kaum, doch zumindest etwas transparenter im Handling...
Apropos, gab es "einst" nicht sogar noch Reportagen in den
Mainstreammedien, dass alle populären "Sicherheitsarchitekturen",
einschliesslich PGP, von Geheimdienstlern unterwandert wurde, um auch
dort heimliche Backdoors einzubauen?
Erinnert sich daran noch jemand?

Nein, daran wird sich wohl kaum jemand erinnern können - außerhalb der
Kreise mancher Verschwörungstheoretiker jedenfalls. Aber dort glaubt man
ja z.B. auch, dass Snowden tatsächlich Reales "aufgedeckt" hätte, ohne
auch nur einen Gedanken daran zu verschwenden, warum jener wohl nach
Moskau "geflohen" ist und dann wieder seinen russischen Pass aus dem
Tresor geholt hat :->

Post by Ingolf H.
Brecht sagte: "Wehret den Anfängen"
Ich sage: (Fast schon) zu spät, 1984 wird gerade "erfolgreich" installiert.

Vielleicht solltest du einfach besseren Stoff verwenden

MfG
Rupert

[Marco Moock]

Post by Rupert Haselbeck

Post by Ingolf H.
Was Linux im spezifischem betrifft, so bin ich vor wenigen Jahren
aufgrund seiner stetig wachsenden Intransparenz in Ubuntu zu Debian
gewechselt.

Ist Ubuntu denn neuerdings nicht mehr Debian?

Das war es nie, es basiert nur darauf und übernimmt einen Großteil der
Pakete aus Debian testing. Sonst gibt es da aber so einige
Unterschiede, u.a. das Paketformat snap, was dort standardmäßig aktiv
ist.

Post by Rupert Haselbeck

Post by Ingolf H.
Allein diese IMHO problematische snap-Architektur wieder los
zu werden war nicht sehr einfach und brachte mich schlussendlich zu
diesem Entschluß. Dass Debian viel sauberer/sicherer ist, glaube
ich übrigens kaum, doch zumindest etwas transparenter im Handling...
Apropos, gab es "einst" nicht sogar noch Reportagen in den
Mainstreammedien, dass alle populären "Sicherheitsarchitekturen",
einschliesslich PGP, von Geheimdienstlern unterwandert wurde, um
auch dort heimliche Backdoors einzubauen?
Erinnert sich daran noch jemand?

Nein, daran wird sich wohl kaum jemand erinnern können - außerhalb
der Kreise mancher Verschwörungstheoretiker jedenfalls. Aber dort
glaubt man ja z.B. auch, dass Snowden tatsächlich Reales "aufgedeckt"
hätte, ohne auch nur einen Gedanken daran zu verschwenden, warum
jener wohl nach Moskau "geflohen" ist und dann wieder seinen
russischen Pass aus dem Tresor geholt hat :->

Wenn das alles gelogen sei, warum wurde das dann vor 10 Jahren in der
Presse nicht so kommuniziert?
Wer verarscht jetzt wen?

Post by Rupert Haselbeck

Post by Ingolf H.
Brecht sagte: "Wehret den Anfängen"
Ich sage: (Fast schon) zu spät, 1984 wird gerade "erfolgreich" installiert.

Vielleicht solltest du einfach besseren Stoff verwenden

Vielleicht solltest du gar keinen mehr nehmen und dich an Fakten
orientieren.

[Marco Moock]

Post by Ingolf H.
...kriminelle Machenschaften, Backdoors, Kontrollsystem
Was Linux im spezifischem betrifft, so bin ich vor wenigen Jahren
aufgrund seiner stetig wachsenden Intransparenz in Ubuntu zu Debian
gewechselt. Allein diese IMHO problematische snap-Architektur wieder
los zu werden war nicht sehr einfach und brachte mich schlussendlich
zu diesem Entschluß. Dass Debian viel sauberer/sicherer ist, glaube
ich übrigens kaum, doch zumindest etwas transparenter im Handling...
Apropos, gab es "einst" nicht sogar noch Reportagen in den
Mainstreammedien, dass alle populären "Sicherheitsarchitekturen",
einschliesslich PGP, von Geheimdienstlern unterwandert wurde, um auch
dort heimliche Backdoors einzubauen?

Wäre natürlich möglich und lässt sich nur prüfen, indem man den Code
incl. eingebundener Bibliotheken und Compiler analysiert und dann
kompiliert und mit dem vergleicht, was die Distributionen so
ausliefern.

Post by Ingolf H.
Erinnert sich daran noch jemand?

Ich habe davon noch nicht gehört, kann aber vor meiner Zeit gewesen
sein. Die Crypto-Wars von Joe Biden und anderen Leuten waren vor meiner
Zeit. Hadmut Danisch hat da einiges zu gebloggt, wer sich dafür
interessiert.

Post by Ingolf H.
Brecht sagte: "Wehret den Anfängen"
Ich sage: (Fast schon) zu spät, 1984 wird gerade "erfolgreich" installiert.

Leider ja - die meisten Leute machen noch freiwillig mit.

[Hergen Lehmann]

Post by Marco Moock

Post by Ingolf H.
Mainstreammedien, dass alle populären "Sicherheitsarchitekturen",
einschliesslich PGP, von Geheimdienstlern unterwandert wurde, um auch
dort heimliche Backdoors einzubauen?

Wäre natürlich möglich und lässt sich nur prüfen, indem man den Code
incl. eingebundener Bibliotheken und Compiler analysiert und dann
kompiliert und mit dem vergleicht, was die Distributionen so
ausliefern.

Das genügt nicht.
Einer der bekanntesten Fälle einer Geheimdienst-Backdoor war ein
mutmaßlich(*) kompromittierter Zufallsgenerator-Algorithmus
("Dual_EC_DRBG"), welcher seinen Weg in amtliche Standards gefunden
hatte, und von dort in den Quellcode zahlreiche Produkte.

Da kannst du noch so sorgfältig deinen Code analysieren...


(*) Wirklich bewiesen wurde die Backdoor meines Wissens bis heute nicht,
der Snowden-Leak lieferte lediglich den Beleg, das die US-Geheimdienste
sich auffällig stark für diesen Algorithmus engagiert haben.

[Andreas M. Kirchwitz]

Post by Martin Klaiber
Ich muss gestehen, dass ich schockiert bin. Dass diese Person (oder
mehrere, die sich hinter dem Namen Jia Tan verbergen) es geschafft
hat, den Rang eines Maintainers zu erreichen und über mehrere Jahre
Schadcode einbauen konnte, ohne entdeckt zu werden.

Einerseits ist man aufgewühlt, wenn tatsächliche Angriffe entdeckt
werden, andererseits macht es (immer wieder erneut) deutlich, dass
sämtliche IT ständig Angriffen ausgesetzt ist, auch Open Source.

Post by Martin Klaiber
Nun frage ich mich, ob ob in Linux vielleicht schon etliche Backdoors
existieren, ohne dass man davon weiß.

1 hat man aufgedeckt, 99 weitere schlummern unerkannt vor sich hin.

Post by Martin Klaiber
Alles ziemlich krass, finde ich. Und ich frage mich, ob wir in der
Opensource-Community vielleicht zu blauäugig sind und zu sehr davon
ausgehen, dass alle Beteiligten die uneigennützigen Ziele teilen?

Das ist doch völlig normal, dass man seine Leute irgendwo
einschmuggelt, dass man Daten abgreift oder Code einbringt.
Alltagsgeschäft in Geheimdiensten, Firmen, Politik und
überhaupt überall im Leben.

Open Source ist in der Vergangenheit auch schon oft genug
manipuliert worden mit Backdoors etc. Das ist nichts Neues.

Open Source sagt überhaupt nichts aus. Es muss halt auch
mal ein anderer diesen Code tatsächlich anschauen. Sonst
ist es fast das gleiche wie Closed Source.

Open Source lebt halt sozusagen vom Schwarm. Irgendwem wird
es früher oder später auffallen, wenn etwas merkwürdig ist.

Heutzutage könnte man das sinnvoll eine AI machen lassen,
die können ja bereits Code "lesen" und "schreiben", viele
junge Programmierer verwenden AI maßgeblich dafür. (Was dann
die neue Frage aufwirft, wie weit man der AI vertrauen kann.)

Post by Martin Klaiber
Oder habt ihr mit so etwas gerechnet und bin nur ich zu blauäugig
gewesen? Ich muss gestehen, mit so viel krimineller Energie hatte
ich nicht gerechnet.

IBM / Red Hat / Fedora wollen möglichst viel Software auf Flatpak
umstellen, Ubuntu hat bereits Kern-Komponenten in Snap ausgelagert.
Das ist im Grunde Closed Source durch die Hintertür. Kriminelle
und Geheimdienste freuen sich über so viel Dummheit.

Mal schauen, wann auch Debian kippt.

Die meisten Distributionen, die diesen Weg gehen, fremden Code
ungeprüft (unprüfbar) einfach an die Nutzer durchzureichen, haben
offenbar nicht realisiert, dass sie sich damit selbst abschaffen.
Wer braucht dann noch verschiedene Distributionen? Wozu ist eine
Distribution dann überhaupt noch gut, wenn nicht auch dazu, eine
weitere Instanz zu sein, die einen Blick auf den Code wirft und
Probleme dort erkennt?

Grüße, Andreas

[Marco Moock]

Post by Andreas M. Kirchwitz
Open Source ist in der Vergangenheit auch schon oft genug
manipuliert worden mit Backdoors etc. Das ist nichts Neues.

Welche Beispiele sind dir da bekannt?

Post by Andreas M. Kirchwitz
Open Source sagt überhaupt nichts aus. Es muss halt auch
mal ein anderer diesen Code tatsächlich anschauen. Sonst
ist es fast das gleiche wie Closed Source.
Open Source lebt halt sozusagen vom Schwarm. Irgendwem wird
es früher oder später auffallen, wenn etwas merkwürdig ist.

Da gilt dann auch Team: Toll, ein anderer macht´s.

Post by Andreas M. Kirchwitz
Heutzutage könnte man das sinnvoll eine AI machen lassen,
die können ja bereits Code "lesen" und "schreiben", viele
junge Programmierer verwenden AI maßgeblich dafür. (Was dann
die neue Frage aufwirft, wie weit man der AI vertrauen kann.)

Wenn die manipuliert ist oder auch nur mit Bullshit gefüttert wird, ist
auch da Ende Gelände.

Post by Andreas M. Kirchwitz

Post by Martin Klaiber
Oder habt ihr mit so etwas gerechnet und bin nur ich zu blauäugig
gewesen? Ich muss gestehen, mit so viel krimineller Energie hatte
ich nicht gerechnet.

IBM / Red Hat / Fedora wollen möglichst viel Software auf Flatpak
umstellen, Ubuntu hat bereits Kern-Komponenten in Snap ausgelagert.
Das ist im Grunde Closed Source durch die Hintertür. Kriminelle
und Geheimdienste freuen sich über so viel Dummheit.

Es ist vor allem ein Dschungel an Versionen und an beteiligten Leuten.
Das zu prüfen ist um Faktoren aufwändiger als bei der deb/rpm-Variante,
bei der eine Bibliothek im System halt einmal vorhanden ist.

Wie ist der Stand da bei Fedora? Springen die auch auf den Zug auf oder
kommt das eher aus der RHEL/IBM-Ecke?

Post by Andreas M. Kirchwitz
Mal schauen, wann auch Debian kippt.

Und wann Slackware oder gar xBSD.

Post by Andreas M. Kirchwitz
Die meisten Distributionen, die diesen Weg gehen, fremden Code
ungeprüft (unprüfbar) einfach an die Nutzer durchzureichen, haben
offenbar nicht realisiert, dass sie sich damit selbst abschaffen.

Welche Distribution macht das denn nicht?
Die Manpower gibt es da halt nicht.

Post by Andreas M. Kirchwitz
Wer braucht dann noch verschiedene Distributionen? Wozu ist eine
Distribution dann überhaupt noch gut, wenn nicht auch dazu, eine
weitere Instanz zu sein, die einen Blick auf den Code wirft und
Probleme dort erkennt?

Irgendwer muss die Teile zu einem OS zusammenbauen. Linux from Scratch
existiert und ist für die Praxis eine Schrottlösung.

Dazu kommt, dass die Distributionen sich halt in Sachen Paketen und
Konzepten stark unterscheiden.

[Thomas Hochstein]

Post by Andreas M. Kirchwitz
Mal schauen, wann auch Debian kippt.
Die meisten Distributionen, die diesen Weg gehen, fremden Code
ungeprüft (unprüfbar) einfach an die Nutzer durchzureichen, haben
offenbar nicht realisiert, dass sie sich damit selbst abschaffen.

Das macht Debian doch nicht anders. Der Prozentsatz an Maintainern, der
Upstream-Code tatsächlich prüfen kann und dann auch im einzelnen prüft,
dürfte gegen null gehen.

Post by Andreas M. Kirchwitz
Wer braucht dann noch verschiedene Distributionen? Wozu ist eine
Distribution dann überhaupt noch gut, wenn nicht auch dazu, eine
weitere Instanz zu sein, die einen Blick auf den Code wirft und
Probleme dort erkennt?

Das ist nicht die Aufgabe einer Distribution. (Binäre) Distributionen gibt
es deshalb, damit man die Software nicht selbst kompilieren muss, die dort
enthaltene Software zueinander passt (shared libraries) und um eine
einheitliche Konfiguration und Standards (bspw. im Filesystem)
durchzusetzen und während eines definierten Zeitraums für
Sicherheitsupdates zu sorgen, weil man eben nicht einfach "die neueste
Version" nehmen kann.

Dass jemand einen Blick auf den Code wirft und dabei Probleme erkennt, ist
dabei Zufall.

-thh

[Andreas M. Kirchwitz]

Post by Thomas Hochstein

[Flatpak, Snap etc.]
Mal schauen, wann auch Debian kippt.
Die meisten Distributionen, die diesen Weg gehen, fremden Code
ungeprüft (unprüfbar) einfach an die Nutzer durchzureichen, haben
offenbar nicht realisiert, dass sie sich damit selbst abschaffen.

Das macht Debian doch nicht anders. Der Prozentsatz an Maintainern, der
Upstream-Code tatsächlich prüfen kann und dann auch im einzelnen prüft,
dürfte gegen null gehen.

Egal ob Debian, Fedora und andere - dort wird sehr viel in den Code
reingeschaut und abgeändert, um die Software zu erweitern, Bugs zu
beheben oder das Verhalten der Software anzupassen an Besonderheiten
der jeweiligen Distribution.

Die Zahl der distributionseigenen Patches ist teilweise riesig.
Nicht immer zum Vorteil, die bauen auch Bugs ein, die ärgerlich
sind, weil man sie ja nicht im offiziellen Source Code findet,
sondern die man sich aus den Distributions-Quellen holen muss.

Ziel ist bei all dem natürlich nicht, bösen Code zu finden, aber
es ist ein Nebeneffekt, der sich automatisch ergibt, wenn man so
viel mit dem Source Code hantiert. Es ist de facto eine Kontroll-
instanz, die Angreifer zu überwinden haben. Sonst wäre es viel
einfacher, bösen Code in Open Source reinzuschmuggeln.

Natürlich ist das kritisch betrachtet auch ein weiteres Einfallstor.

Die Original-Programmierer mögen sich noch so viel Mühe geben mit
Kontrollen, Audits, Checks usw. Ein einzelner Maintainer einer
Distribution kann dort (unfreiwillig) Backdoors einbauen in Code,
der ursprünglich unangreifbar gewesen sein könnte.

Auch das ist ja bereits passiert.

Post by Thomas Hochstein

Wer braucht dann noch verschiedene Distributionen? Wozu ist eine
Distribution dann überhaupt noch gut, wenn nicht auch dazu, eine
weitere Instanz zu sein, die einen Blick auf den Code wirft und
Probleme dort erkennt?

Das ist nicht die Aufgabe einer Distribution.

Das ist nicht primäre Aufgabe einer Distribution, aber ein quasi
unvermeidlicher (positiver) Nebeneffekt, wenn die Distribution
etwas taugt und nicht bloß Original-Sources durchreicht. Dann
bräuchte der Anwender nämlich keine Distribution, sondern kann
sich auch alles selbst compilieren. Gibt's ja sogar auch.

Post by Thomas Hochstein
(Binäre) Distributionen gibt
es deshalb, damit man die Software nicht selbst kompilieren muss, die dort
enthaltene Software zueinander passt (shared libraries) und um eine
einheitliche Konfiguration und Standards (bspw. im Filesystem)
durchzusetzen und während eines definierten Zeitraums für
Sicherheitsupdates zu sorgen, weil man eben nicht einfach "die neueste
Version" nehmen kann.

Eben, und ich compiliere sehr viel selbst und passe manchmal
Source Code an meine Bedürfnisse an, und ohne es selbst zu wollen,
bin ich damit eine weitere Instanz, der Merkwürdigkeiten auffallen
würden - zumindest an den Stellen, an denen ich was verändert habe.

Für einen Angreifer ist das umgekehrt die primäre Herausforderung,
bösen Code an all diesen Augen vorbeizuschmuggeln. Und wenn ich mir
die hohen Anzahl von Patches engagierter Distributionen wie Debian
oder Fedora/RedHat ansehe, dann ist das Einschleusen von Schadecode
für Angreifer ziemlich aufwendig und daher bislang vergleichsweise
unattraktiv. Glück für uns alle.

Post by Thomas Hochstein
Dass jemand einen Blick auf den Code wirft und dabei Probleme erkennt, ist
dabei Zufall.

Natürlich ist das Zufall. Für einen Angreifer spielt das aber keine
Rolle, zu welchem Zweck jemand anderes den Source Code anschaut.
Für einen Angreifer ist jede Instanz lästig, die überhaupt in den
Source Code schaut. Je weniger reinschauen, desto bessere Chancen
hat der Angreifer, unter dem Radar zu bleiben.

Wie gesagt, ich sehe hier ein sinnvolles Einsatzgebiet für AI,
die heute ja schon zum Programmieren verwendet wird. Mit reiner
Menschenkraft ist das Problem jedenfalls nicht zu lösen.

Grüße, Andreas

[Thomas Hochstein]

Post by Andreas M. Kirchwitz

Post by Thomas Hochstein
Das macht Debian doch nicht anders. Der Prozentsatz an Maintainern, der
Upstream-Code tatsächlich prüfen kann und dann auch im einzelnen prüft,
dürfte gegen null gehen.

Egal ob Debian, Fedora und andere - dort wird sehr viel in den Code
reingeschaut und abgeändert, um die Software zu erweitern, Bugs zu
beheben oder das Verhalten der Software anzupassen an Besonderheiten
der jeweiligen Distribution.

"Zu erweitern" glaube ich eher nicht, aber ja, das passiert schon. Wenn
dabei eine böswillige Änderung auffällt, ist das aber eher Zufall.
Üblicherweise sollten neue Versionen bereits paketierter Software
unproblematisch übernommen werden können.

Post by Andreas M. Kirchwitz
Die Zahl der distributionseigenen Patches ist teilweise riesig.

Wobei jedenfalls bei Debian das Ziel ist, diese nach Möglichkeit zu
minimieren, indem man sie entweder upstreamt oder nicht zwingend
erforderliche Divergenzen zum Upstream zu vermeiden sucht.

Post by Andreas M. Kirchwitz
Ziel ist bei all dem natürlich nicht, bösen Code zu finden, aber
es ist ein Nebeneffekt, der sich automatisch ergibt, wenn man so
viel mit dem Source Code hantiert. Es ist de facto eine Kontroll-
instanz, die Angreifer zu überwinden haben. Sonst wäre es viel
einfacher, bösen Code in Open Source reinzuschmuggeln.

Ich zweifele. Um Software für Debian zu paketieren, muss man oft außer
Dateipfaden und Abhängigkeiten nicht viel rummachen - und wenn sie einmal
paketiert ist, sollten Updates, die keine massiven, inkompatiblen
Änderungen enthalten, eigentlich Selbstläufer sein.

Dazu kommt dann als nächstes Problem, dass auch Debian nicht genügend
Freiwillige hat. Die Kernteams sind immer schon chronisch unterbesetzt und
überlastet, und die Maintainer einzelner Pakete, nun ja ... sagen wir mal
so: im konkreten Fall von xz-utils [1] hat der Maintainer seinen letzten
regelmäßigen Upload im November 2012 (!) [2] vorgenommen. Danach gab es
ein paar verstreute NMUs (vier bis 2017), im Januar 2019 dann nochmal
einen Upload des Maintainers [3] , aber seitdem hat faktisch jemand
anderes das Paket betreut, der sich gerade jetzt aktuell entschlossen
hatte, es auch als Maintainer zu übernehmen [4].

Ist eben alles nicht so einfach.

(Nicht dass es im Usenet wesentlich anders aussähe.)

-thh

[1] <https://tracker.debian.org/pkg/xz-utils/news/>
[2]
<https://tracker.debian.org/news/537090/accepted-xz-utils-511alpha20120614-2-source-amd64-all/>
[3]
<https://tracker.debian.org/news/1025067/accepted-xz-utils-524-1-source-amd64-all-into-unstable/>
[4]
<https://tracker.debian.org/news/1515323/accepted-xz-utils-561-1-source-into-unstable/>

[Marc Haber]

Post by Andreas M. Kirchwitz

Post by Thomas Hochstein

[Flatpak, Snap etc.]
Mal schauen, wann auch Debian kippt.
Die meisten Distributionen, die diesen Weg gehen, fremden Code
ungeprüft (unprüfbar) einfach an die Nutzer durchzureichen, haben
offenbar nicht realisiert, dass sie sich damit selbst abschaffen.

Das macht Debian doch nicht anders. Der Prozentsatz an Maintainern, der
Upstream-Code tatsächlich prüfen kann und dann auch im einzelnen prüft,
dürfte gegen null gehen.

Egal ob Debian, Fedora und andere - dort wird sehr viel in den Code
reingeschaut und abgeändert, um die Software zu erweitern, Bugs zu
beheben oder das Verhalten der Software anzupassen an Besonderheiten
der jeweiligen Distribution.

Dnnoch würde ich so etwas, was in einem Binärfile versteckt ist das
zum Testen einer Dekompression benutzt wird, vermutlich nicht finden.

Post by Andreas M. Kirchwitz
Die Zahl der distributionseigenen Patches ist teilweise riesig.
Nicht immer zum Vorteil, die bauen auch Bugs ein, die ärgerlich
sind, weil man sie ja nicht im offiziellen Source Code findet,
sondern die man sich aus den Distributions-Quellen holen muss.

Wenn ich mir Sources angucken möchte, nehme ich apt source. Alleine
weil es für alle Pakete direkt funktioniert. Die unmodifizierten
Upstream sources bekomme ich dabei direkt mit, und es is sogar
sichergestellt, dass der Upstream Tarball immer noch derselbe ist aus
dem das Paket gebaut wurde. Das kann man für den potenziell "after the
fact" von der Upstream-Website geholten release tarball nicht sagen.

Post by Andreas M. Kirchwitz
Ziel ist bei all dem natürlich nicht, bösen Code zu finden, aber
es ist ein Nebeneffekt, der sich automatisch ergibt, wenn man so
viel mit dem Source Code hantiert. Es ist de facto eine Kontroll-
instanz, die Angreifer zu überwinden haben. Sonst wäre es viel
einfacher, bösen Code in Open Source reinzuschmuggeln.

Ich habe noch nicht viel gesehen, mache das ja erst seit 25 Jahren,
aber diese Art des Backdoors im Quelltext zu verstecken ist mit das
komplexeste was ich in diesem Bereich bisher gesehen habe.

Grüße
Marc

[Alexander Schreiber]

Post by Andreas M. Kirchwitz
Open Source ist in der Vergangenheit auch schon oft genug
manipuliert worden mit Backdoors etc. Das ist nichts Neues.
Open Source sagt überhaupt nichts aus. Es muss halt auch
mal ein anderer diesen Code tatsächlich anschauen. Sonst
ist es fast das gleiche wie Closed Source.
Open Source lebt halt sozusagen vom Schwarm. Irgendwem wird
es früher oder später auffallen, wenn etwas merkwürdig ist.

Allerdings. Und dieser Vorfall bestätigt den alten Spruch: "Die
Worte, die einer Entdeckung vorausgehen sind nicht 'Heureka!',
sondern 'Hmm, das ist aber seltsam ...'" ;-)

Post by Andreas M. Kirchwitz
Heutzutage könnte man das sinnvoll eine AI machen lassen,
die können ja bereits Code "lesen" und "schreiben", viele
junge Programmierer verwenden AI maßgeblich dafür. (Was dann
die neue Frage aufwirft, wie weit man der AI vertrauen kann.)

Die Analysen von Code, den LLMs (AI ... nicht wirklich, das sind
mehr so regexes auf Steroiden und Speed) rauswerfen haben ein
grosszügiges Mass von klassischen (und potentiell ausnutzbaren)
Fehlern gefunden. So Kategorie "unerfahrener Programmierer,
schlecht bezahlt und unter Zeitdruck mit unvollständiger
Spezifikation".

Wer einen Bullshit-Generator zum Code schreiben einsetzt, bekommt halt
dass, was zu erwarten ist.

Und vulnerability analysis von LLM ist fast noch schlimmer. Eignet
sich hervorragend zum Maintainer ärgern (weil die mit bullshit
vulnerability reports zugeworfen werden), aber nicht für viel anderes.

Post by Andreas M. Kirchwitz

Post by Martin Klaiber
Oder habt ihr mit so etwas gerechnet und bin nur ich zu blauäugig
gewesen? Ich muss gestehen, mit so viel krimineller Energie hatte
ich nicht gerechnet.

IBM / Red Hat / Fedora wollen möglichst viel Software auf Flatpak
umstellen, Ubuntu hat bereits Kern-Komponenten in Snap ausgelagert.
Das ist im Grunde Closed Source durch die Hintertür. Kriminelle
und Geheimdienste freuen sich über so viel Dummheit.

*hualp* Flatpack und Snap, ganz toller Mist.

Post by Andreas M. Kirchwitz
Mal schauen, wann auch Debian kippt.

Hoffentlich nicht.

Man liest sich,
Alex.

[Marc Haber]

Post by Alexander Schreiber
Die Analysen von Code, den LLMs (AI ... nicht wirklich, das sind
mehr so regexes auf Steroiden und Speed) rauswerfen haben ein
grosszügiges Mass von klassischen (und potentiell ausnutzbaren)
Fehlern gefunden. So Kategorie "unerfahrener Programmierer,
schlecht bezahlt und unter Zeitdruck mit unvollständiger
Spezifikation".
Wer einen Bullshit-Generator zum Code schreiben einsetzt, bekommt halt
dass, was zu erwarten ist.

Ich habe in den letzten Wochen einigen Code mit Hilfe von ChatGPT
"geschrieben" und ich muss sagen, ich hatte schon dümmere
Programmier-Hiwis und Extreme-Programming-Partner die mir weniger
folgen konnten.

Besonders das Grunt Work der Programmierung ("schreibe mir eine
Beispiel-Klasse, mit der Key-Value-Paare im Speicher gecached und
zusätzlich in redis persistiert werden können, mit Getter- und
Setter-Methoden etc") macht ChatGPT erschreckend gut. Man kann mit dem
Ding richtige Dialoge führen ("gib mir mal Beispielcode der über TCP
feststellt ob ein Host erreichbar ist", "ja, ok, jetzt bitte als
Klasse").

Und ChatGPT kommt auch viel besser mit solchem Syntax-Kram zurecht als
ich mit meinen Drölfzig Programmiersprachen, der keine wirklich
"richtig" beherrscht ("heißt es nun else if, elsif oder elif?").

Andererseits muss man natürlich den Code der da rausfällt prüfen und
anfassen damit er wirklich das tut was er soll, aber die 80 Prozent
der Softwareentwicklung, die so gar keinen Spaß machen, erledigt
ChatGPT ziemlich gut. Ich hatte aber auch schon den Fall, dass die
"KI" sich verrant hat und immer zwischen zwei falschen Lösungen hin-
und her gewechselt ist. Und manchmal muss man es mit der künstlichen
Nase darauf stoßen dass es Bullshit verzapft hat ("Aber ist das nicht
total ineffizient, weil Du dreimal über den ganzen Datenbestand drüber
iterierst" - "Ja, da hast Du recht, hier ist der bessere Code").

In so einer Situation ist ein Tool, das das "gesamte Wissen" und allen
Beispielcode des Internet gefressen hat und den Durchschnitt davon
stumpf nachplappert genau das richtige.

Und ja, ich gebe zu dass das in einer so weit verbreiteten
Programmiersprache wie Python sicher besser funktioniert als in einem
Exoten wie Prolog oder Modula-2.

Grüße
Marc

[Tim Landscheidt]

Post by Marc Haber
[…]
In so einer Situation ist ein Tool, das das "gesamte Wissen" und allen
Beispielcode des Internet gefressen hat und den Durchschnitt davon
stumpf nachplappert genau das richtige.
Und ja, ich gebe zu dass das in einer so weit verbreiteten
Programmiersprache wie Python sicher besser funktioniert als in einem
Exoten wie Prolog oder Modula-2.

Nachplappern trifft es recht gut: Ich wollte (und will) in
RPM ein Makro umdefinieren und dabei die vorherige Definiti-
on wiederholen (= der bestehenden Definition weiteren Text
anfügen). Ich bin mir zu 99 % sicher, dass das nicht geht.
ChatGPT schlägt nicht nur eifrig eine nicht funktionierende
Variante vor, wenn man es darauf hinweist, schlägt es weite-
re nicht funktionierende Varianten vor, bis man sich irgend-
wann in einem Kreis (oder einer Endlosschleife) befindet.

Das ist gewissermaßen des Äquivalent des InterNet-Nutzers,
der unter einen Fehlerbericht Lösungsvorschläge postet, ohne
die Problembeschreibung überhaupt vollständig gelesen zu ha-
ben.

Zudem – Stichwort Sicherheitslücken – sieht man dem Code
dann selten an, ob der wiedergekäute Beispielcode auf dem
Niveau des ersten Abends eines VHS-Programmierkurses ist
oder den Stand der Technik wiedergibt.

Tim

[Marc Haber]

Post by Tim Landscheidt

Post by Marc Haber
[…]
In so einer Situation ist ein Tool, das das "gesamte Wissen" und allen
Beispielcode des Internet gefressen hat und den Durchschnitt davon
stumpf nachplappert genau das richtige.
Und ja, ich gebe zu dass das in einer so weit verbreiteten
Programmiersprache wie Python sicher besser funktioniert als in einem
Exoten wie Prolog oder Modula-2.

Nachplappern trifft es recht gut: Ich wollte (und will) in
RPM ein Makro umdefinieren und dabei die vorherige Definiti-
on wiederholen (= der bestehenden Definition weiteren Text
anfügen). Ich bin mir zu 99 % sicher, dass das nicht geht.
ChatGPT schlägt nicht nur eifrig eine nicht funktionierende
Variante vor, wenn man es darauf hinweist, schlägt es weite-
re nicht funktionierende Varianten vor, bis man sich irgend-
wann in einem Kreis (oder einer Endlosschleife) befindet.

Das hin- und her springen zwischen zwei inkorrekten Lösungen habe ich
auch schon erlebt und in meinem Artikel erwähnt.

Grüße
Marc

[Thomas Hochstein]

Post by Martin Klaiber
Ich muss gestehen, dass ich schockiert bin. Dass diese Person (oder
mehrere, die sich hinter dem Namen Jia Tan verbergen) es geschafft
hat, den Rang eines Maintainers zu erreichen

Lieber Himmel, was ist denn schwierig daran, den "Rang" eines
"Maintainers" in einem beliebigen Software-Projekt zu erreichen? Man trägt
ein bißchen etwas bei, kümmert sich, dann ist man drin.

Der Verlauf ist ja offen einsehbar: wie bei vielen Projekten gab es nur
einen Maintainer, der nicht mehr genug Zeit für das Projekt aufbringen
konnte (und zudem "mental health problems" schilderte). Das Projekt
stagniert, Nutzer beschweren sich (vielleicht echte, vielleicht Fakes),
dem Maintainer tut das in der Seele weh, das sein Projekt so stagniert.
Jemand bietet Hilfe an und kümmert sich, Nutzer rufen dazu auf, der
Maintainer solle Hilfe annehmen oder das Projekt direkt ganz abgeben. Der
Maintainer nimmt Hilfe an. Schwups, ist "Jia Tan" Maintainer.

Post by Martin Klaiber
und über mehrere Jahre
Schadcode einbauen konnte, ohne entdeckt zu werden.

Der "Schadcode" wurde Anfang diesen Jahres eingebaut, soweit ich das der
bisherigen Darstellung entnehmen konnte-

Post by Martin Klaiber
Nun frage ich mich, ob ob in Linux vielleicht schon etliche Backdoors
existieren, ohne dass man davon weiß.

Wer weiß?

Es braucht dazu gar nicht erst Böswilligkeit, es genügen simple Fehler.

<https://lists.debian.org/debian-security-announce/2008/msg00152.html>
<https://xkcd.com/221/>
<https://xkcd.com/424/>
(Blieb ~ 2 Jahre lang unentdeckt.)

Das Problem betrifft genauso kommerzielle Software:
<https://en.wikipedia.org/wiki/2020_United_States_federal_government_data_breach>

Das Argument, das Risiko sei bei quelloffener Software geringer, weil
jeder sie prüfen könne, leidet in der Praxis daran, dass (a) eben nicht
jeder prüfen kann und (b) noch weniger es tatsächlich tun.

Oder mit anderen Worten:
| I think the point that you're assuming (probably because you quite
| reasonably think it's too obvious to need to be stated, but I'm not sure
| it's that obvious to everyone) is that malicious code injected via a
| commit is significantly easier to detect than malicious code that is only
| in the release tarball.
|
| This is not *always* correct; it really depends on how many eyes are on
| the upstream repository and how complex or unreadable the code upstream
| writes normally is. (For example, I am far from confident that I can
| eyeball the difference between valid and malicious procmail-style C code
| or random M4 files.) I think it's clearly at least *sometimes* correct,
| though, so I'm sympathetic, particularly given that it's already Debian
| practice to regenerate the build system files anyway.
<https://lists.debian.org/debian-devel/2024/03/msg00344.html>

Post by Martin Klaiber
<https://boehs.org/node/everything-i-know-about-the-xz-backdoor>
Demnach wurde offenbar bei dem xz-Projekt, bei dem der ursprüngliche
Maintainer überlastet war, Druck ausgeübt, einen weiteren Maintainer
zu installieren, wobei diese Person vorher schon off-list mit dem
ursprünglichen Maintainer zusammengearbeitet hat und sich vermutlich
so ein gewisses Vertrauen erarbeiten konnte.

Ja. Alles ganz normal. So passiert das dutzendfach.

Post by Martin Klaiber
Im Nachhinein wird natürlich klar, dass das vermutlich
<https://news.ycombinator.com/item?id=39866275>

Oder <https://bugs.launchpad.net/ubuntu/+source/xz-utils/+bug/2059417>.

Post by Martin Klaiber
Alles ziemlich krass, finde ich.

Tatsächlich?

Das Problem ist doch nicht neu. Es gibt eine Unzahl von Projekten, die
fast alle nicht genügend Manpower haben oder im Wesentlichen von
Einzelpersonen als Hobby betrieben werden, darunter auch ganz zentrale
(oft entsprechend alteingeführte) "Bausteine".

<https://xkcd.com/2347/>

Post by Martin Klaiber
Oder habt ihr mit so etwas gerechnet und bin nur ich zu blauäugig
gewesen? Ich muss gestehen, mit so viel krimineller Energie hatte
ich nicht gerechnet.

Der Aufwand ist groß, aber für einen Nationalstaat doch sehr, sehr
überschaubar.

-thh

[Tim Landscheidt]

Post by Thomas Hochstein
[…]

Post by Martin Klaiber
Oder habt ihr mit so etwas gerechnet und bin nur ich zu blauäugig
gewesen? Ich muss gestehen, mit so viel krimineller Energie hatte
ich nicht gerechnet.

Der Aufwand ist groß, aber für einen Nationalstaat doch sehr, sehr
überschaubar.

Naja, der vorherige Maintainer wird in seinen besseren Zei-
ten das Projekt auch nur nebenher betreut haben. Das heißt,
der Täter musste vielleicht zwei Jahre gelegentlich nach
Feierabend ein paar Mails beantworten und konnte parallel an
seinem Exploit arbeiten. Für Nicht-Beamte ist das keine
Vollzeittätigkeit :-).

Lediglich für die „kommerzielle“ Verwertung des Zugriffs auf
alle per SSH erreichbaren Debian-/Fedora-Systeme wäre es
wahrscheinlich sinnvoll, sich jemandem mit einer dicken
Brieftasche anzudienen.

Tim

[Gerald E¡scher]

Post by Thomas Hochstein
<https://xkcd.com/424/>

Die Sicherheizlücke von Ubuntu ist aber ziemlich BÖSE ;-)