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.
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?
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.
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. ;(
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
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..
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):
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/
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.
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.
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.
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.
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.
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.
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.
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:> 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.).
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/20https://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.
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:> 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.
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.
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.
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 ;)
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.
Thread beobachten
Seitenaufteilung abschalten