FHEM (Komponenten oder Module) betroffen von log4j Sicherheitslücke?

[r00t2]

Hallo zusammen,

ich habe zwei kurze Fragen zu obigem Thema:
1) In welcher Form ist FHEM (ggf. sogar unabhängig vom verwendeten OS-Unterbau) betroffen von der aktuellen log4j Sicherheitslücke?

2) Ist bekannt, welche Drittanbieter/Hersteller alle davon betroffen sein können und deren Produkte wir ggf. über Gateways, Module oder andere Protokolle in FHEM integriert haben?

Beim Suchen des Begriffs durch das Board sind doch einige Treffer aufgekommen, in der die Bibliothek scheinbar genutzt wird (allerdings öfters bei eingebundenen Modulen, hauptsächlich in Apache).

Danke für eine Antwort.
Gruß root2

[rudolfkoenig]

FHEM selbst ist davon nicht betroffen.

Allerdings kommuniziert FHEM mit etlichen Diensten in der Cloud oder mit diversen Routern, Staubsaugern, etc, die wiederum selbst betroffen sein koennten.

Dass der HTTP-Server Apache davon betroffen waere, ist mir neu. Bitte diesen Server nicht verwechseln mit den vielen anderen, von dem Apache Software Foundation betreuten/finanzierten Projekten, die sehr wohl betroffen sein koennen.

[r00t2]

Danke für die schnelle Antwort!

... Dass der HTTP-Server Apache davon betroffen waere, ist mir neu. Bitte diesen Server nicht verwechseln mit den vielen anderen, von dem Apache Software Foundation betreuten/finanzierten Projekten, die sehr wohl betroffen sein koennen.

Ich hatte ja auch nirgends den Apache HTTP Server erwähnt

Aber Debian hat z. B. das Paket für apache-log4j2 mit einem Sicherheitspatch versorgt.

Denke, hier im Forum ist es in Verbindung mit S.E.P.I.A. und selbst-gehosteter Alexa Sprachsteuerung mal zum Tragen gekommen.

[rob]

Heise.de verweist u.a. auf diese Liste von Betroffenheiten: https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
Im FHEM-Umfeld wird ja, wie oben schon geschrieben, alles mögliche eingesetzt. Ich denke da auch an diverse Docker-Geschichten, indirekt eine Auswirkung möglich wäre. Docker selbst und OpenHAB seien z.B. betroffen und div. Cloudkrams auch.
Kann nicht schaden bei sich selbst kritisch zu schauen, was man da so laufen hat mit Log4Bash /Log4J ähnlichen Mechanismen  Als Anwender kann man eh nur auf Patches warten.

Quelle: https://www.heise.de/ratgeber/Schutz-vor-schwerwiegender-Log4j-Luecke-was-jetzt-hilft-und-was-nicht-6292961.html

VG
rob

[Wernieman]

Auch bei Docker ist es nicht Docker selber, sondern ein mögliches Zusatzmodul "docker scan". Solange man das Scan-Modul nicht aktiviert hat, ist docker selber nicht betroffen. Das Docker trotzdem ein Update erhalten hat, ist dabei positiv.

Musste das Thema gestern schon beruflich durchkauen ....

[curt]

Allerdings kommuniziert FHEM mit [...] diversen Routern, Staubsaugern, etc, die wiederum selbst betroffen sein koennten.

So lange deren WebInterfaces nicht aus dem Internet erreichbar ist, sehe ich da keinen Angriffsvektor.

[Wernieman]

Sehe ich etwas kurz ... da sich meistens ein PC mit Browser im gleichen Netz befinden. Ich stimme Dir nur zu, das man deswegen aktuell nicht in Hektik verfallen sollte, solange es "lohnendere" Angriffsziele gibt. Längerfristig (hoffentlich erst in wenigen Monaten) sieht es dagegen anders aus ...

[rudolfkoenig]

Es kann zu Problemen fuehren, wenn FHEM einem betroffenen Geraet infizierte Daten weitergibt.
Meines Wissens muss das betroffene Geraet keinen Internet-Zugriff wg. Code-Nachladen haben, weil die Daten auch Bytecode enthalten koennen.

[curt]

Es kann zu Problemen fuehren, wenn FHEM einem betroffenen Geraet infizierte Daten weitergibt.

Ich sehe nur nicht, wo FHEM die her haben könnte. Hast Du da ein Szenario vor Auge? Mir fällt im Moment keins ein.

(Ich finde es richtig, dass wir derartige Probleme diskutieren. Und ich will die überhaupt nicht klein reden.)

[rudolfkoenig]

Hmmm...
Mir fallen gerade nur unplausible Szenarien ein.
Offensichtlich bin ich ein schlechter Einbrecher.
Aber theoretisch...

[curt]

Doch - ein Szenario würde mir einfallen. Aber ich muss da ausholen.

Nun bin ich noch die Coder-Generation, die prozedural denkt und mit Klassen, Vererbung und dem ganzen Gedöhns nichts am Hut hat - und eigentlich in dem Alter ist, dass man programmieren lässt. Aber folgendes habe ich aus verschiedenen Veröffentlichungen/Diskussionen ger.ct, Köhntopp[¹] et al verstanden:

Da werden (zunächst spezifikationsgemäß) Klassen aus dem Internet nachgeladen. Dieses kann man via http/GET triggern, das ist schon weniger konzeptgemäß.

Als Szenario stellen wir uns WLAN-Glühbirnen, also Leuchtmittel vor, die verschiedene Farben annehmen und der Entwickler löste das in der Glühbirne mit Java. Und weil alle das so machen, hat er auch Logging vermittels log4j eingebaut. Klingt unwahrscheinlich, aber wen würde sowas wundern?

Nun kommt eine Glühbirne auf die Idee (ja, alles an den Haaren herbeigezogen) nach Hause zu telefonieren - das traute ausländische Heim hat sich aber grad selbst via log4j was eingetreten - und schiebt den genau gleichen Angriffsvektor zur Glühbirne. Das log4j der Glühbirne interpretiert - und legt los. Ja - was eigentlich?

Die kompromittierte Glühbirne wird sich wohl alle lokalen WebServer suchen und den Angriffsvektor abschießen. So weit - so schlecht. In diesem Szenario kommt die Glühbirne aber nicht über das eigene Netzsegment, wir haben schlauerweise segmentiert, wir haben auch mehrere Wlan.

Endlich komme ich zu der Frage, ob FHEM vielleicht doch nutzbar ist. Denn FHEM nutzt (zumindest bei mir) Informationen, die aus unterschiedlichen Netzsegmenten kommen.

Kritisch wäre also, wenn FHEM direkt oder indirekt Proxy zwischen verschiedenen Geräten in verschiedenen Netzsegmenten spielt. Dabei dürfte eine reine Filterung als Lösung ausscheiden, siehe [²].

[¹] https://heise.de/-6294476
[²] https://heise.de/-6292961

[Wernieman]

Du must es "nur" schaffen, den "Angriffsstring" zur Glühbirne zu schicken. Aber wenn Du soweit bist, das Du FHEM bringen kannst, beliebige Strings zu schicken, hast Du noch ganz andere Möglichkeiten ..

[rob]

Unerbetene Nachrichten via Telegram, E-Mail, abgefragte Websites (httpmod), "komische" Strings in MQTT-Sendern, Anrufer-CID oder Gerätenamen von (Gast-)Smartphones usw. sind hoffentlich kein Problem. Ich möchte es nicht herbeisehnen, aber wenigstens drüber nachgedacht haben

[Wernieman]

Zustimmung!