BSI warnt vor Kritischer Schwachstelle in weit verbreitetem Software-Produkt Log4j

[Cherusker]

Eine Möglichkeit, wie man als (mac)user direkt im eigenen Heimnetzwerk betroffen sein kann, ist die Managementkonsole von Ubiquiti, mit denen die Unifi-Geräte verwaltet werden. Aber die haben bereits ein Update veröffentlicht. Wenn man da also mit aktuellen Patches unterwegs ist, kann man den panic mode wieder verlassen.

Panic Mode ist nie gut. Kühler Kopf ist besser. Ob die schnellen Patches reichen, bezweifel ich. Einfache RegEx schützen nur vor Script Kiddies, aber nicht vor ernsthaften Angriffen. Viele Firmen werden mit Patches beruhigen, die aber nichts bringen. Die Lösung liegt tiefer.

 

[Johanna K]

Die arbeiten unbezahlt in ihrer Freizeit dran.

Die Entwickler selbst schreiben

Log4j maintainers have been working sleeplessly on mitigation measures [...]. Yet nothing is stopping people to bash us, for work we aren't paid for,

Da ist es, das Problem.
Hätten wir die Entwickler bezahlt, könnten wir sie jetzt bashen.

Wenn die Entwickler das Geld, das momentan nötig ist, die Folgen der Schwachstelle zu beheben, als Gehalt bekommen, die hätten sehr gut davon leben können.

Aber diese Rechnung ist fehlerhaft. Es gibt sehr viele Open-Source-Programme, aber nur wenige, die so hohe Kosten zur Beseitigung einer Lücke erfordern. Diese Kosten müsste man über alle genutzten Projekte verrechnen. Je mehr Programme man benutzt, desto höher ist das Risiko, eines zu erwischen, die solch ein Ding drinnen hat.

Aber dass auch milliardenschwere Firmen Open Source verwenden, ohne den Entwicklern jemals Geld zukommen zu lassen, ist schon fragwürdig.

 

[tocotronaut]

Naja. Abschalten der Loggingfunktion wenn man sie gerade nicht braucht ist ja schonmal ein Schritt...

Das Problem scheint unter anderem auch aus der Defaulteinstellung "ON" zu resultieren..

 

[Johanna K]

Naja. Abschalten der Loggingfunktion wenn man sie gerade nicht braucht ist ja schonmal ein Schritt...

Ob man Logging braucht, weiß man meistens erst nachher.

Nein, Logging ist schon gut und richtig. Man sollte sich aber darauf verlassen können, dass einfach nur geloggt wird ohne Seiteneffekte. "Keep it simple" wäre manchmal eine gute Strategie. log4j bietet reichlich viele Möglichkeiten in der Konfiguration, hierhin und dahin loggen, automatisch Mails schicken etc.. Je mehr Funktionen, desto eher eine die schief geht.

Die kritische Funktion hätte niemals per Default freigeschaltet werden dürfen. Aber vermutlich war dem log4j-Team selbst nicht bewusst, was man da für einen Mist mit machen kann.

 

[MOM2006]

in der Firma mal evaluiert. 2 Produkte haben log4j2 im Einsatz. Soweit so schlecht. Viel fataler aber, dass Hundertschaften von Hersteller noch immer das log4j 1 rein nageln in ihre Produkte, welches seit 2015 end of allem ist und auch nachweislich eine nicht grad unkritische Lücke offen hat. aber das ist nicht nur bei log4j so.

 

[Cherusker]

Die Entwickler selbst schreiben

Log4j maintainers have been working sleeplessly on mitigation measures [...]. Yet nothing is stopping people to bash us, for work we aren't paid for,

Das halte ich für ein zu billiges Argument. Sie haben Log4j entwickelt und zur Verfügung gestellt. Ob gegen Geld oder für lau, ändert ja nichts an dem Fehler und macht ihn auch nicht weniger problematisch. Der Fehler liegt bei den Entwicklern.

Die andere Seite der Medaille ist, dass die kostenlosen Produkte so oft ungeprüft übernommen werden, anstatt die Entwickler mit Patches zu unterstützen. Immerhin wird Log4j ja von genügend Konzernen genutzt, die die Man Power und das Know How hätten, den Code mal zu prüfen.

 

[MOM2006]

aber eines muss man mir schon plausibel erklären. warum reagiert eine Komponente, die ansich ja nur für logging zuständig ist, aktiv auf das, was im logging geschickt wird? Wie kommt man auf die Idee so etwas zu bauen? Da ist doch so ein Supergau schon vorprogrammiert.

 

[Barry Lyndon]

aber eines muss man mir schon plausibel erklären. warum reagiert eine Komponente, die ansich ja nur für logging zuständig ist, aktiv auf das, was im logging geschickt wird? Wie kommt man auf die Idee so etwas zu bauen? Da ist doch so ein Supergau schon vorprogrammiert.

Über das Warum können wir nur spekulieren. Meine Theorie aufgrund meiner Erfahrungen mit Programmierern ist: weil sie häufig SVPs sind (selbstverliebte Programmierer), die unbedingt übers Ziel hinausschiessen möchten, weil es so geil ist und „von-hinten-durch-die-Brust“ ist noch geiler.

 

[Dextera]

Es funktioniert wie spezifiziert

 

[sailingHobbit]

Über das Warum können wir nur spekulieren. Meine Theorie aufgrund meiner Erfahrungen mit Programmierern ist: weil sie häufig SVPs sind (selbstverliebte Programmierer), die unbedingt übers Ziel hinausschiessen möchten, weil es so geil ist und „von-hinten-durch-die-Brust“ ist noch geiler.

Was ich selbst aber auch schon oft erlebt habe: irgendein User möchte sowas haben, dann wird es halt eingebaut, vor allem wenn er selbst den Pull Request erstellt hat und nur noch einer der Hauptentwickler mergen muss. An die möglichen Nebenwirkungen wird dabei selten gedacht, weil sich da gerade bei so Libraries schnell ziemlich komplexe Szenarien ergeben, die niemand mehr vollständig nachvollziehen kann.

Klassiker für Funktionen in Software sind auch Anforderungen, die sich irgendein Fachbereich hauptberuflich ausdenkt aber kein Kunde nutzt oder tatsächlich braucht. Hab ich selbst oft genug erlebt, teilweise versenken Großkonzerne in so Sachen Millionenbeträge. Die Begründung ist dann oftmals "war im alten System auch so".

 

[magfoo]

Ja, klar. Aber mit welchem Ziel …möglicherweise … Daten?

muss nicht. Man kann einen so übernommen Server auch ganz gut für weitere Angriffe auf dritte nutzen. Wo bekommt man schon mal so gut angebundenes Werkzeug wie Minecraftserver?

As always: Es ist open source software. Willst Du das einsetzen steht es Dir frei, da drin nach Fehlern zu suchen und sie zu fixen.
Wollte bisher niemand. Also darf sich niemand wundern.

So schauts aus.

Panic Mode ist nie gut. Kühler Kopf ist besser. Ob die schnellen Patches reichen, bezweifel ich. Einfache RegEx schützen nur vor Script Kiddies, aber nicht vor ernsthaften Angriffen. Viele Firmen werden mit Patches beruhigen, die aber nichts bringen. Die Lösung liegt tiefer.

Das Problem ist eher: Die Lücke ist ja nicht neu, die ist nur gerade öffentlich geworden.
Wie viele Leute haben schon Ihre remoteshells verteilt und nutzen die jetzt weiter nach dem Patch von log4j?
eigentlich heisste es hier: neu aufsetzen.

 

[magfoo]

Was heißt hier schimpfen … Programmierer (Maskulin beabsichtigt!) sind häufig eine besondere Spezies von selbstverliebten Bastlern.
Typische Dialoge aus meiner beruflichen Praxis:

Barry: Ich will das nicht.
SVP (selbstverliebter Programmierer): Aber Mr. Barry! Damit kann der Anwender viel komfortabler …
Barry (unterbricht): Ich will das nicht.
SVP: Und wenn die Anwender falsche Dat…
Barry (noch ruhig): ich will das nicht.
SVP: Aber die Fachbereiche wollen es!
Barry (immerhin Vorgesetzter oder Auftraggeber des SVP und selber ehemaliger Programmierer): ICH WILL DAS NICHT!

Oft genug machen sie es trotzdem, heimlich, und hinterlassen hysterisch verwachsenen Dschungelcode.
Was treibt diese Spezies dazu, (häufig) unnötige Funktionen (auch noch an den falschen Stellen) einzubauen? Ist das Eitelkeit? Unvermögen? Selbstbefriedigung? Oder alles zusammengenommen?

Zurück zum Topic: Der von wegus verlinkte Artikel enthält eine Grafik, die hervorragend veranschaulicht.
Danke natürlich wieder an @Johanna K, @tocotronaut und @wegus.

Sorry, aber das sind doch Klischees
Für so einen Quatsch haben die meisten angestellten Entwickler überhaupt keine Zeit oder müssen unsinnige Vorgaben erfüllen.
Eher läuft es so:
Barry: Ich will XYZ
SVP: Aber das macht es unsicher
Barry: Ich will aber
SVP: Ich bin dagegene, weil...
Barry(unterbricht SVP): morgen ist Release, mach das so wie ich sage sonst macht's jemand anderes.

Oder eben:
Barry: morgen ist das fertig!
SVP: wir müssen noch drölfzig Bugs fixen
Barry: egal, morgen ist Termin, da ist das fertig: Compiliert es?
SVP: Ja, aber es gibt trotzdem noch Bugs.
Barry: Ist egal, patchen wir später. Der Kunde hat einen Servicevertrag.

 

[Cherusker]

Wie viele Leute haben schon Ihre remoteshells verteilt und nutzen die jetzt weiter nach dem Patch von log4j?
eigentlich heisste es hier: neu aufsetzen.

Richtig! Das beinhaltet meine Aussage. Patchen reicht nicht! Weder, um vor der Lücke künftig geschützt zu sein, noch davor, bereits betroffen zu sein, ohne es zu wissen. Selbst neu aufsetzen kann zu wenig sein. Es muss über eine völlig andere Struktur des Netzwerkes nachgedacht werden.

 

[magfoo]

Richtig! Das beinhaltet meine Aussage. Patchen reicht nicht! Weder, um vor der Lücke künftig geschützt zu sein, noch davor, bereits betroffen zu sein, ohne es zu wissen. Selbst neu aufsetzen kann zu wenig sein. Es muss über eine völlig andere Struktur des Netzwerkes nachgedacht werden.

Naja, erst mal reicht neu Aufsetzen und patchen natürlich aus. Dann ist die Lücke geschlossen und wenn man aus einer vertrauenswürdigen Quelle neu installiert ist diese Gefahr gebannt.
Was soll man denn am Netzwerk ändern? Bugs wird es immer wieder geben. Auch ist das hier kein Problem des Netzwerkes, es ist einfach ein Softwarebug in einer sehr häufig verwendeten Softwarekomponente.

 

[Cherusker]

Naja, erst mal reicht neu Aufsetzen und patchen natürlich aus. Dann ist die Lücke geschlossen und wenn man aus einer vertrauenswürdigen Quelle neu installiert ist diese Gefahr gebannt.

Nein, mit patchen ist die Lücke nicht unbedingt geschlossen. Der Patch ändert nur die Vorsteinstellungen. Wer die alte Konfiguration einspielt, reißt die Lücke wieder auf. Soetwas dürfte häufig passieren, weil die wenigsten Log4j ausreichend kennen dürften.

Was soll man denn am Netzwerk ändern? Bugs wird es immer wieder geben. Auch ist das hier kein Problem des Netzwerkes, es ist einfach ein Softwarebug in einer sehr häufig verwendeten Softwarekomponente.

Weil es Bugs immer geben wird, muss man sich unter anderem über sein Netzwerk Gedanken machen. Segmentierung wäre schon mal ein guter Schritt. Beschränkungen der erlaubten Verbindungen und Rechte ein weiterer.

 

[magfoo]

Nein, mit patchen ist die Lücke nicht unbedingt geschlossen. Der Patch ändert nur die Vorsteinstellungen. Wer die alte Konfiguration einspielt, reißt die Lücke wieder auf. Soetwas dürfte häufig passieren, weil die wenigsten Log4j ausreichend kennen dürften.

Das ist eine frage des Patches.
Es gibt Hersteller von Software, die log4j komplett rauspatchen oder deaktivieren.
Das nur die Voreinstellungen geändert werden ist so pauschal falsch. 90% der User nutzen ja nicht den Patch von log4j, sondern den von einem Softwarehersteller der log4j in seinem Produkt verwendet.

Weil es Bugs immer geben wird, muss man sich unter anderem über sein Netzwerk Gedanken machen. Segmentierung wäre schon mal ein guter Schritt. Beschränkungen der erlaubten Verbindungen und Rechte ein weiterer.

Das macht man ja schon. Das ist ja nichts neues.

 

[MOM2006]

Das ist eine frage des Patches.
Es gibt Hersteller von Software, die log4j komplett rauspatchen oder deaktivieren.
Das nur die Voreinstellungen geändert werden ist so pauschal falsch. 90% der User nutzen ja nicht den Patch von log4j, sondern den von einem Softwarehersteller der log4j in seinem Produkt verwendet.

und gefühlt 95% der software hersteller gehören mit einem nassen fetzen durchs universum geprügelt, weil sie es ihm jahr 2021 noch immer nicht schaffen eine log4j version zu verwenden, die nicht end of support und allem ist und zudem auch lücken aufweist. bei der analyse unserer systeme gab es grad mal 2 produkte die ein log4j2 verwendeten, der rest ca. 40 produkte verwendet eine log4j1 version wo seit 2015 auf log4j2 verwiesen wird.

in vielen bereichen, vor allem wenns dann um security geht, ist die kundschaft der software hersteller viel zu gutmüdig und nimmt da jeden dreck ohne grossartige evaluierung ab.

edit wirft halt kein gutes bild auf die entwickler. wer als mitigation nur die umgebungsvariable setzt, der könnt böse überraschungen erleben.

CVE - CVE-2021-45046 (mitre.org)

 

[MOM2006]

achja sehr empfehlenswert beide seiten zu lesen --> Kommentar zu Log4j: Es funktioniert wie spezifiziert | heise online

 

[magfoo]

und gefühlt 95% der software hersteller gehören mit einem nassen fetzen durchs universum geprügelt, weil sie es ihm jahr 2021 noch immer nicht schaffen eine log4j version zu verwenden, die nicht end of support und allem ist und zudem auch lücken aufweist. bei der analyse unserer systeme gab es grad mal 2 produkte die ein log4j2 verwendeten, der rest ca. 40 produkte verwendet eine log4j1 version wo seit 2015 auf log4j2 verwiesen wird.

in vielen bereichen, vor allem wenns dann um security geht, ist die kundschaft der software hersteller viel zu gutmüdig und nimmt da jeden dreck ohne grossartige evaluierung ab.

edit wirft halt kein gutes bild auf die entwickler. wer als mitigation nur die umgebungsvariable setzt, der könnt böse überraschungen erleben.

CVE - CVE-2021-45046 (mitre.org)

Ich weiss halt wie meine Kollegen "Wünsche" und Anforderungen definieren. Bin selber kein echter Entwickler, ich bin für IT-Infrastruktur zuständig.
Wäre ich Softwareentwickler, ich würde ja für die einfach nicht arbeiten, die Firmen versuchen es aber. Was willst du da groß ordentlich entwickeln wenn die Anforderung lautet: "Ich will das es funktioniert. Was sage ich nicht, aber es muss funktionieren".
Und das ist keine Übertreibung, das ist bittere Realität.
RPO und RTO? Kann man nicht mal mit Bildern erklären, das wird einfach nicht verstanden. "Muss immer laufen, nix darf verlorengehen, darf aber nix kosten".

Ich will in dieser Welt kein Softwareentwickler sein, das steht fest.

"Nennen Sie ihre wichtigsten Geschäftsprozesse". Rückfrage der GL an mich: "Herr XYZ, was sind Geschäftsprozesse". Original so erlebt als das BSI bei uns saß wegen Grundschutz.

Ordentliche Entwicklung fängt mit ordentlichen Anforderungen an. Und daran scheitern die meisten Projekte schon. Die eigentliche Entwicklung fährt dann mit Ansage gegen die Wand.

 

[tocotronaut]

Ein Gechefsprozess ist wenn dem Chef das Gehalt überwiesen wird...