Ist zwar nicht die Beste Quelle aber ich denke das geht Viral die nächsten Tage. https://www.express.de/ratgeber/digital/minecraft-sicherheitsluecke-fliegt-auf-wie-gross-ist-die-gefahr-82309 Zitat der Quelle : "Das Bundesamt für Sicherheit in der Informationstechnik (BSI) setzte am Samstag, 11. Dezember 221, seine Warnstufe zu der Sicherheitslücke von Orange auf Rot hoch." Muss also was dran sein. ;) Nur für die die es interessiert. Ansonsten kann das gerne gelöscht werden.
:
Verschoben durch Moderator
Und warum postest du das nicht im dafür passenden Forum "PC Hard- & Software"? Oder richtet sich das an die Leute, die Java-Anwendungen (natürlich mit log4j) auf Mikrocontrollern laufen haben?
weitere Infos z.B. hier https://www.heise.de/news/Kritische-Zero-Day-Luecke-in-log4j-gefaehrdet-zahlreiche-Server-und-Apps-6291653.html (vom Freitag) und inzwischen auch auf breiter Fläche: https://www.sueddeutsche.de/wirtschaft/bsi-bedrohungslage-warnstufe-log4j-1.5485806 https://www.tagesschau.de/inland/bsi-schadsoftware-101.html
Axel S. schrieb: > Und warum postest du das nicht im dafür passenden Forum "PC Hard- & > Software"? Weil es sich hauptsächlich um Server handelt. Und es Leute gibt die sich HIER mit MC beschäftigen, ihren PC im Griff haben, und einen externen SERVER betreiben. Oder einfach gesagt. Ich wollte die breite Masse erreichen. Wenn es dich nicht juckt, lass es mit lesen. Mich juckt es auch nicht wirklich, da ich kein Server mehr habe sondern nur noch Web-Space. Aber viele haben ein (V-)*Server*(chen). Genau wie ich damals auch.
Oh, ein Software-Bug. Uih. Übrigens, in China ist ein Sack Reis umgefallen. Das dortige Landwirtschaftsministerium hat deswegen die Warnstufe Rot ausgerufen. Die Medien berichten landesweit.
Beitrag #6907660 wurde von einem Moderator gelöscht.
Einer schrieb: > Oh, ein Software-Bug. Uih. Jedenfalls einer der Viral geht. Siehe die Links oben. Und ein Software-Bug wovon sogar die Express was weiß ist schon was besonderes. ;) Davon abgesehen ist das ein BUG sondern eine sehr gut funktionierende Sicherheitslücke ;)
Schlaumaier schrieb: > Davon abgesehen ist das ein BUG sondern eine sehr gut funktionierende > Sicherheitslücke ;) Davon abgesehen ist das KEIN BUG sondern eine sehr gut funktionierende Sicherheitslücke ;) Und ich muss meine Tastatur mal reinigen. ;(
Beitrag #6907680 wurde von einem Moderator gelöscht.
Das tolle am Internet ist, dass man nicht alles lesen muss, was einem nicht interessiert. Auch wird man nicht gezwungen, auf alles mit dem blöden Kommentar zu reagieren, dass es "niemanden" interessiert. Das sind wir wieder beim allgemein grassierenden Egoismus, bei dem nur das eigene Ego zählt. Denn denkt mal darüber nach. Es gibt noch andere Menschen auf der Welt, denen es vielleicht interessiert. Schlaumaier schrieb: > Weil es sich hauptsächlich um Server handelt. Es handelt sich nicht hauptsächlich um Server. Viele Java-Programme verwenden log4j. In vielen kann das Teil nicht einfach aktualisiert werden. Das ist eine sehr dumme, schlafende Sicherheitslücke.
Schlaumaier schrieb: > Nur für die die es interessiert. Ansonsten kann das gerne gelöscht > werden. Die Sicherheitslücken sind, und anders wäre es auch wieder nicht zu erwarten, in Ubuntu
1 | bionic (18.04LTS) (java): Apache Log4j - Logging Framework for Java [universe] |
2 | 2.10.0-2: all |
3 | |
4 | focal (20.04LTS) (java): Apache Log4j - Logging Framework for Java [universe] |
5 | 2.11.2-1: all |
6 | |
7 | hirsute (21.04) (java): Apache Log4j - Logging Framework for Java [universe] |
8 | 2.13.3-1: all |
9 | |
10 | impish (21.10) (java): Apache Log4j - Logging Framework for Java [universe] |
11 | 2.13.3-1: all |
12 | |
13 | jammy (java): Apache Log4j - Logging Framework for Java [universe] |
14 | 2.13.3-1: all |
**nicht gefixt.** Es ist halt ein Paket aus universe. PS: Ja, ich habe mir auch die Changelogs für jede Distriversion angeschaut. https://packages.ubuntu.com/search?keywords=liblog4j2-java&searchon=names&suite=all§ion=all Und in Linux Mint auf Ubuntu basierend wohl daher auch nicht. Bei denen ist die Package Search Webseite leider immer noch broken, bzw. wird das Paket dort nicht gefunden, da man nur nach einer kleinen Auswahl suchen kann. Ausgenommen davon ist vielleicht die Linux Mint Debian Edition (LMDE), die könnte das Update erhalten haben. In Debian kam das Sicherheitsupdate übrigens gestern für stable und oldstable, sowie sid rein:
1 | rmadison liblog4j2-java |
2 | liblog4j2-java | 2.15.0-1~deb10u1 | oldstable-new | all |
3 | liblog4j2-java | 2.15.0-1~deb11u1 | stable-new | all |
4 | liblog4j2-java | 2.15.0-1 | buildd-unstable | all |
5 | liblog4j2-java | 2.15.0-1 | unstable | all |
Debian stable und Debian oldstable sind somit geschützt. Ja, ich konnte nicht widerstehen. :)
Das log4j Sicherheitsproblem ist ernst, diese Bibliothek hatte schon in der Vergangenheit Lücken, hauptsächlich im Zusammenhang mit der Netzwerk Funktionalität, diese neue Lücke in Version 2 hat es aber in sich. Christian H. schrieb: > Es handelt sich nicht hauptsächlich um Server. Viele Java-Programme > verwenden log4j. In vielen kann das Teil nicht einfach aktualisiert > werden. Das ist eine sehr dumme, schlafende Sicherheitslücke. Viele Firmen haben über das Wochenende schon Udpates in Produktion deployed, ist halt schön wen man das innerhalb von einer Stunde machen kann in der Cloud wenn die CI/CD Pipeline nach aktuellen best practices läuft. Andere haben Updatezyklen von 3 Monaten.. manche sind noch langsamer, andere wiederum haben gar keine Updates. Ist alles nicht so schlimm wenn die Geräte die diese anfälligen Version laufen haben nicht "online" gehen können. Falls doch, ist es eine Gute Gelegenheit sich mal zu überlegen wie man wichtige Updates auf diese Geräte bringen kann..
weiterlesen: https://www.heise.de/news/Roter-Alarm-Log4j-Zero-Day-Luecke-bedroht-Heimanwender-und-Firmen-6292863.html
Ein Auszug aus der Changelog:
1 | apache-log4j2 (2.15.0-1~deb11u1) bullseye-security; urgency=high |
2 | |
3 | * Team upload. |
4 | * Backport version 2.15.0 to Bullseye and fix CVE-2021-44228. |
5 | (Closes: #1001478) |
6 | |
7 | -- Markus Koschany <apo@debian.org> Sat, 11 Dec 2021 17:15:53 +0100 |
8 | |
9 | apache-log4j2 (2.15.0-1) unstable; urgency=high |
10 | |
11 | * Team upload. |
12 | * New upstream version 2.15.0. |
13 | - Fix CVE-2021-44228: |
14 | Chen Zhaojun of Alibaba Cloud Security Team discovered that JNDI features |
15 | used in configuration, log messages, and parameters do not protect |
16 | against attacker controlled LDAP and other JNDI related endpoints. An |
17 | attacker who can control log messages or log message parameters can |
18 | execute arbitrary code loaded from LDAP servers when message lookup |
19 | substitution is enabled. From version 2.15.0, this behavior has been |
20 | disabled by default. (Closes: #1001478) |
21 | * Update debian/watch to track the latest releases. |
22 | * Declare compliance with Debian Policy 4.6.0. |
23 | |
24 | -- Markus Koschany <apo@debian.org> Sat, 11 Dec 2021 15:01:57 +0100 |
Das neue Paket ist übrigens aus dem Debian Security Zweig.
Nano schrieb: > Das neue Paket ist übrigens aus dem Debian Security Zweig. nutzt das überhaupt irgendwer? Bibliotheken für Java werden doch so gut nie vom OS gezogen.
Eine Kurze Suche auf meinen Windows Partitionen ergab übrigens, dass der MOD Forged Alliance Forever für Supreme Commander ebenfalls log4j verwendet und somit ein Update braucht, sofern sich die Sicherheitslücke in dem Fall ausnutzen lassen sollte (was ich nicht überprüft habe, ich habe nur geschaut, ob es benutzt wird):
1 | find -iname *log4j* |
2 | ./####/Downlord's FAF Client/lib/log4j-api-2.11.2.jar |
3 | ./####/Downlord's FAF Client/lib/log4j-to-slf4j-2.11.2.jar |
Mladen G. schrieb: > Nano schrieb: > >> Das neue Paket ist übrigens aus dem Debian Security Zweig. > > nutzt das überhaupt irgendwer? > > Bibliotheken für Java werden doch so gut nie vom OS gezogen. Bei mir kam das Update ganz normal rein. Und ja, der Security Zweig ist normalerweise in der source list eingetragen: Ausschnitt aus meiner /etc/apt/sources.list Datei:
1 | deb https://deb.debian.org/debian-security/ bullseye-security main contrib non-free |
2 | deb-src https://deb.debian.org/debian-security/ bullseye-security main contrib non-free |
Es ist bei Ubuntu leider wie befüchtet. Ich habe gerade Xubuntu 21.10 in meiner VM aktualisiert und das ist das Ergebnis:
1 | apt show liblog4j2-java |
2 | Package: liblog4j2-java |
3 | Version: 2.13.3-1 |
4 | .... |
Version 2.13.3-1 ist unsicher. Letzter Changelog Eintrag ist vom Januar 2021, also 12 Monate alt:
1 | apt changelog liblog4j2-java |
2 | apache-log4j2 (2.13.3-1) unstable; urgency=medium |
3 | |
4 | * New upstream release |
5 | - Refreshed the patches |
6 | - Ignore the new log4j-docker, log4-jpl, log4j-kubernetes and |
7 | log4j-spring-cloud-config modules |
8 | * Depend on libgeronimo-jpa-2.0-spec-java instead of libjpa-2.1-spec-java |
9 | * Removed the -java-doc package (Closes: #835382) |
10 | * Standards-Version updated to 4.5.1 |
11 | * Switch to debhelper level 13 |
12 | * No longer track the release candidates |
13 | |
14 | -- Emmanuel Bourg <ebourg@apache.org> Tue, 19 Jan 2021 14:29:47 +0100 |
Man beachte, dass es sich hierbei um eine Ubuntu 21.10 Version handelt, während dieses Paket vom Januar ist. Da gab es also nichtmal große Updates. In Linux Mint 20.2, was ich hier ebenfalls auf einer VM habe und gerade upgedated habe, hat das Paket übrigens die Version 2.11.2-1 und der letzte Changelogeintrag ist vom 10.9.2019. Sowohl bei Ubuntu, als auch Linux Mint (nicht Debian Edition) ist das Paket also veraltet und die Sicherheitslücke nicht gestopft.
Nano schrieb: > Es ist bei Ubuntu leider wie befüchtet. In Arch Linux läuft das etwas anders: Da hat schon vorgestern einer den Maintainer des Pakets freundlich auf das Problem hingewiesen. Schon nach 6 Minuten kam die Antwort des Maintainers: "give me a second" In einer Sekunde hat er es zwar nicht geschafft ;-), aber nach 4 Minuten war das korrigierte Paket online. https://aur.archlinux.org/packages/log4j/
Mal ne Frage an die linux-Leute. Kommt das auch automatisch mit der Aktualisierungsverwaltung. ?? Ich kenne mich mit Linux nicht wirklich aus. Sorry
Nachtrag : Habe linux mint cimarron 20.* und 17.* (wegen 32 bit) Falls das jemand hat, gibt es da schon updates zu . ??
Nano schrieb: > Sowohl bei Ubuntu, als auch Linux Mint (nicht Debian Edition) ist das > Paket also veraltet und die Sicherheitslücke nicht gestopft. Da Ubuntu für log4j wie für viele andere Pakete einfach Debianpakete nimmt und neu baut müssen sie auf Debian warten. Gestern Nachmittag hatte Debian auch noch kein Update, mittlerweile schon. Spätestens Montag landet es dann auch bei Ubuntu.
Nano schrieb: > Mladen G. schrieb: >> Nano schrieb: >> >>> Das neue Paket ist übrigens aus dem Debian Security Zweig. >> >> nutzt das überhaupt irgendwer? >> >> Bibliotheken für Java werden doch so gut nie vom OS gezogen. > > Bei mir kam das Update ganz normal rein. > Bestimmt, aber das nutzt doch niemand. Bibliotheken werden mit der Anwendung bzw. dem App Server ausgeliefert, wer da OS Versionen nutzt, hat ganz andere Probleme IMO.
Schlaumaier schrieb: > Falls das jemand hat, Nach deiner eigenen Aussage du selber: > Nachtrag : Habe linux mint cimarron 20.* und 17.* > gibt es da schon updates zu . ?? Wiese beantwortest du diese Frage nicht einfach selber?
Axel S. schrieb: > Und warum postest du das nicht im dafür passenden Forum "PC Hard- & > Software"? Oder richtet sich das an die Leute, die Java-Anwendungen > (natürlich mit log4j) auf Mikrocontrollern laufen haben? Witzigerweise auch JA Ich habe gerade mal mein PC nach der Datei gescannt und der einzige Ort wo die ist, ist im Verzeichnis der IDE von Arduino. Nur so als Nebeninfo. ;)
Auf meinem Werkstattrechner hat die Suche nach "log4j" folgende Dateien zu Tage gefördert: log4j-api-2.13.3.jar, log4j-slf4j-impl-2.13.3.jar, log4j2.xml, log4j-api-2.13.2.jar, log4j-api-2.12.0.jar, log4j-core-2.12.0.jar, log4j-1.2.17.jar, Laut VirusTotal sind alle unauffällig. Kann man sich einigermaßen auf dieses Ergebnis verlassen? Gibts eine Liste der gefährdeten Dateiversionen?
Nano schrieb: > In Linux Mint 20.2, was ich hier ebenfalls auf einer VM habe und gerade > upgedated habe, hat das Paket übrigens die Version 2.11.2-1 und der > letzte Changelogeintrag ist vom 10.9.2019. Bei Linux Mint ist das standardmäßig gar nicht installiert, weil man es am Desktop auch nicht braucht. Insofern: irrelevant. Für Server sieht's anders aus, aber da wäre Debian sowieso vorzuziehen.
Schlaumaier schrieb: > Mal ne Frage an die linux-Leute. > > Kommt das auch automatisch mit der Aktualisierungsverwaltung. ?? Wenn das Paket dafür upgedated wird, ja, dann gibt es ein Update. Ob es automatisch eingespielt wird, hängt von der Einstellung in deinem Linux Mint ab. > Nachtrag : Habe linux mint cimarron 20.* und 17.* (wegen 32 bit) > Falls das jemand hat, gibt es da schon updates zu . ?? Nein, siehe oben. Für Linux Mint basierend auf Ubuntu gibt es noch keine Updates. Falls dein Linux Mint die Debian Edition ist, könnte es anders aussehen. Du kannst das aber recht leicht mit apt show paketname und apt changelog paketname nachprüfen.
Blechbieger schrieb: > Nano schrieb: >> Sowohl bei Ubuntu, als auch Linux Mint (nicht Debian Edition) ist das >> Paket also veraltet und die Sicherheitslücke nicht gestopft. > > Da Ubuntu für log4j wie für viele andere Pakete einfach Debianpakete > nimmt und neu baut müssen sie auf Debian warten. Gestern Nachmittag > hatte Debian auch noch kein Update, mittlerweile schon. Debian sid bekam, siehe Changelog (siehe oben), das Update Gestern um 15:01:57 Uhr und Debian Stable bekam es um 17:15:53 Uhr als Security Backports in den Security Zweig. > Spätestens > Montag landet es dann auch bei Ubuntu. Da wäre ich mir an deiner Stelle nicht so sicher, denn es ist ein Paket aus dem Ubuntu universe Zweig und dieser Zweig wird von Canonical nicht aktiv gepflegt. Es kann also gut sein, das am Montag immer noch kein Update kommt, da es von der Community abhängt. Wenn sich da einer findet, dann ja, ansonsten wohl eher nicht. Oder anders gesagt, falls du Ubuntu einsetzt, es liegt auch an dir, denn auch du bist Teil der Community.
Mladen G. schrieb: > Bestimmt, aber das nutzt doch niemand. Das sehe ich nicht so. Bei mir wurde es installiert, also wird's eine Anwendung nutzen. > Bibliotheken werden mit der Anwendung bzw. dem App Server ausgeliefert, Als Docker, Flatpack, Snap usw. Image ist das sicherlich so. > wer da OS Versionen nutzt, hat ganz andere Probleme IMO. Nicht wenn die Distri was taugt.
was nun schrieb: > Laut VirusTotal sind alle unauffällig. Kann man sich einigermaßen auf > dieses Ergebnis verlassen? Du hast nicht begriffen wo das Problem ist. Lies nochmal die verlinkten Artikel.
was nun schrieb: > Auf meinem Werkstattrechner hat die Suche nach "log4j" folgende Dateien > zu Tage gefördert: > > log4j-api-2.13.3.jar, > log4j-slf4j-impl-2.13.3.jar, > log4j2.xml, > log4j-api-2.13.2.jar, > log4j-api-2.12.0.jar, > log4j-core-2.12.0.jar, > log4j-1.2.17.jar, > > Laut VirusTotal sind alle unauffällig. Kann man sich einigermaßen auf > dieses Ergebnis verlassen? VirusTotal ist keine Datenbank für Sicherheitslücken. Du musst auf die Version schauen und dann gegebenenfalls, falls diese Version eine manuelle Pflege bekommt, da noch drauf schauen. Für eine manuelle Einpflege in alte Versionen ist das Datum und eventuelle Changelogergänzungen, sofern vorhanden, relevant. In Upstream wurde die Sicherheitslücke CVE-2021-44228 erst in 2.15 gefixt. https://logging.apache.org/log4j/2.x/changes-report.html Die Versionen 2.0 bis 2.14.1 sind laut BSI nämlich alle anfällig. Siehe hier: https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=3 > Gibts eine Liste der gefährdeten Dateiversionen? Siehe BSI. Einfach immer dem CVE-2021-44228 Eintrag nachgehen.
Yalu X. schrieb: > Wiese beantwortest du diese Frage nicht einfach selber? und wie ? Ich würde sie nicht stellen wenn ich wüste ob diese "Aktualisierungsverwaltung" das Problem für mich löst. Habe nämlich gerade beide gestartet und NIX von Java gesehen. Und ich habe schon oft Pakete nachinstallieren müssen die ich in der Paketverwaltung nicht gefunden habe. Und wie gesagt, ich habe wenig Ahnung von Linux. Da läuft eh nix Sicherheitsrelevantes drauf, ich mag nur keine Sicherheitslücken auf meinen Geräten.
Nano schrieb: > Da wäre ich mir an deiner Stelle nicht so sicher, denn es ist ein Paket > aus dem Ubuntu universe Zweig und dieser Zweig wird von Canonical nicht > aktiv gepflegt. Es ist aber zumindest schonmal auf dem Radar mit Status "needs triage": https://ubuntu.com/security/CVE-2021-44228
Ach ja, und ein ähnlicher Fall letztes Jahr mit einer älteren Version dieser Lib wurde offenbar durchaus zentral in Ubuntu gefixt: "In general, a standard system update will make all the necessary changes." https://ubuntu.com/security/notices/USN-4495-1
Schlaumaier schrieb: > Yalu X. schrieb: >> Wiese beantwortest du diese Frage nicht einfach selber? > > und wie ? Du gehst in Synaptic, suchst nach log4j (nur Paketnamen), stellst erleichtert fest, daß nichts davon installiert ist, und legst Dich wieder schlafen.
Nano schrieb: > Für eine manuelle Einpflege in alte Versionen ist das Datum und > eventuelle Changelogergänzungen, sofern vorhanden, relevant. Korrektur. Genaugenommen ist das Datum ein Indiz. Ob das dann tatsächlich gefixt wurde, da muss man dann schon den Code anschauen, wenn keine Changelog dabei ist.
Nop schrieb: > Ach ja, und ein ähnlicher Fall letztes Jahr mit einer älteren Version > dieser Lib wurde offenbar durchaus zentral in Ubuntu gefixt: > "In general, a standard system update will make all the necessary > changes." > https://ubuntu.com/security/notices/USN-4495-1 Wie schon gesagt, wenn sich aus der Community einer findet, dem das wichtig ist, dann wird es eventuell gefixt. Es gibt ein paar wenige Pakete in universe, die von Canonical nicht aktiv gepflegt werden, aber dafür von der Community gut gepflegt werden, weil da ein paar sind, denen diese Pakete dann wichtig sind. Ein Beispiel wäre bspw. Wireshark, das bekommt regelmäßig updates, auch Sicherheitsupdates. Meist sind das dann wichtige Pakete, die entweder viele nutzen oder von Leuten benutzt werden, die Ahnung bezüglich IT haben. Wie eben im Fall von Wireshark. Der große Rest kriegt meist nichts, das gilt auch für solche Pakete, wo die Nutzer zwar keine Fixes einbringen, aber die Sicherheitslücke Canonical melden. Die Sicherheitslücke wird bei Canonical dann wie im obigen Beispiel vermerkt, aber Canonical wartet dann auf die Community, dass die nen diff Patch uploaden. Und wenn dann da nichts kommt, dann bleibt die Sicherheitslücke drin. Da diese Sicherheitslücke aber überall in den Nachrichten herumläuft und auch von Serverbetreibern benötigt wird, stehen die Chancen gut, dass die Community da nen Fix nachliefert.
Nano schrieb: > Da diese Sicherheitslücke aber überall in den Nachrichten herumläuft und > auch von Serverbetreibern benötigt wird, stehen die Chancen gut, dass > die Community da nen Fix nachliefert. Ich meine natürlich, dass die Software von Serverbetreibern benötigt wird.
Nop schrieb: > Du gehst in Synaptic, suchst nach log4j (nur Paketnamen), stellst > erleichtert fest, daß nichts davon installiert ist, und legst Dich > wieder schlafen. Na, ja, so einfach ist das nicht. Irgendwelche beliebige Java SW zieht sich ihr eigenes log4j rein. Solange man aber keinen Server mit Java Paketen betreibt, sollte einem das egal sein.
Nano schrieb: > was nun schrieb: >> Auf meinem Werkstattrechner hat die Suche nach "log4j" folgende Dateien >> zu Tage gefördert: >> >> log4j-api-2.13.3.jar, >> log4j-slf4j-impl-2.13.3.jar, >> ... >> Laut VirusTotal sind alle unauffällig. Kann man sich einigermaßen auf >> dieses Ergebnis verlassen? > > VirusTotal ist keine Datenbank für Sicherheitslücken. Das hatte ich befürchtet. Allerdings sind ja dort verschiedene Scanner am Werk. Hatte gehofft, wenigstens einige würden potentielle Sicherheitslücken anmeckern... > Du musst auf die Version schauen und dann gegebenenfalls, falls diese > Version eine manuelle Pflege bekommt, da noch drauf schauen. > Für eine manuelle Einpflege in alte Versionen ist das Datum und > eventuelle Changelogergänzungen, sofern vorhanden, relevant. > > In Upstream wurde die Sicherheitslücke CVE-2021-44228 erst in 2.15 > gefixt. > https://logging.apache.org/log4j/2.x/changes-report.html > > Die Versionen 2.0 bis 2.14.1 sind laut BSI nämlich alle anfällig. Ok, danke. Das ist ja sehr bedauerlich alles. Ich fürchte bei mir wird überhaupt nichts automatisch gefixt... Habe keinen Bock mehr! Entweder ich lösche den Mist oder nehme die Rechner vom Netz... Mal schauen.
Andreas B. schrieb: > Na, ja, so einfach ist das nicht. Irgendwelche beliebige Java SW zieht > sich ihr eigenes log4j rein. Installiert man besp. Arduino händisch, Fritzing ist es dort auch dabei: 2.12 Sowie in burp, SOAP-UI und noch zig anderer Javasoftware die man manuell installiert hat. Das ist praktisch überall dabei aber meist in Uraltversionen 1.x. Bei solchen Programmen such man das entspr Verzeichniss tausche die Log4j-core und Log4j-api durch die 2.15er Versionen aus fertig. Die alte 1.x-Versionen lässt man in Ruhe, die haben den Bug nicht. Oder man fummelt in den Startupscripte rum und hängt an die java-optionen ein -Dlog4j2.formatMsgNoLookups=true ran. Ausserdem betrifft einen der Bug auch nicht wenn man ein aktuelle Java 8 ab u121 im Einsatz hat, selbst die ältere Arduinoide oben kommt mit einem u191 wo die entspr. jndi-Funktionalität ausgeschaltet ist die aktiviert sein muss um den Exploit auszunutzen. Selbst wenn man die passende alten Libs und Java hat, es betrifft dann immer noch nicht jede Anwendung die Endanwender installieren, das sind meist keine Serveranwendungen wo jemand von aussen den passenden String eingeben kann. Ich sag mal 99% der Anwender die Javasoftware auf ihrem Rechner haben, sind durch diese Software auf ihrem Rechner nicht betroffen. Das ist eher ein Problem für Serverbetreieber die im Backend Java laufen haben.
Andreas B. schrieb: > Solange man aber keinen Server mit Java Paketen betreibt, sollte einem > das egal sein. Für Privatleute könnte relevant sein: der Netzwerkdrucker der Switch der Router sonstige Rechner mit Serverdiensten. Das könnten auch Spiele die als Server arbeiten und Verbindungen mit anderen Spielern aus dem Internet ermöglichen, falls sie diese Software einsetzen. Bei obigem Forged Alliance würde ich also auf den ersten Blick erst einmal auf einem Patch warten, bevor ich das wieder nutzen würde. ABER: Die Sicherheitslücke ist durch Eingaben, falls ich das jetzt richtig gelesen haben sollte, auch lokal ausnutzbar. D.h. Bibliotheken, Unis, Firmen usw. deren Rechner vielleicht nicht im Internet hängen, aber lokal Zugang zu Dritten zugänglich machen, könnten auch betroffen sein.
Ergängzung: Gibt allerdings auch Prgramme die mit einer fetten Jar als lib daherkommt wo dann andere jars drinnstecken wie eben log4j, da muss man dann halt mal reinschauen, sind technisch nur Zipdateien.
was nun schrieb: > Nano schrieb: >> was nun schrieb: >>> Auf meinem Werkstattrechner hat die Suche nach "log4j" folgende Dateien >>> zu Tage gefördert: >>> >>> log4j-api-2.13.3.jar, >>> log4j-slf4j-impl-2.13.3.jar, >>> ... >>> Laut VirusTotal sind alle unauffällig. Kann man sich einigermaßen auf >>> dieses Ergebnis verlassen? >> >> VirusTotal ist keine Datenbank für Sicherheitslücken. > > Das hatte ich befürchtet. Allerdings sind ja dort verschiedene Scanner > am Werk. Hatte gehofft, wenigstens einige würden potentielle > Sicherheitslücken anmeckern... Nein, die suchen nicht nach Sicherheitslücken. Die suchen nur nach Schadsoftware in bestehenden Binaries. > Ich fürchte bei mir wird überhaupt nichts automatisch gefixt... > Habe keinen Bock mehr! Entweder ich lösche den Mist oder nehme die > Rechner vom Netz... Mal schauen. Lies dir die PDF vom BSI durch. Da gibt es eine Konfigurationsmöglichkeit um den betroffenen Logdienst zu deaktivieren, dann ist der auch nicht mehr anfällig und die Software kann weiterbenutzt werden, sofern nicht auf die Logfunktionen zugegriffen wird.
Nano schrieb: > der Netzwerkdrucker > der Switch > der Router Da läuft in 99% der Fälle keine Javasoftware drauf.
Berufsberatung schrieb: > Sowie in burp, SOAP-UI und noch zig anderer Javasoftware die man > manuell installiert hat. Das ist praktisch überall dabei aber meist in > Uraltversionen 1.x. Aus dem BSI Schreiben: "Die Log4J Versionen 1.x sind von der aktuellen Schwachstelle nach aktueller Kenntnis nicht betroffen [GIT2021d]. Die Version 1.x wird, auch wenn sie noch in diversen Produkten eingesetzt wird, nicht mehr vom Hersteller unterstützt. Sie ist End-of-Life und durch andere Schwachstellen verwundbar. Daher sollten auch noch eingesetzte Log4J Versionen 1.x ebenfalls auf eine nicht-verwundbare Version 2.x aktualisiert werden." https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=3
Gerade mal die Logs von Arudino angeschaut. Der loggt hier nur den Zugriff auf die Server für Updates, ansonsten nix. Fehleingaben über diesen jndi-String kann man also nirgends machen damit die mal im Log auftauchen. Und selbst wenn, dazu muss man am Rechner sitzen und wenn ich das kann brauche ich diese Lücke sowieso nicht mehr. Dieser Angriff betrifft zu 99% Serveranwendungen und werden meist isoliert betrieben wo man auch nicht wahllos jede Adresse aufrufen kann. Da ist idR alles dicht und nur definierte Addressen sind offen. Allerdings gab es dennoch genug Demos bei bekannten Firmen deren Webanwendungen kaputt waren. Wenn die anderweitig richtig konfiguriert gewesen wären hätte diese Lücke nicht ausgenutzt werden können. Aber das ist wieder eine andere Baustelle. @nano: "Die Log4J Versionen 1.x sind von der aktuellen Schwachstelle nach aktueller Kenntnis nicht betroffen [GIT2021d]." Ja ich weiss das wollte ich noch erwähnen dass man in diesem Fall nichts machen muss. Habe ich wohl vergessen.
Berufsberatung schrieb: > Nano schrieb: >> der Netzwerkdrucker >> der Switch >> der Router > > Da läuft in 99% der Fälle keine Javasoftware drauf. Das kann man nie wissen. Vor allem einem Drucker würde ich zutrauen, dass der viel Bloatware enthält. Und Java spart Entwicklungskosten, da es genug Programmierer gibt, die Java können.
Nano schrieb: > Und Java spart Entwicklungskosten, da es genug Programmierer gibt, die > Java können. Ist kein Argument, es gibt auch genug Entwickler für andere Sprachen da würde ich dann auch "Geld sparen" nach deiner Logik. Erst mal muss genug Power und Platz auf der Kiste vorhanden sein, das ist in dem Bereich meist nicht der Fall, da muss die billigste schmalste hardware rein, weil die dann tausendfach verkauft wird, die Software wird nur einmal entwickelt, höchstens ein Update, dann gibts schon das nächste Modell. Java ist da viel zu fett auch mit abgespeckter runtime, völlig andere Baustelle. Ja es läuft auch auf Smartphones, da hat man aber das passende Ökosystem drumherum geschaffen und war ne Design und Strategieentscheidung, das ist mit so Kisten wie Druckern nicht vergleichbar. Bei richtigen Servern wo Java etabliert ist spielt das keine Rolle, da kostet Hardware nix (= man mietet sich entspr. Resourcen in der Cloud), da ist Software das Teuerste und die wird gehegt und gepflegt.
Berufsberatung schrieb: > Ergängzung: Gibt allerdings auch Prgramme die mit einer fetten Jar > als > lib daherkommt wo dann andere jars drinnstecken wie eben log4j, da muss > man dann halt mal reinschauen, sind technisch nur Zipdateien. Dieses Skript eignet sich dafür recht gut: https://stackoverflow.com/a/4623213 D.h. den Code einfach kopieren, als Datei mit bspw. Endung *.sh abspeichern. Dann mit bspw. chmod ausführbar machen und mit skriptname.sh log4j starten. Ich habe das mal gemacht und bspw folgendes gefunden: SMCIPMITool.jar JViewerX9.jar TrapView.jar IPMIView20.jar Alle diese jar Dateien sind Bestandteil des IPMIView Bundles, das man bei Supermicro für sein IPMI fähiges Mainboard downloaden und nutzen kann. Es ist im Prinzip die javabasierte IPMI Clientsoftware um den IPMI fähigen Rechner remote per IPMI zu konfigurieren und zu nutzen. Der Normalanwender dürfte da also nicht betroffen sein. Es sei denn natürlich, er betreibt wie ich ein IPMI fähiges NAS und benutzt diese Client Software auf seinem PC. Und natürlich gesetzt den Fall, dass es sich überhaupt um die betroffenen Versionen von log4j handelt und überhaupt ein Ausnutzungsszenarion gegeben ist. Mediathekview scheint diese log4j Software auch zu benutzen. Zumindest gibt es dafür eine XML Datei Namens log4j2 PS: Das Skript kann man noch dahingehend abändern und den Eintrag -name durch -iname ersetzen, dann sollten auch groß geschriebene JAR Dateiendungen mitberücksichtigt werden. Wer nur die jar Dateien ausgeben will, der setzt vor dem echo $match ein # Zeichen. Bei Verzeichnisnamen, die ein Leerzeichen enthalten, macht das Skript noch Probleme. Das müsste noch angepasst werden. Die Einträge in der Variable $jar die den Pfad enthält müssten angepasst werden, wenn sie ein Leerzeichen enthalten.
berufsberatung schrieb: > Nano schrieb: >> Und Java spart Entwicklungskosten, da es genug Programmierer gibt, die >> Java können. > Ist kein Argument, es gibt auch genug Entwickler für andere Sprachen da > würde ich dann auch "Geld sparen" nach deiner Logik. Das ist ein Argument, denn ein C oder C++ Progammierer wäre teuer. Da macht es also schon Sinn, die Software stattdessen in Java zu schreiben, wenn es die Maschine zulässt. > Erst mal muss genug Power und Platz auf der Kiste vorhanden sein, Ja, das ist natürlich klar. > das > ist in dem Bereich meist nicht der Fall, da muss die billigste schmalste > hardware rein, weil die dann tausendfach verkauft wird, die Software > wird nur einmal entwickelt, höchstens ein Update, dann gibts schon das > nächste Modell. Ich weiß. Aber so ein Drucker kann durchaus genug RAM und Leistung haben. Vor allem wenn es ein teurer Laserdrucker ist. Da müsste man mal schauen, was da tatsächlich verbaut ist. > Java ist da viel zu fett auch mit abgespeckter runtime, völlig andere > Baustelle. Ja es läuft auch auf Smartphones, da hat man aber das > passende Ökosystem drumherum geschaffen und war ne Design und > Strategieentscheidung, das ist mit so Kisten wie Druckern nicht > vergleichbar. Die HW wird immer günstiger.
Nano schrieb: > Für Privatleute könnte relevant sein: > der Netzwerkdrucker > der Switch > der Router <-- laut Heise (https://www.heise.de/news/Roter-Alarm-Log4j-Zero-Day-Luecke-bedroht-Heimanwender-und-Firmen-6292863.html) z.B. "... Ubiquiti, bei Heimanwendern vor allem für seine Meshing-fähigen WLAN Access Points bekannt, bereits eingeräumt, dass das Konfigurations- und Verwaltungs-Frontend UniFi Network Application verwundbar ist .. "
doschi schrieb: > Nano schrieb: >> Für Privatleute könnte relevant sein: >> der Netzwerkdrucker >> der Switch >> der Router <-- > > laut Heise > (https://www.heise.de/news/Roter-Alarm-Log4j-Zero-Day-Luecke-bedroht-Heimanwender-und-Firmen-6292863.html) > z.B. > "... Ubiquiti, bei Heimanwendern vor allem für seine Meshing-fähigen > WLAN Access Points bekannt, bereits eingeräumt, dass das Konfigurations- > und Verwaltungs-Frontend UniFi Network Application verwundbar ist .. " Ok, dann ist dort Java also auch angekommen. Hat der "nano" oben nicht so unrecht.
berufsberatung schrieb: > Dieser Angriff betrifft zu 99% Serveranwendungen und werden meist > isoliert betrieben wo man auch nicht wahllos jede Adresse aufrufen kann. > Da ist idR alles dicht und nur definierte Addressen sind offen. Nuja.. Das beliebte Spiel Minecraft ist auch betroffen. Macht kein Spaß, wenn Sohnemann auf Papas Rechner spielt, und das Microsoft Konto mit ggf. hinterlegter Bezahlfunktion übernimmt.
Nano schrieb: > Mediathekview scheint diese log4j Software auch zu benutzen. Zumindest > gibt es dafür eine XML Datei Namens log4j2 Das muss nix bedeuten. Viele nutzen heute sl4j, das ist so ne Art Frontend für diverse Logger, das sind dann auch entspr. Klassen, Aufrufe, Konfigdateien dabei wo "log4j" auftaucht, es aber nicht genutzt wird. Wenn keine log4j-jars oder davon ausgepackte Klasse gefunden werden, wird das auch nicht verwendet.
update: Das heisst nicht sl4j sondern slf4j java. Das 'f' steht für Facade also halt ne vorgeschaltete Klasse um einheitlich auf den Logger-Zoo dahinter zuzugreifen, also eher mehr ein Adapter.
Nils schrieb: > Nuja.. Das beliebte Spiel Minecraft ist auch betroffen. Macht kein Spaß, > wenn Sohnemann auf Papas Rechner spielt, und das Microsoft Konto mit > ggf. hinterlegter Bezahlfunktion übernimmt. Ups, ja das ist übel und so einfach.
Nano schrieb: > Ausgenommen davon ist vielleicht die Linux Mint Debian Edition (LMDE), > die könnte das Update erhalten haben. Zufällig habe ich gerade einen uralten Laptop da, der im Unterschied zu meinem anderen Rechnern LMDE4 laufen lassen kann. Nach Refresh der Repos zeigt mir Synaptic: liblog4j2-java 2.15.0-1~deb10u1 Die Doku dazu: liblog4j2-java-doc 2.11.1-2 D.h. die Basis war 2.11, aber das eigentliche Paket ist auf 2.15 hochgezogen. Allerdings habe ich mein Reinbooten der LMDE auch bemerkt, daß sie selbst bei ausreichend alter Hardware nicht so problemlos ist wie die Ubuntu-basierte Hauptedition von Mint. Erstmal mit nichtssagenden Fehlermeldungen wegen atomic flip bombardiert worden, als Lösung beim Booten den Kernelparameter video=SVIDEO-1:d mitgegeben, dann ging's. Mint hat 20 auf demselben Rechner keine solche Zicken gemacht.
Nils schrieb: > berufsberatung schrieb: >> Dieser Angriff betrifft zu 99% Serveranwendungen und werden meist >> isoliert betrieben wo man auch nicht wahllos jede Adresse aufrufen kann. >> Da ist idR alles dicht und nur definierte Addressen sind offen. > > Nuja.. Das beliebte Spiel Minecraft ist auch betroffen. Macht kein Spaß, > wenn Sohnemann auf Papas Rechner spielt, und das Microsoft Konto mit > ggf. hinterlegter Bezahlfunktion übernimmt. Es gibt für Windows seit Windows NT 3.1 getrennte Benutzeraccounts. Ab ca. Windows Vista haben die standardmäßig sogar nur eingeschränkte Rechte. Ich kann es absolut nicht nachvollziehen, wenn du das für deinen Sohnemann nicht nutzt. Das ist wie "kein Backup, kein Mitleid."
berufsberatung schrieb: > Nano schrieb: >> Mediathekview scheint diese log4j Software auch zu benutzen. Zumindest >> gibt es dafür eine XML Datei Namens log4j2 > > Das muss nix bedeuten. Viele nutzen heute sl4j, das ist so ne Art > Frontend für diverse Logger, das sind dann auch entspr. Klassen, > Aufrufe, Konfigdateien dabei wo "log4j" auftaucht, es aber nicht genutzt > wird. > > Wenn keine log4j-jars oder davon ausgepackte Klasse gefunden werden, > wird das auch nicht verwendet. Okay, ich habe das jetzt auch nicht näher untersucht. Es war eine einfache Stringsuche.
Nop schrieb: > Zufällig habe ich gerade einen uralten Laptop da, der im Unterschied zu > meinem anderen Rechnern LMDE4 laufen lassen kann. Nach Refresh der Repos > zeigt mir Synaptic: >.. > D.h. die Basis war 2.11, aber das eigentliche Paket ist auf 2.15 > hochgezogen. Das ist dann doch erfreulich für die LMDE User. > Allerdings habe ich mein Reinbooten der LMDE auch bemerkt, daß sie > selbst bei ausreichend alter Hardware nicht so problemlos ist wie die > Ubuntu-basierte Hauptedition von Mint. Erstmal mit nichtssagenden > Fehlermeldungen wegen atomic flip bombardiert worden, als Lösung beim > Booten den Kernelparameter video=SVIDEO-1:d mitgegeben, dann ging's. > Mint hat 20 auf demselben Rechner keine solche Zicken gemacht. LMDE ist noch recht neu und dürfte auch noch nicht so viele Nutzer haben. Die stellen ja erst langsam um. Da kann es dann schon sein, dass es da mehr Ungereimtheiten gibt und ein reines Debian stable ist es durch die Änderungen seitens Mint ja auch nicht mehr.
Die MEMEs sind köstlich: https://github.com/YfryTchsGD/Log4jAttackSurface/blob/master/pages/MEME.md :D Hier gibt's ne Liste zum Thema: https://github.com/YfryTchsGD/Log4jAttackSurface
Nano schrieb: > Das ist dann doch erfreulich für die LMDE User. Ja, und es bringt auch ein wenig Licht in unsere gelegentlichen Diskussionen hier, inwieweit LMDE sich bei den Sicherheitsupdates an Debian anlehnt: ganz direkt. > LMDE ist noch recht neu und dürfte auch noch nicht so viele Nutzer > haben. Naja, neu ist es nicht, LMDE ist ja schon bei Edition 4. Es hat halt nur keine so hohe Prio, was auch erklärt, wieso es immer noch kein LMDE 5 gibt. > Die stellen ja erst langsam um. Derzeit (leider) nicht. LMDE ist immer noch im Status "strategisches Fallback". Aber abgesehen von kleinen Hakeleien konnte ich LMDE4 gerade mal auf einem uralten Core2Duo-Laptop mit 2GB RAM aufsetzen, und es funktioniert. Wird danach eh wieder plattgemacht, weil ich die HDD noch durch eine SSD ersetze, aber war ne gute Gelegenheit, sich LMDE endlich mal live anzuschauen.
Zu der Schwachstelle gibt es diese beiden Artikel, die sie ausführlich erklären: https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/ und https://github.com/mbechler/marshalsec/ Neben Minecraft ist auch Blender betroffen. Und für Android gibt's wohl ein Sicherheitsupdate, allerdings weiß ich jetzt nicht, ob dieses mit dieser Sicherheitslücke zusammenhängt. Die Updatefunktion auf dem Handy ist da leider nicht sehr gesprächig.
Nano schrieb: > Ich kann es absolut nicht nachvollziehen, wenn du das für deinen > Sohnemann nicht nutzt., > Das ist wie "kein Backup, kein Mitleid. Ich hab weder einen Sohnenmann noch kein Backup. Mich betrifft das nicht. Wollte nur darauf hinweisen, das nicht nur Server-Betreiber angreifbar sind.
Nils schrieb: > Nano schrieb: >> Ich kann es absolut nicht nachvollziehen, wenn du das für deinen >> Sohnemann nicht nutzt., >> Das ist wie "kein Backup, kein Mitleid. > > Ich hab weder einen Sohnenmann noch kein Backup. > > Mich betrifft das nicht. > > Wollte nur darauf hinweisen, das nicht nur Server-Betreiber angreifbar > sind. Ach so, okay, dann habe ich das wohl missverstanden. Sry
berufsberatung schrieb: > Ok, dann ist dort Java also auch angekommen. Hat der "nano" oben nicht > so unrecht. Update: Das ist die Verwaltungssoftware die auf dem PC läuft, in den Geräten steckt keine Javasoftware.
berufsberatung schrieb: > berufsberatung schrieb: >> Ok, dann ist dort Java also auch angekommen. Hat der "nano" oben nicht >> so unrecht. > Update: > Das ist die Verwaltungssoftware die auf dem PC läuft, in den Geräten > steckt keine Javasoftware. Lies: https://www.heise.de/forum/heise-online/Kommentare/Warnstufe-Rot-Log4j-Zero-Day-Luecke-bedroht-Heimanwender-und-Firmen/WLAN-ist-nunmal-von-aussen-erreichbar/posting-40132196/show/
Nano schrieb: > Neben Minecraft ist auch Blender betroffen. Recht unwahrscheinlich, das ist C und Python.
Zurück zum eigentlichen Thema: Bisher bekannte betroffene Server + Dienste sind aufgelistet bei (Github) SwitHak/20211210-TLP-WHITE_LOG4J.md: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
Yalu X. schrieb: >> gibt es da schon updates zu . ?? > > Wiese beantwortest du diese Frage nicht einfach selber? Ich bin jetzt doch eher erstaunt über eine derart überflüssige Antwort auf eine ernstgemeinte Frage von Seiten der Moderation. Den aggresiven Grundton hätts auch nicht gebraucht. Da müssen wir uns wohl nicht wundern woher Linux seinen Ruf weg hat.
:
Bearbeitet durch User
Nano schrieb: > Das sehe ich nicht so. > Bei mir wurde es installiert, also wird's eine Anwendung nutzen. Die einzigen Anwendungen die das nutzten könnten wären andere Java Anwendungen die über Debian packages installiert werden. "Richtige" Server Anwendungen kommen immer mit ihren eigenen Abhängigkeiten, sogar IDEs bringen oft ire JRE/JDK mit. log4j ist der de-facto standard fürs logging in Java, ältere SW hat meist noch log4j 1 dabei, dieses ist nicht von diesem Exploit betroffen hat aber andere Problem und ist nicht kompatibel zur V2 (API Änderungen). mit anderen Worten: log4j ist (so gut wie) immer dabei bei Java Anwendungen, das OS packet updaten das es nicht genutzt wird bringt da nix, wenn man sicher gehen will, keine Java Prozesse erlauben. Nano schrieb: > Als Docker, Flatpack, Snap usw. Image ist das sicherlich so. Keiner der Java entwickelt setzt auf Java Bibliotheken die vom OS verwaltet werden, bei JNI ist das was anderes, aber selbst da liefert man das mit aus. Gilt auch für das JRE/JDK selbst. Paketiert sind die halt als WAR (webarchives) oder JAR.
Nano schrieb: > Ausgenommen davon ist vielleicht die Linux Mint Debian Edition (LMDE), > die könnte das Update erhalten haben. Hat sie!
Georg A. schrieb: > Nano schrieb: >> Neben Minecraft ist auch Blender betroffen. > > Recht unwahrscheinlich, das ist C und Python. Du solltest die oben verlinkten Informationen auch mal lesen: https://github.com/YfryTchsGD/Log4jAttackSurface/blob/master/components/Blender/Blender.jpeg
Mladen G. schrieb: > Nano schrieb: >> Das sehe ich nicht so. >> Bei mir wurde es installiert, also wird's eine Anwendung nutzen. > > Die einzigen Anwendungen die das nutzten könnten wären andere Java > Anwendungen die über Debian packages installiert werden. Bei mir besteht die Abhängigkeit zur Mediathekview, ist mir aber nicht so wichtig, weil der Vorteil einer Distribution wie Debian mit ihrem Paketsystem der ist, dass man sich für Details nicht zwingend kümmern muss, das macht die Distribution nämlich selber und nimmt einem diese Arbeit ab. Deswegen sagte ich auch, irgendeine Anwendung wird es nutzen. Da du aber gefragt hast:
1 | apt rdepends liblog4j2-java |
2 | liblog4j2-java |
3 | Reverse Depends: |
4 | Schlägt vor: libnetty-java (>= 2.13.3) |
5 | Hängt ab von: igv |
6 | Hängt ab von: xperia-flashtool |
7 | |Hängt ab von: jabref (>= 2.10.0-2) |
8 | Hängt ab von: mediathekview |
9 | Hängt ab von: libjengelman-shadow-java |
10 | Hängt ab von: jabref (<< 2.10) |
11 | Hängt ab von: libcdk-java (>= 2.11.2) |
12 | Hängt ab von: arduino |
13 | Hängt ab von: libbiojava4.0-java |
14 | Hängt ab von: libbarclay-java |
In meinem Fall brauche ich es für die mediathekview
1 | dpkg --status mediathekview |
2 | Package: mediathekview |
3 | Status: install ok installed |
Und wer die ardunio IDE über das Paketsystem installiert hat, wird ebenfalls das liblog4j2-java Paket installiert bekommen. Die ist bei mir allerdings momentan nicht installiert, ich erwähne es nur, weil das die typische andere Anwendung aus der obigen Liste wäre, die ein Privatanwender bei sich Zuhause installiert haben könnte, wenn er oder seine Kinder mit Arduino spielen. > "Richtige" Server Anwendungen kommen immer mit ihren eigenen > Abhängigkeiten, sogar IDEs bringen oft ire JRE/JDK mit. Bei mir ist Apache aus dem Paketsystem installiert, da ich das lokal für localhost brauche. Die Abhängigkeiten werden über das Paketsystem aufgelöst und die entsprechenden Pakete installiert. Das gleiche gilt für Samba. Es ist also keineswegs so, dass Serveranwendungen immer am Paketsystem vorbei installiert werden und dann ihre Abhängigkeiten natürlich selber mitbringen müssen. Außerdem habe ich oben ja Docker usw. bereits erwähnt. > mit anderen Worten: log4j ist (so gut wie) immer dabei bei Java > Anwendungen, das OS packet updaten das es nicht genutzt wird bringt da > nix, wenn man sicher gehen will, keine Java Prozesse erlauben. Das von der Distri gelieferte Paket wird aber in meinem Fall benutzt und die Anwendung die darauf aufbaut profitiert von dem Sicherheitsfix auch. Siehe oben. > Nano schrieb: >> Als Docker, Flatpack, Snap usw. Image ist das sicherlich so. > > Keiner der Java entwickelt setzt auf Java Bibliotheken die vom OS > verwaltet werden, Wenn die von der Distri mitgelieferte JRE und JDK Version genügt, dann gibt's keinen Grund, die Pakete dafür nicht einzusetzen. Warum willst du dir da unnötig Arbeit aufhalsen? Das macht überhaupt keinen Sinn und kostet nur Zeit. Nur wenn du die neuere Versionen brauchst, die nicht im Repo enthalten sind, hast du wirklich einen Grund, das JRE/JDK am Paketsystem vorbei zu installieren.
Nano schrieb: > Du solltest die oben verlinkten Informationen auch mal lesen: Das ist keine Information, sondern ein Witz von Twitter.
Nano schrieb: > Es ist also keineswegs so, dass Serveranwendungen immer am Paketsystem > vorbei installiert werden und dann ihre Abhängigkeiten natürlich selber > mitbringen müssen. Ja, aber das ist doch nur bei Desktops üblich. Wenn du jetzt noch nachsiehst, was ein sog. "fat jar" ist, dann wird ganz schnell klar dass man log4j V2 in der betroffenen Versionen haben kann, ohne sie auf den ersten Blick zu sehen (die Jars gibt es nicht, die Klassen schon ;) ) Nano schrieb: > Wenn die von der Distri mitgelieferte JRE und JDK Version genügt, dann > gibt's keinen Grund, die Pakete dafür nicht einzusetzen. > Warum willst du dir da unnötig Arbeit aufhalsen? Das macht überhaupt > keinen Sinn und kostet nur Zeit. Das ist total unrealistisch in der Produktion für die meisten Anwendungen. Da kontrolliert man die Anwendung und ihre Umgebung selber als Entwickler, um unnötige Arbeit zu vermeiden. In der Produktion für Cloud SW nimt man sowieso "immutable server", ob das Docker/Packer oder sonst was ist, ist egal, da updated doch keiner einzelne Instanzen, die werden Plattgemacht sobald ein Cluster mit der neuen Version steht. Wie dem auch sei, mit der Suche nach der jar wirst du nicht alle vorkommen finden können (Fat Jar zB.).
:
Bearbeitet durch User
Nop schrieb: > Nano schrieb: > >> Du solltest die oben verlinkten Informationen auch mal lesen: > > Das ist keine Information, sondern ein Witz von Twitter. Hättest du auf der verlinkten Seite mal genau hingeguckt und wärst dort ein paar Ebenen runter gegangen, dann hättest du gemerkt, das es hier um Log4j geht. https://github.com/YfryTchsGD/Log4jAttackSurface/tree/master/components
Nano schrieb: > Hättest du auf der verlinkten Seite mal genau hingeguckt Habe ich, allerdings gründlicher als Du. Hier die ursprüngliche "Quelle": https://twitter.com/chfourchfour/status/1469412054549286928/ Es sollte eigentlich beim dritten Bild klingeln, aber wer auch beim vierten immer noch nicht schaltet, bei dem ist alles zu spät. Das wird auch in den Issues Deiner Quelle schon thematisiert, und letzterer verlinkt den ursprünglichen Tweet: https://github.com/YfryTchsGD/Log4jAttackSurface/issues/20 https://github.com/YfryTchsGD/Log4jAttackSurface/issues/44 Es ist auch völlig offensichtlich, weil Blender gar kein Java verwendet. Wenn Du einfach mal in Deinem Paketmanager nachschaust, welche Abhängigkeiten Blender hat, wirst Du bemerken, daß liblog4j2-java nicht dazu zählt.
Mladen G. schrieb: > Nano schrieb: >> Es ist also keineswegs so, dass Serveranwendungen immer am Paketsystem >> vorbei installiert werden und dann ihre Abhängigkeiten natürlich selber >> mitbringen müssen. > > Ja, aber das ist doch nur bei Desktops üblich. Nein, das ist eben nicht zwingend so. Viele Distributionen werden auf Servern eingesetzt und da wird oft nicht eine extra Version des gewünschten Webservers am Paketsystem vorbei eingesetzt, sondern der aus dem Repository der Distribution installiert. Das hat nämlich den Vorteil, dass man sich den Wartungs- und Pflegeaufwand spart. Dafür sind die Distris nämlich da. Natürlich braucht man da dann eine brauchbare Distri, wo diese Pakete aktiv gepflegt werden. Z.B. RedHat, dafür wir dann auch extra gezahlt. Und selbst Canonical hat hier für Server was im Angebot, dann sollte man sich allerdings auf den main Zweig beschränken. Natürlich gibt's auch Leute, die paketieren dann alles selber zusammen und machen sich den extra Aufwand, aber es ist eben nicht so, dass nur ausschließlich diese Art der Installation angewendet werden würde, wie du irrtümlicherweise hier behauptest. Das kostet nämlich extra Aufwand und der muss dann auch bezahlt werden. Außerdem braucht dieser dann auch kompetentes Personal, die sich um die extra Installationen kümmern. > Wenn du jetzt noch nachsiehst, was ein sog. "fat jar" ist, dann wird > ganz schnell klar dass man log4j V2 in der betroffenen Versionen haben > kann, ohne sie auf den ersten Blick zu sehen (die Jars gibt es nicht, > die Klassen schon ;) ) Brot backt man mithilfe von Mehl, Wasser und Salz.
Nop schrieb: > Nano schrieb: > >> Hättest du auf der verlinkten Seite mal genau hingeguckt > > Habe ich, allerdings gründlicher als Du. Hier die ursprüngliche > "Quelle": https://twitter.com/chfourchfour/status/1469412054549286928/ > Es sollte eigentlich beim dritten Bild klingeln, aber wer auch beim > vierten immer noch nicht schaltet, bei dem ist alles zu spät. > > Das wird auch in den Issues Deiner Quelle schon thematisiert, und > letzterer verlinkt den ursprünglichen Tweet: > https://github.com/YfryTchsGD/Log4jAttackSurface/issues/20 > https://github.com/YfryTchsGD/Log4jAttackSurface/issues/44 Gut, dann hat der Typ Namens "cckuailong" auf github schlichtweg gelogen und immer noch seine Webseite nicht aktualisiert: https://github.com/YfryTchsGD/Log4jAttackSurface/tree/d574fb2861ebf02e0f4ae27c658fae1b1790ae3f Spätestens hier hat man es ihm ja gesagt: https://github.com/YfryTchsGD/Log4jAttackSurface/issues/20 Heise hätte somit auch besser prüfen können, auf welche github Seite man verlinkt. > Es ist auch völlig offensichtlich, weil Blender gar kein Java verwendet. Ich habe kein Blender installiert und Blender erlaubt durchaus die Installation von Zusatzmodulen und da muss nicht jedes auch in einer Distri mitpaketiert sein. Völlig abwegig klang das daher nicht.
Nano schrieb: > Natürlich gibt's auch Leute, die paketieren dann alles selber zusammen > und machen sich den extra Aufwand, aber es ist eben nicht so, dass nur > ausschließlich diese Art der Installation angewendet werden würde, wie > du irrtümlicherweise hier behauptest. Diese Leute arbeiten in der Cloud mit hochskalierbaren Systemen. Die Probleme die man bekommt wenn zwei Anwendungen hat die unterschiedliche und inkompatible Versionen einer Bibliothek brauchen erspart man sich da. Privatanwender hab3en eher das Problem dass sie auf Distros setzen und sich ihre SW von dort installieren. Für mich als Java Entwickler (über 20 Jahre) ist es die Norm meine Abhängigkeiten mitauszuliefern. Viele der Software im Repo ist hoffnungslos veraltet (Eclipse etc.), ist auch egal weil ich mir das alles immer selber installiere, aktuelle Versionen, die haben auch einen Update Mechanismus. Nano schrieb: > Brot backt man mithilfe von Mehl, Wasser und Salz. Vergiss die Hefe nicht sonst wird das ein langweiliger Lappen ;) Ist ja auch egal, worauf ich hinauswill ist dass wenn du dich auf OS Pakete beschränkst, ist die Wahrscheinlichkeit sehr hoch dass andere Java SW das log4j mitbringt, sicher ist man da nur ohne Java Prozesse, und das ist IMO schwer, egal ob privat auf dem Desktop oder in der Produktion in der Cloud, und alles was dazwischen ist. log4j ist wirklich überall im Java Bereich, wenn man Glück hat, V1.
Mladen G. schrieb: > Privatanwender hab3en eher das Problem dass sie auf Distros setzen und > sich ihre SW von dort installieren. > > Für mich als Java Entwickler (über 20 Jahre) ist es die Norm meine > Abhängigkeiten mitauszuliefern. > Viele der Software im Repo ist hoffnungslos veraltet (Eclipse etc.), ist > auch egal weil ich mir das alles immer selber installiere, aktuelle > Versionen, die haben auch einen Update Mechanismus. Wer nur HTML und CSS für seinen Firmenauftritt braucht, braucht das alles nicht. Der kann den Apache oder nginx aus der Distri nehmen und fertig. Und das ist eben kein "nur Privatanweder." Ein Handwerker will auf seinem Webauftritt ne Telefonnummer und ein paar Bilder + Beschreibung seiner Leistungen was er so kann, mehr braucht er in der Regel nicht. Warum sollte er also Apache selber zusammenpacken und separat installieren? > > Nano schrieb: >> Brot backt man mithilfe von Mehl, Wasser und Salz. > > Vergiss die Hefe nicht sonst wird das ein langweiliger Lappen ;) > > Ist ja auch egal, worauf ich hinauswill Nein, du hast einfach am Thema vorbei geredet, damit du etwas zu sagen hast. Das man log4j auch in Jar Pakete packen kann weiß ich auch und steht übrigens auch oben im Thread, d.h. wissen wir alle. Hier ging es aber um die Pakete der Distributionen, fertig. Also was soll das mit deinem Einwand? Wir: Diskussion über rote Autos und welchen Motor man jetzt nimmt. Ich: Okay, ich nehme jetzt das rote Auto mit dem Benzinmotor. Du: Stimmt nicht! Es gibt auch grüne, rote und blaue Autos. Ja wissen wir, was soll das jetzt? Also dummes Gelaber von deiner Seite. Du hast im Prinzip nichts gesagt, was hier irgendwie von Relevanz wäre und niemand wüsste. > ist dass wenn du dich auf OS > Pakete beschränkst, ist die Wahrscheinlichkeit sehr hoch dass andere > Java SW das log4j mitbringt, Wenn ich mich auf OS Pakete beschränke, dann habe ich auch nur OS Pakete installiert. > sicher ist man da nur ohne Java Prozesse, Wenn du etwas am Paketsystem vorbei installierst, dann musst du dich um die Sicherheit selber kümmern. Das ist allgemein bekannt und wissen wir alle hier schon lange. Also völlig windschief deine ganze Diskussion.
>> sicher ist man da nur ohne Java Prozesse, > > Wenn du etwas am Paketsystem vorbei installierst, dann musst du dich um > die Sicherheit selber kümmern. Das ist allgemein bekannt und wissen wir > alle hier schon lange. > Also völlig windschief deine ganze Diskussion. Und noch etwas. Und das gilt nicht nur für Java Prozesse, sondern für jede Software, egal womit die programmiert wurde. Wenn du eine Software, die in C programmiert wurde, am Paketsystem vorbei installierst und die eine Sicherheitslücke enthält, dann musst du dich auch um diese kümmern. Das Problem ist also keineswegs auf Java begrenzt.
Nano schrieb: > Gut, dann hat der Typ Namens "cckuailong" auf github schlichtweg gelogen Das ist zu hart - er ist auf den Witz reingefallen, weil er wahrscheinlich nur eine Sekundärquelle vorliegen hatte, wo nur der Fake-Screenshot von Blender zu sehen war und nicht der Rest des Witzes. > und immer noch seine Webseite nicht aktualisiert: Das kann man ihm in der Tat vorwerfen.
Nano schrieb: > Ein Handwerker will auf seinem Webauftritt ne Telefonnummer und ein paar > Bilder + Beschreibung seiner Leistungen was er so kann, mehr braucht er > in der Regel nicht. > > Warum sollte er also Apache selber zusammenpacken und separat > installieren? Weil die Handwerker auf der Seite auch ein Kontakt-Formular haben wollen. Und dazu brauch mal i.d.R. Java.
Schlaumaier schrieb: > Weil die Handwerker auf der Seite auch ein Kontakt-Formular haben > wollen. > Und dazu brauch mal i.d.R. Java. Blödsinn.
Schlaumaier schrieb: > Nano schrieb: >> Ein Handwerker will auf seinem Webauftritt ne Telefonnummer und ein paar >> Bilder + Beschreibung seiner Leistungen was er so kann, mehr braucht er >> in der Regel nicht. >> >> Warum sollte er also Apache selber zusammenpacken und separat >> installieren? > > Weil die Handwerker auf der Seite auch ein Kontakt-Formular haben > wollen. > Und dazu brauch mal i.d.R. Java. Ich schrieb: .. mehr braucht er in der Regel nicht. Man achte auf das "in der Regel". Es steht dem Handwerker natürlich frei, noch viel mehr einzubauen, inkl. Videos und 3d Animationen wie er arbeitet, aber das ist dann alles schon außerhalb von "in der Regel". Und PHP oder gar ein GI-Skript in beliebiger dafür brauchbarer Sprache reicht für ein Kontaktformular auch, dafür braucht man nicht zwingend Java.
Nano schrieb: > Und PHP oder gar ein GI-Skript in beliebiger dafür brauchbarer Sprache Studien haben übrigens belegt, daß die überwiegende Zahl der PHP-Scripte in PHP geschrieben sind.
Nop schrieb: > Nano schrieb: > >> Und PHP oder gar ein GI-Skript in beliebiger dafür brauchbarer Sprache > > Studien haben übrigens belegt, daß die überwiegende Zahl der PHP-Scripte > in PHP geschrieben sind. Ich bezog mich auf CGI Skripte, die kann man auch in C und sonstwas schreiben. Für PHP nimmt man in der Regel das entsprechende PHP Module für den Webserver.
Übrigens, so ist die Lücke entstanden: https://issues.apache.org/jira/browse/LOG4J2-313 Von einem (Nord?) Koreaner Namens Woonsan Ko. Zuerst hat er nach einem Feature gefragt und ein paar Stunden später hat er einen passenden diff patch geliefert, das seinen Wunsch erfüllt. Und der wurde dann vom Nutzer Namens Ralph Goers akzeptiert, abgenickt und in den Code commited. Ab da, also dem 18 Juli 2013, war der Schadcode dann platziert und drin.
Nano schrieb: > Von einem (Nord?) Koreaner Namens Woonsan Ko. > Zuerst hat er nach einem Feature gefragt und ein paar Stunden später hat > er einen passenden diff patch geliefert, das seinen Wunsch erfüllt. Woonsan Ko ist unter anderem Apache-PMC-Mitglied und arbeitet in Boston. Du kannst Deine Verschwörungsgedanken über nordkoreanische Spione also wieder einpacken. Nano schrieb: > Ab da, also dem 18 Juli 2013, war der Schadcode dann platziert und drin. Da kann man nur hoffen, dass das nicht schon seit Jahren ausgenutzt wird. Aber zumindest automatische Scans mit entsprechendem User-Agent gab es vorher nicht, ich hatte den ersten Einschlag am Freitag kurz nach 14:00. Übrigens aus dem erwarteten Land (nicht Nordkorea).
Nano schrieb: > Für PHP nimmt man in der Regel das entsprechende PHP Module für den > Webserver. In Red Hat 7 wurde 2014 PHP 5.4 eingefroren. Das wird von Red Hat selbst zwar bis 2024 mit kritischen Fixes versehen, aber Anwendungen im Webserver wie Wordpress (keine Kommentare bitte ;-) benötigen längst frischeres PHP. Es kann also nötig sein, das zu trennen, will man das Grundsystem nicht stets hinterherziehen.
:
Bearbeitet durch User
Hmmm schrieb: > Nano schrieb: >> Von einem (Nord?) Koreaner Namens Woonsan Ko. >> Zuerst hat er nach einem Feature gefragt und ein paar Stunden später hat >> er einen passenden diff patch geliefert, das seinen Wunsch erfüllt. > > Woonsan Ko ist unter anderem Apache-PMC-Mitglied und arbeitet in Boston. > Du kannst Deine Verschwörungsgedanken über nordkoreanische Spione also > wieder einpacken. Ein Spion würde auch erst einmal Vertrauen schaffen, in dem er für Monate zuerst sauberen Code liefert, bis genug Vertrauen da ist und niemand mehr richtig hinguckt. Und wenn's dann Jahre später rauskommt, kann man es als Fehler abtun und abstreiten, man hat ja zuvor immer gute Arbeit geliefert. Ist in der Wikipedia doch auch nicht anders. Wenn du da als IP was reinstellst, ist da jeder gleich misstrauisch und guckt ganz genau hin. Hast du dir nen Namen gemacht, wird der Edit oft abgenickt. Im Prinzip nennt man diesen Schritt auch Social Engineering Angriff. Insofern liegst du im Irrtum. Das muss keine Verschwörung sein. Und was den Ort betrifft, Nordkoreanische Spione sind in der ganzen Welt aktiv. Es ist sogar so, dass man bei den Überläufern ganz genau hinschauen muss, weil auch unter diesen ein Spion sein könnte und auch sind. Wie sich bspw. auf andere Weise bereits herausgestellt hat: https://www.youtube.com/watch?v=JMr83agVQjc Zumal, wie sollte ein Open Source Projekt das auch überprüfen? Und nein, ich sage nicht dass es wirklich so war, ich wollte es nur mal erwähnen dass es möglich sein könnte. > > Nano schrieb: >> Ab da, also dem 18 Juli 2013, war der Schadcode dann platziert und drin. > > Da kann man nur hoffen, dass das nicht schon seit Jahren ausgenutzt > wird. Wenn das absichtlich platziert worden sein sollte, was ja durchaus möglich ist, wurde das sicherlich ausgenutzt.
Noch etwas. Unsere Bundesregierung plant laut Koalitionsvertrag ja nun in den Behörden mehr auf Open Source zu setzen. Eine Entscheidung, die ich im Prinzip gut finde. Hoffentlich wird da aber auch ein umfangreicher Code Audit eingeplant, für jeden Code, der auf den Behördenrechnen laufen soll. D.h. man sollte, wenn man das richtig umsetzen will, da nicht einfach irgendeine Distribution nehmen, sondern gezielt nur die allernötigste Software raussuchen und dann aus dieser eine eigene Distribution erstellen und jede Codezeile einem Code Audit unterstellen. Nur so wäre wirkliche Sicherheit möglich. Und damit das nicht zu viel Aufwand ist, muss man sich auf das nötigste beschränken. Heartbleed und dieser Log4j Bug haben nämlich deutlich gezeigt, dass dies mehr als nötig ist. Ich weiß allerdings nicht, wie man das bezahlen soll. Da sollte man dann schon Geld in die Hand nehmen und die Personen, die den Code Audit machen, gründlich untersuchen, als würden sie sich beim BND oder MAD bewerben.
Nano schrieb: > Hoffentlich wird da aber auch ein umfangreicher Code Audit eingeplant, > für jeden Code, der auf den Behördenrechnen laufen soll. Vergiß es, das ist gar nicht zu leisten. Allein der Kernel hat doch schon 30 Millionen Codezeilen, und dann stehen die Projekte selber ja auch nicht still.
Nano schrieb: > Insofern liegst du im Irrtum. Das muss keine Verschwörung sein. > Und was den Ort betrifft, Nordkoreanische Spione sind in der ganzen Welt > aktiv. Hast Du beim peinlichen Debian-OpenSSL-Bug vor >10 Jahren auch solche Theorien geäussert, oder war das für Dich als Debian-Fan undenkbar? Nano schrieb: > Es ist sogar so, dass man bei den Überläufern ganz genau > hinschauen muss, weil auch unter diesen ein Spion sein könnte und auch > sind. Auch ohne seine Geburtsurkunde gesehen zu haben, würde ich stark annehmen, dass er bzw. seine Familie nicht aus Nord-, sondern aus Südkorea stammt. Nano schrieb: > Zumal, wie sollte ein Open Source Projekt das auch überprüfen? Das Schöne an Open Source ist, dass theoretisch jeder reingucken und Fehler bemerken kann. Dummerweise wird das oft nicht (oder nur halbherzig) getan, obwohl gerade in Situationen wie dieser (Verarbeitung von potentiell ungefiltertem Input) erhöhte Vorsicht angebracht gewesen wäre. Aber die IT-Geschichte ist voll von solchen Bugs, siehe ungefilterte Environment-Variablen im telnetd, Directory Traversal Bugs, SQL Injections etc. Und auf die Gefahr hin, gleich gesteinigt zu werden: Bei Java-Leuten kommt noch dazu, dass man statt des KISS-Prinzips gerne gigantische Libraries einbindet, obwohl man mit ein paar Zeilen eigenem Code dasselbe erreicht hätte.
Hmmm schrieb: > Auch ohne seine Geburtsurkunde gesehen zu haben, würde ich stark > annehmen, dass er bzw. seine Familie nicht aus Nord-, sondern aus > Südkorea stammt. Südkorea ist doch in Wahrheit ein Fake der Nordkoreaner - sowas wie Bielefeld in nationalem Maßstab.
Nun hackt man nicht auf den armen Kerl herum. Es liegt doch an Hmmm schrieb: > Das Schöne an Open Source ist, dass theoretisch jeder reingucken und > Fehler bemerken kann. Dummerweise wird das oft nicht (oder nur > halbherzig) getan, Was in den Fall bedeutet, nicht der der es entwickelt hat, ist der schuldige sonder der der es unkontrolliert durchgewunken hat. Ich mag Leute die Heiligenscheine predigen und Hörner haben. ;)
Nop schrieb: > Nano schrieb: > >> Hoffentlich wird da aber auch ein umfangreicher Code Audit eingeplant, >> für jeden Code, der auf den Behördenrechnen laufen soll. > > Vergiß es, das ist gar nicht zu leisten. Allein der Kernel hat doch > schon 30 Millionen Codezeilen, und dann stehen die Projekte selber ja > auch nicht still. Man kann die Hardware eingrenzen, dann kann man die ganzen Treibermodule, die man nicht braucht aus dem modifizierten Kernelcode rausschmeißen und schon ist der Code deutlich kleiner. Dass die Projekte nicht still stehen, ist korrekt. Da muss man dann halt stabilen und auditen Freeze machen, Sicherheitspatches zurückportieren und in einem weiteren Zweig die Neuerungen mitmachen und auditen.
Hmmm schrieb: > Nano schrieb: >> Insofern liegst du im Irrtum. Das muss keine Verschwörung sein. >> Und was den Ort betrifft, Nordkoreanische Spione sind in der ganzen Welt >> aktiv. > > Hast Du beim peinlichen Debian-OpenSSL-Bug vor >10 Jahren auch solche > Theorien geäussert, oder war das für Dich als Debian-Fan undenkbar?# Du hast bereits beweisen, dass du für Social Engineering anfällig bist. Finde dich also damit ab. Und damals habe ich übrigens noch kein Debian benutzt und ja, das war ein großes Problem. > Nano schrieb: >> Es ist sogar so, dass man bei den Überläufern ganz genau >> hinschauen muss, weil auch unter diesen ein Spion sein könnte und auch >> sind. > > Auch ohne seine Geburtsurkunde gesehen zu haben, würde ich stark > annehmen, dass er bzw. seine Familie nicht aus Nord-, sondern aus > Südkorea stammt. Der Name ist Koreanisch. Und auch für Überläufer ist es möglich, die amerikanische Staatsbürgerschaft zu erhalten. Siehe der Link zum Video. Die Frau dieses Kanals hat diese vor ein paar Tagen erst erhalten und war ein Überläufer. > Nano schrieb: >> Zumal, wie sollte ein Open Source Projekt das auch überprüfen? > > Das Schöne an Open Source ist, dass theoretisch jeder reingucken und > Fehler bemerken kann. Du hast gar nicht verstanden, was ich geschrieben habe. Nochmal, für dich verständlich: Wie soll ein Open Source Projekt Personen und ihre Identität und wahre Herkunft überprüfen? Das ist für ein Open Source unmöglich, das kann nur ein Staat leisten!
Nano schrieb: > Und damals habe ich übrigens noch kein Debian benutzt und ja, das war > ein großes Problem. Nicht falsch verstehen, das Problem bezieht sich auf den OpenSSL Bug.
Nano schrieb: > Man kann die Hardware eingrenzen, dann kann man die ganzen > Treibermodule, die man nicht braucht aus dem modifizierten Kernelcode > rausschmeißen und schon ist der Code deutlich kleiner. Das sind immer noch über 10 Millionen Zeilen nur für den Kernel, und dann daraus auch noch nen Staatskernel zusammenbacken... das wird nichts. Schlimmstenfalls übrigens 16 Staatskernel, dank Föderalismus. Dasselbe natürlich nochmal für die Anwendungen. Dazu kommt, daß solche Staatsposten nach allem möglichen besetzt werden, nur nicht nach Qualifikation. Am Ende stehen dann nur Milliarden an verbrannten Steuergeldern ohne funktionierende Systeme. Nee, die sollen sich ne solide Distro als Basis hernehmen und darauf aufsetzen.
Nano schrieb: > sondern gezielt nur die allernötigste > Software raussuchen und dann aus dieser eine eigene Distribution > erstellen und jede Codezeile einem Code Audit unterstellen. Oh, super, nicht nochmal... Dann wird also ein Codestand genommen, ca. 6 Monate (mal wild geraten) geprüft, und dieser dann für die kommenden n Jahre verwendet, damit es sich auch lohnt. Das bedeutet: Ein neuer Sicherheitsstandard X (z.B. TLS 1.4) kann dann nicht verwendet werden, weil es den damals bei der Prüfung noch nicht gab. Oder glaubst Du, es ist Geld da, dass so ein wird in kürzeren Zeitabständen wiederholt wird?
Nano schrieb: > Du hast bereits beweisen, dass du für Social Engineering anfällig bist. > Finde dich also damit ab. Du bist gut. Leider nur darin, Blödsinn zu reden und dabei (Deiner Meinung nach) schlau rüberzukommen. Nano schrieb: > Und damals habe ich übrigens noch kein Debian benutzt und ja, das war > ein großes Problem. Zweifellos, aber hegst Du da keinen Spionageverdacht? Falls zutreffend, warum nicht? Nano schrieb: > Nochmal, für dich verständlich: > Wie soll ein Open Source Projekt Personen und ihre Identität und wahre > Herkunft überprüfen? Wen interessiert die Herkunft? Interessant ist der Code, nur der muss geprüft werden. Und zwar nicht primär wegen Deiner Nerd-Spionage-Phantasien, sondern weil Menschen dazu neigen, Fehler zu machen. Nop schrieb: > Nee, die sollen sich ne solide Distro als Basis hernehmen und darauf > aufsetzen. Und in den Anwendungen dann das KISS-Prinzip anwenden. Niemand braucht die eierlegende Wollmilchsau des Loggings, um ein Textfile zu schreiben.
Nop schrieb: > Nano schrieb: > >> Man kann die Hardware eingrenzen, dann kann man die ganzen >> Treibermodule, die man nicht braucht aus dem modifizierten Kernelcode >> rausschmeißen und schon ist der Code deutlich kleiner. > > Das sind immer noch über 10 Millionen Zeilen nur für den Kernel, und > dann daraus auch noch nen Staatskernel zusammenbacken... das wird > nichts. Schlimmstenfalls übrigens 16 Staatskernel, dank Föderalismus. > Dasselbe natürlich nochmal für die Anwendungen. Den Kernel muss man nicht zusammenbacken. Die Treibermodule sind ja jetzt nicht mit dem Rest so zusammengewachsen, dass man das nicht leicht trennen könne. 10 Mio Zeilen, ja, vielleicht. Da muss man dann durch. Man braucht halt ein großes Team und muss da dann durch. Immerhin geht es um die nationale digitale Infrastruktur und damit um die nationale Sicherheit. Föderalismus wird dafür ausgeschlossen. Damit muss man dann halt leben. Aber, wenn ich mich nicht irre, ist das ohnehin schon jetzt der Gedanke bei der geplanten Umstellung auf Open Source Software, damit da nicht jedes Bundesland sein eigenes Süppchen kocht und es wieder nicht harmoniert. > Dazu kommt, daß solche Staatsposten nach allem möglichen besetzt werden, > nur nicht nach Qualifikation. Am Ende stehen dann nur Milliarden an > verbrannten Steuergeldern ohne funktionierende Systeme. Um das zu verhindern braucht man ein größeres Gehalt, idealerweise als Bonus für entsprechende IT Spezialisten, dann kriegt man auch die entsprechenden Leute. Qualifikation kriegt man, in dem man 2 oder besser 3 Teams bildet und die alle den gleichen Code auditen lässt. Was im Angebracht der Sicherheitsfrage ohnehin notwendig wäre. Ja, das vervielfacht die Kosten, ist aber nötig. Denn so findet man recht schnell die, die Sicherheitslücken nicht finden und kann sie entweder nachschulen oder durch bessere Leute ersetzen. Außerdem hat man dann wirklich ein Mehraugenprinzip, auch beim Audit. Außerdem würde man so auch solche Leute loswerden, die die Sicherheitslücken absichtlich nicht finden wollen, schlechte Arbeit dürfte statistisch betrachtet dann durchaus auffallen. Leute die gegen den Staat arbeiten kann man nämlich nicht ausschließen. Dieses Szenario muss auch bedacht werden. > Nee, die sollen sich ne solide Distro als Basis hernehmen und darauf > aufsetzen. Dann nimmst du aber gerade solche möglicherweise absichtlich platzierten Sicherheitslücken wie heartbleet und log4j in Kauf und der Staat ist dann bei höchstkritischen Systemen dann anfällig gegenüber feindlichen Ländern. Im V-Fall wäre das Fatal, bei einem Wirtschaftskrieg auch. Und im Prinzip aber auch sonst, wenn der "Feind" alles mitlesen kann. Beachte, ich rede hier nicht nur bloß von irgendnem Rathauscomputer, sondern von einem System, das überall eingesetzt werden soll. Also auch im Kanzleramt und Behörden wie dem MAD und BND. Also wo die höchste Sicherheitstufe gelten soll. Da kannst du nicht einfach irgendeine Wald und Wiesen Distri nehmen, nicht einmal Redhat. Da musst du den Code zwingend auditen. Und deswegen musst du bei 10 Mio Kernelcodezeilen da dann halt auch durch. Und die Software muss eingeschränkt werden. D.h. dann bspw. X.org fliegt raus und Wayland wird audited. Das gleiche gilt für die vielen Desktop Environments und WM, da nimmt man nur eines, das der Aufgabe gewachsen ist und audited das, der Rest fliegt raus. Unternehmen, die dann für den Staat Software entwickeln sollen. Im Koalitionsvertrag steht ja bereits drin, dass für den Staat entwickelte Software als Open Source veröffentlicht werden soll, können dann dieses auditete System downloaden und darauf basierend dann ihre Anwendung entwerfen. Die können dann also nicht frei wählen, ob sie Qt, gtk, fltk, wxwidget und sonstiges als Gui Toolkit nehmen, sondern die müssen dann das nehmen, was da dann benutzt wird bzw. vorhanden ist.
Achim H. schrieb: > Nano schrieb: >> sondern gezielt nur die allernötigste >> Software raussuchen und dann aus dieser eine eigene Distribution >> erstellen und jede Codezeile einem Code Audit unterstellen. > > Oh, super, nicht nochmal... Dann wird also ein Codestand genommen, ca. 6 > Monate (mal wild geraten) geprüft, und dieser dann für die kommenden n > Jahre verwendet, damit es sich auch lohnt. > > Das bedeutet: Ein neuer Sicherheitsstandard X (z.B. TLS 1.4) kann dann > nicht verwendet werden, weil es den damals bei der Prüfung noch nicht > gab. > > Oder glaubst Du, es ist Geld da, dass so ein wird in kürzeren > Zeitabständen wiederholt wird? Rückportieren sind möglich. Das sagte ich ja oben. TLS 1.4 ist ja jetzt nur ein kleiner Baustein, das sollte man problemlos rückportieren können.
Hmmm schrieb: > Nano schrieb: >> Du hast bereits beweisen, dass du für Social Engineering anfällig bist. >> Finde dich also damit ab. > > Du bist gut. Leider nur darin, Blödsinn zu reden und dabei (Deiner > Meinung nach) schlau rüberzukommen. Social Engineering ist eben kein Blödsinn, sondern in der Praxis bereits längst umgesetzter Fakt! Der Fehler liegt an dir, du redest Unsinn, nicht ich. > Nano schrieb: >> Nochmal, für dich verständlich: >> Wie soll ein Open Source Projekt Personen und ihre Identität und wahre >> Herkunft überprüfen? > > Wen interessiert die Herkunft? Interessant ist der Code, nur der muss > geprüft werden. Und zwar nicht primär wegen Deiner > Nerd-Spionage-Phantasien, sondern weil Menschen dazu neigen, Fehler zu > machen. Zum Überprüfen brauchst du aber Personen, denen du vertrauen kannst. Also ist es eben nicht egal, wen du da nimmst.
Nano schrieb: > Zum Überprüfen brauchst du aber Personen, denen du vertrauen kannst. > Also ist es eben nicht egal, wen du da nimmst. Wenigstens können die Auditoren in Ruhe und unüberwacht arbeiten, nicht so wie bei MS: https://heise.de/-2678517 Besonders interessant: Die Auditoren dürfen nur von MS freigegebe Tools zum Prüfen verwenden, und eine Garantie dass der untersuchte Quelltext den Binaries auf dem Installationsmedium entspricht gibt's auch nicht. Ich denke unter solchen Bedingungen ist ein Linux-Audit viel billiger durchzuführen.
:
Bearbeitet durch User
Nano schrieb: > Social Engineering ist eben kein Blödsinn, sondern in der Praxis bereits > längst umgesetzter Fakt! Erzähl mal was Neues. Es ging aber um Deine haltlose Unterstellung, ich wäre anfällig dafür, weil ich Deinen rassistisch angehauchten Gedankengang (koreanischer Name -> Nordkorea -> Spionage) idiotisch finde. Dass das Debian-Projekt seinerzeit ausgerechnet eine Kryptographie-Library unbrauchbar gemacht hat, scheint nicht Dein Misstrauen geweckt zu haben, zumindest drückst Du Dich vor einer eindeutigen Antwort. Nano schrieb: > Zum Überprüfen brauchst du aber Personen, denen du vertrauen kannst. > Also ist es eben nicht egal, wen du da nimmst. Dann solltest Du vielleicht eher denjenigen durch die Blume verdächtigen, der den Patch angenommen hat.
Beitrag #6909248 wurde von einem Moderator gelöscht.
Betrifft das eigentlich auch Eclipse? Insbesonders TI CodeComposerStudio und ST CUBE MX?
Nano schrieb: > Ich habe kein Blender installiert und Blender erlaubt durchaus die > Installation von Zusatzmodulen und da muss nicht jedes auch in einer > Distri mitpaketiert sein. > Völlig abwegig klang das daher nicht. Also keine Ahnung von Blender aber mitreden? Es gibt keine Schnittstelle von der Blender-Modul-API zu Java. Wozu auch, das macht ja Python. Und selbst wenn irgendwer mal so einen Wrapper geschrieben hätte, wäre das schon ohne log4j-Nutzung ein regenbogenfarbiges Einhorn, das schon gar nicht in der Standardinstallation mit den 100 DefaultAddons dabei ist. Ich habe meinen Defaultcube jedenfalls jetzt nach dem Escape in dem Bild benannt und das steht jetzt so völlig unexpandiert an allen Orten in Blender ;)
hat nicht jemand schon mal Minecraft angesprochen, irgendetwas mit fiktivem Sohn? -> https://www.borncity.com/blog/2021/12/14/log4j-schwachstelle-cve-2021-44228-minecraft-dringend-patchen/
Kleiner Hinweis an Arduino-IDE-Nutzer. In der aktuellen "arduino-nightly-windows" Version (Stand der Datei : 13.12.2021) ist die "log4j-api-2.15.0.jar" lib drin. Und die sollte den Fehler beheben. ;) Hoffe ich zumindest.
Ubuntu und somit auch das nicht-LMDE-Mint haben den Patch auch ausgerollt.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.