Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
News Sonntagsfrage: Eine Woche Log4Shell, was hat das für dich bedeutet?
- Ersteller SVΞN
- Erstellt am
- Zur News: Sonntagsfrage: Eine Woche Log4Shell, was hat das für dich bedeutet?
AncapDude
Banned
- Registriert
- Dez. 2015
- Beiträge
- 1.023
Scheiß Firma hat mich im Urlaub genervt weil ich prüfen sollte ob wir davon betroffen sind. Tatsächlich gab es eine Software die eine vulnerable Version nutzte, aber laut Hersteller/Entwickler kein Angriffsvektor besteht, inzwischen gab es wohl trotzdem Maßnahmen. Zwei andere Produkte die noch auf eine 1.x Version setzen wurden vorsorglich abgeschaltet.
Öhm, nein?SheepShaver schrieb:Scanner wie SonarQube oder Veracode.
Das sind beides SAST und teilen Dir ggf. Abhängigkeiten mit. Ob deine myriaden OSSP - oder welches Akronym man auch immer verwenden möchte - Schwachstellen haben, teilen Dir so Sachen wie Snyk, Black Duck oder auch OWASP Dependency Checker mit.
Und SAST läuft am besten als Linter. ... also theoretisch. Praktisch können die Entwickler dann nix mehr schreiben, weil die IDE so saulahm geworden ist. Und schon fängt man an Kompromisse einzugehen.
...
Ich habe immer noch kein brauchbares DAST-Tool gefunden, welche statsächlich APIs und die Geschäftslogik erkunden kann.
Danke für dieses Beispiel, welches schon auf dem absteigenden Ast war.Rickmer schrieb:Damals war der Gedanke Sicherheit (bzw. Vertraulichkeit) bei vielen noch gar kein Gedanke im Kopf - siehe z.B. das SMTP-Protokoll, jegliche Verschlüsselungsmöglichkeiten usw. sind erst später drum herum gewickelt worden.
SMTP ist ein HERVORRAGENDES Beispiel dafür, warum man für andere Nutzung ggf. neuere Werkzeuge entwickeln sollte, anstatt alte immer weiter aufzubohren und zu verändern.
SMTP sollte Text übermitteln und robust - zuverlässig - sein. Das konnte es und das war es. Es erfüllte die Spezifikation. ... dann kam der Siegeszug des "Internet" und schon hatten wir den Salat.
Log4J ist GENAU so eine Altlast:
Die JNDI Funktionalität ist nämlich KEIN Bug, sondern es funktioniert wie spezifiziert!
Hurrah! Damals war das Nachladen von von ausführbarem Code - zur Laufzeit (!) - irgendwie eine saucoole Idee und wurde entsprechend umgesetzt. Deswegen wurde das auch nie gefunden, denn auf die Idee, dass es schlecht sein könnte, wildfremden Code auf zur Laufzeit auf deiner Kiste auszuführen, kamen die Leute wesentlich später.
Und Security-Audits beziehen sich meist eher auf den geschriebenen Code und dessen Verletzung von Spezifikationen als auf dessen Spezifikation an sich.
Ich dachte eher an die Programme, die sie damals für die ersten Raum- und Mondflüge entwickelt haben.
Für die ersten Clearinghäuser (die, so hört man immer noch mit COBOL laufen) etc.
Eben überall dort, wo Menschenleben auf dem Spiel standen, die ersten Programmierer hauptsächlich Frauen waren, Wasserfall ein eher revolutionärer Ansatz war und so Sachen wie das internet eher als Spielzeug betrachtet wurden. Nützlich, aber nicht wqirklich wichtig und daher auch nicht so streng zu spezifizieren.
Ergänzung ()
Joahhhh, könnte schon klappen. Wir haben da mehrere Dutzend, manche von denen arbeiten sogar zusammen.Enigma schrieb:Dafür braucht man halt einen Architekt, der die Strategie vorgibt und auch mal klar die Entscheidung trifft, einen Trend wie Vue NICHT mizugehen. Das gesamte Unternehmen ist dann halt nur so gut wie der Architect, der muss gut gewählt werden.
Und das was aus deren Federn fliesst ist sogar wirklich toll.
Hat nur leider den Haken, dass man sämtlichen Code in Rust neu schreiben müsste, was bei den Hardwarenahen Sachen in C echt spannend werden würde, oder eben nicht.
Jetzt gucken wir uns die Kosten eines derartigen Umbaus an und .... voila, die Risikobewertung und Kosten-Nutzen Rechnung machen das extremst unwahrscheinlich.
Von daher finde ich solche Aufreger wie log4j sehr nützlich, weil man damit C-Levels beeindrucken kann.
Und mit Glück bekommt man dann auch das Budget die wichtigen Teile neu zu schreiben.
Also ein Teil nach dem anderen erneuern.
Das ist so ziemlich die einzige Chance die jede Firma hat.
Alles auf einen Schlag neu zu schreiben wird jede Organisation komplett überfordern und lahmlegen.
Zuletzt bearbeitet:
Mal eine dumme Frage. Ist das ein Problem von Servern die von außen Erreichbar sind oder auch von PCs (macs, pc)?
Wenn ich das richtig verstanden habe müsste man irgendwie eine Eingabe von "außen" machen, wie ein Formular, API Aufruf, um das auszunutzen.
Oder steht da doch irgenwie noch Port offen und ich muss auch auf meinem PC etwas machen wenn da normale Desktopanwendungen laufen die Java nutzen?
Wenn ich das richtig verstanden habe müsste man irgendwie eine Eingabe von "außen" machen, wie ein Formular, API Aufruf, um das auszunutzen.
Oder steht da doch irgenwie noch Port offen und ich muss auch auf meinem PC etwas machen wenn da normale Desktopanwendungen laufen die Java nutzen?
drachenpalme
Cadet 2nd Year
- Registriert
- Jan. 2021
- Beiträge
- 25
foo_1337 schrieb:Es ist überhaupt kein Problem bei Tomcat, Wildfly, Jetty & Co log4j zu nutzen. Im Gegenteil, es wird sogar sehr oft gemacht. Wir hatten jedenfalls genug Applikationen, bei denen das der Fall war.
Magst du ein prominentes Beispiel haben? Atlassian. Ein weiteres? Vmware. Noch mehr?
Deine Aussage ist also, weil jemand in der Lage ist, eine betroffene Applikation auf einer Plattform zu deployen, hat die Plattfoirm ein Problem? Das wäre so, wie zu behaupten, der Linux-Kernel hat ein Problem, weil man auf einem Linux System ja OpenSSL mit Heartblead benutzen kann.
Sorry, nein. Tomcat, Wildfly und Jetty bringen alle eigene Logsysteme mit und sind nicht betroffen. Du kannst betroffene Applikationen darauf laufen lassen. Du kannst ja auch selber ne Applikation schreiben, die SQL-Injection oder ähnliches zulässt und das ist dann trotzdem kein Problem des Wildfly sondern eines Deiner Applikation
foo_1337 schrieb:Augenscheinlich dann genau von den Leuten, die sich mit der Thematik hier offensichtlich kein bißchen beschäftigt haben.
Ganz ehrlich, hier werd ich stinkig. Ich hab 5 Jahre über sichere Software Systeme promoviert und entwickle seit 15 Jahren kommerziell Java Anwendungen auf Tomcat/Wildfly. Ich weiß wovon ich rede.
Meine Einschätzung ist, dass Du ein Admin bist, der Anwendungen nur mit dieser Brille betrachtet. Dir ist also egal, ob der Fehler aus der Plattform oder der Anwendung kommt. Das ist für Deine Perspektive auch Wumpe, betroffen bist Du so oder so. Das ist sicherlich ein Standpunkt aber keiner, von dem aus Du andere Leute beschuldigen solltest, sich nicht mit dem Thema beschäftigt zu haben.
Mein Punkt war ein anderer: Es gibt durchaus Entwickler, die das haben kommen sehen und die jetzt nicht betroffen sind. Die Leute von Tomcat und Wildfly gehören da dazu. Meine Entwickler auch. Die von Atlassian offensichtlich nicht.
Ranayna
Admiral
- Registriert
- Mai 2019
- Beiträge
- 7.725
@prev:
Fiktives Beispiel.
Du hast zum Beispiel einen Medienplayer, der in Java geschrieben ist und log4j2 einsetzt. Dort werden dann zum Beispiel Fehlermeldungen geloggt, wenn die Datei korrupt ist, und moeglicherweise auch Metadaten wegschreibt.
Du laedst dir jetzt ein Video irgendwo herunter und spielst es ab. Dein Player kann es nicht abspielen. Kann ja mal passieren, nicht kompatible, Download korrupt, oder was auch immer.
Im Hintergrund wurdest du aber grade gehackt. Denn die wenigsten Firewalls blockieren by default den Internetverkehr nach aussen, dein Medienplayer, bzw. dessen eingebautes Log4J2 kann daher absolut problemlos seine Payload aus dem Internet laden.
EDIT: Test
EDIT2: Nochein Test. Ich sehe keinen "Post wurde bearbeitet Hinweis", obwohl es antworten gibt.
EDIT3: Weiterer Test ob jetzt ein Bearbeitet Hinweis auftaucht
EDIT4: Ja, tat er, bei Edit Nummer 3, der eigendlich Edit Nummer 5 war
Fiktives Beispiel.
Du hast zum Beispiel einen Medienplayer, der in Java geschrieben ist und log4j2 einsetzt. Dort werden dann zum Beispiel Fehlermeldungen geloggt, wenn die Datei korrupt ist, und moeglicherweise auch Metadaten wegschreibt.
Du laedst dir jetzt ein Video irgendwo herunter und spielst es ab. Dein Player kann es nicht abspielen. Kann ja mal passieren, nicht kompatible, Download korrupt, oder was auch immer.
Im Hintergrund wurdest du aber grade gehackt. Denn die wenigsten Firewalls blockieren by default den Internetverkehr nach aussen, dein Medienplayer, bzw. dessen eingebautes Log4J2 kann daher absolut problemlos seine Payload aus dem Internet laden.
EDIT: Test
EDIT2: Nochein Test. Ich sehe keinen "Post wurde bearbeitet Hinweis", obwohl es antworten gibt.
EDIT3: Weiterer Test ob jetzt ein Bearbeitet Hinweis auftaucht
EDIT4: Ja, tat er, bei Edit Nummer 3, der eigendlich Edit Nummer 5 war
Zuletzt bearbeitet:
pseudopseudonym
Admiral
- Registriert
- Mai 2017
- Beiträge
- 9.560
Und du glaubst, dass von denen, die halbblind FOSS als Abhängigkeit installieren, die meisten einen besseren Job machen würden, wenn sie die Abhängigkeiten selbst entwickeln?ComputerJunge schrieb:Vergrößert der weltweite Erfolg von FOSS das Problem? Ganz zweifellos. Wenige "Hanseln" mit der Maintenance einer solchen zentralen Komponente alleine zu lassen ist eine Zumutung, fahrlässig und eigentlich sogar unverschämt.
Aber ja, als Unternehmen mehr beizusteuern, wäre schon gut.
IMNSHO MUSS man diese Frage immer stellen!kim88 schrieb:Die Frage sollte (nicht könnte) man sich bei jeder Verwendung eines FOSS Projekts stellen.
Spätestens nach Solarwinds muss eigentlich jeder IT-Sec-Affine bei Tool-Chain, FOSS u.ä. die Alarmglocken läuten!
F
foo_1337
Gast
Nein, das ist nicht die Aussage. Die Aussage ist, dass wenn auf einer Kiste z.B. Tomcat läuft, die Wahrscheinlichkeit, dass log4j läuft, hoch ist. Eben so wie wenn eine Linux Kiste Webserver ist, die Wahrscheinlichkeit hoch ist, dass OpenSSL läuft. Obwohl es auch hier z.B. GnuTLS oder LibreSSL gibt.drachenpalme schrieb:Deine Aussage ist also, weil jemand in der Lage ist, eine betroffene Applikation auf einer Plattform zu deployen, hat die Plattfoirm ein Problem? Das wäre so, wie zu behaupten, der Linux-Kernel hat ein Problem, weil man auf einem Linux System ja OpenSSL mit Heartblead benutzen kann.
Das habe ich auch nicht behauptet. Und du kannst, um mal den Tomcat rauszupicken, diesen selbst halt auch so konfigurieren, dass er log4j nutzt anstelle von java.util.logging (was halt auch kein "eigenes Logsystem" des Tomcats ist).drachenpalme schrieb:Sorry, nein. Tomcat, Wildfly und Jetty bringen alle eigene Logsysteme mit und sind nicht betroffen. Du kannst betroffene Applikationen darauf laufen lassen. Du kannst ja auch selber ne Applikation schreiben, die SQL-Injection oder ähnliches zulässt und das ist dann trotzdem kein Problem des Wildfly sondern eines Deiner Applikation
Merke ich. Hast du da irgendwelche Aktien im Spiel oder was ist das Problem?drachenpalme schrieb:Ganz ehrlich, hier werd ich stinkig.
Vielleicht ließt du nochmal den Kontext: Ich habe einem User hier verbreitete Beispiele genannt, die verwundbar sein können, weil er den Einsatz von Java weltweit sehr kleingeredet hat und das ganze damit runterspielen wollte.
Ah, mal wieder die Nummer "ich mache das schon lange, ich muss es wissen!"drachenpalme schrieb:Ganz ehrlich, hier werd ich stinkig. Ich hab 5 Jahre über sichere Software Systeme promoviert und entwickle seit 15 Jahren kommerziell Java Anwendungen auf Tomcat/Wildfly. Ich weiß wovon ich rede.
Meine Einschätzung hat folgenden Hintergrund: Wir haben als Dienstleister verschiedenste Kunden und in fast allen Fällen wo die 3 bzw. 4 (wir haben auch den JBoss EAP) genannten im Einsatz waren, wurde eben log4j verwendet. Andere hier im Thread haben das bereits für Ihre Applikationen oder deren Kunden auf dieser Basis bestätigt.drachenpalme schrieb:Meine Einschätzung ist, dass Du ein Admin bist, der Anwendungen nur mit dieser Brille betrachtet. Dir ist also egal, ob der Fehler aus der Plattform oder der Anwendung kommt.
Glückwunsch! Aber du hast meinen Punkt nicht verstanden. Schön, wenn eure Applikationen nicht verwundbar sind. Schön auch wenn Tomcat/Wildfly in den Defaults nicht betroffen sind. Blöd halt, wenn es in Real World anders aussieht. Und genau deshalb werde ich auch nach wie vor jeden, der das Einsetzt warnen, zu prüfen, ob log4j verwendet wird. Ob du das jetzt gut findest oder nicht.drachenpalme schrieb:Mein Punkt war ein anderer: Es gibt durchaus Entwickler, die das haben kommen sehen und die jetzt nicht betroffen sind. Die Leute von Tomcat und Wildfly gehören da dazu. Meine Entwickler auch.
Zuletzt bearbeitet von einem Moderator:
Ranayna
Admiral
- Registriert
- Mai 2019
- Beiträge
- 7.725
@prev: Wahrscheinlich. Aber keinesfalls garantiert.
Als erstes stellt man sich natuerlich die Frage, was macht ein Programm ueberhaupt, wenn es keine Eingaben von irgendwoher bekommt?
Es sind durchaus Szenarien denkbar, das ein Programm welches Log4J2 einsetzt, bei einem Absturz problematische Strings wegloggen will.
Das faengt bei Usernamen und Pfaden an, koennte laufende Prozesse beinhalten, und bestimmt noch andere Sachen die mir grade nicht einfallen.
Als erstes stellt man sich natuerlich die Frage, was macht ein Programm ueberhaupt, wenn es keine Eingaben von irgendwoher bekommt?
Es sind durchaus Szenarien denkbar, das ein Programm welches Log4J2 einsetzt, bei einem Absturz problematische Strings wegloggen will.
Das faengt bei Usernamen und Pfaden an, koennte laufende Prozesse beinhalten, und bestimmt noch andere Sachen die mir grade nicht einfallen.
War seit 10. Dezember quasi rund um die Uhr im Einsatz, da bei uns im Konzern eine IT Krise ausgerufen wurde und ich mich bei den in meinem Verantwortungsbereich liegenden Applikationen um das Patch Management, etc auf die jeweils aktuellste Log4j Version kümmern musste. Leider würde der Schaden bei einem Ausnutzen der Sicherheitslücke gleich bei zig Millionen Euro liegen (exklusive Reputationsschaden). Ist bzw war mega nervig, immer kann halt das gut gezahlte Geld den Schmerz bei einer solchen IT Krise auch nicht kompensieren.
Ansonsten verwundert mich das Abstimmergebnis nicht wirklich, dass hier auf Computerbase die Mehrzahl gar nicht von der Vulnerability betroffen waren (die wenigsten werden gar wissen, was log4j ist und wofür es eingesetzt wird; man braucht sich ja als Referenz nur mal das CB Weihnachtsgewinnspiel ansehen, wie viele hier Probleme bei der Beantwortung der doch relativ simplen Fragen hatten).
Ansonsten schon mal schöne und hoffentlich erholsame Feiertage an all meine Leidensgenossen (die jetzt oder die vergangenen Tage auch so extrem im Einsatz waren).
Ansonsten verwundert mich das Abstimmergebnis nicht wirklich, dass hier auf Computerbase die Mehrzahl gar nicht von der Vulnerability betroffen waren (die wenigsten werden gar wissen, was log4j ist und wofür es eingesetzt wird; man braucht sich ja als Referenz nur mal das CB Weihnachtsgewinnspiel ansehen, wie viele hier Probleme bei der Beantwortung der doch relativ simplen Fragen hatten).
Ansonsten schon mal schöne und hoffentlich erholsame Feiertage an all meine Leidensgenossen (die jetzt oder die vergangenen Tage auch so extrem im Einsatz waren).
- Registriert
- Sep. 2018
- Beiträge
- 3.447
Nein - im Gegenteil.pseudopseudonym schrieb:Und du glaubst, dass von denen, die halbblind FOSS als Abhängigkeit installieren, die meisten einen besseren Job machen würden, wenn sie die Abhängigkeiten selbst entwickeln?
Das.pseudopseudonym schrieb:Aber ja, als Unternehmen mehr beizusteuern, wäre schon gut.
Und wenn es nicht direkt mit (temporären - was auch nicht automatisch sinnvoll ist) Entwicklungskapazitäten erfolgt, dann halt indirekt mit Geld, um z.B. regelmäßige Audits (mit entsprechender öffentlicher Aufmerksamkeit) wahrscheinlicher zu machen. Die jetzt stattfindenden in flagranti Audits sind für ziemlich viele jedenfalls auch nicht günstig.
Ich habe im Zuge dieser Lücke gelernt, dass wir unter den TopTen-Contributern (was für fürchterliches Denglisch) beim Thema OSS gehören.ComputerJunge schrieb:Das.
Und wenn es nicht direkt mit (temporären - was auch nicht automatisch sinnvoll ist) Entwicklungskapazitäten erfolgt, dann halt indirekt mit Geld,
Fand ich schon mal gut.
Für alle, die mal einen schönen Rant zum Thema lesen wollen:
www.heise.de/amp/meinung/Kommentar-zu-log4j-Es-funktioniert-wie-spezifiziert-6294476.html
- Registriert
- Sep. 2018
- Beiträge
- 3.447
für log4j? Aber egal, wofür: Top!Unnu schrieb:, dass wir unter den TopTen-Contributern (was für fürchterliches Denglisch) gehören.
Mit Sicherheit nicht!ComputerJunge schrieb:für log4j?
Wie schon gesagt, dass steckt „nur“ in so ein paar zugekauften Produkten, die halt gebündelt mit unseren verkloppt werden.
Wir sind hauptsächlich in Linuxen, C und C++ unterwegs. Für Core-Produkte!
Das ganze zusätzliche Geraffel deckt so ziemlich jede Mode der letzten 2 Dekaden ab!
„Zum Glück“ muss ich mich persönlich „nur“ mit Hyperscalern auseinandersetzen.
Also alles was mit den Rechnern anderer Leute (Cloud) zu tun hat. Und zwar alle 4.
Das reicht mir völlig!
SheepShaver
Commodore
- Registriert
- Nov. 2004
- Beiträge
- 4.334
Öhm, doch?Unnu schrieb:Öhm, nein?
Das sind beides SAST und teilen Dir ggf. Abhängigkeiten mit. Ob deine myriaden OSSP - oder welches Akronym man auch immer verwenden möchte - Schwachstellen haben, teilen Dir so Sachen wie Snyk, Black Duck oder auch OWASP Dependency Checker mit.
Nennt sich bei Veracode SCA. Und ja, SAST Scans machen wir nur auf dem MASTER branch. Das ist suboptimal, da Feedback etwas spät kommt, aber besser als nichts.
jemandanders
Commander
- Registriert
- Mai 2019
- Beiträge
- 2.978
Du lebst unter einem Stein?Gr33nHulk schrieb:In der Umfrage fehlt: "Keine Ahnung, höre ich zum ersten mal von."
Ähnliche Themen
- Antworten
- 222
- Aufrufe
- 32.734
- Antworten
- 153
- Aufrufe
- 15.665
- Antworten
- 584
- Aufrufe
- 51.827
- Antworten
- 480
- Aufrufe
- 59.753
- Antworten
- 246
- Aufrufe
- 28.511