Monatsrückblick Januar/Februar 2026 ist online!

[A Former User]

@thomas-braun

Der Anstieg ist irre ! Vielen dank fuer den Hinweis!

[Homoran]

@thomas-braun sagte in 0.0.0.0 Day - Schwere Lücke:

Der ioBroker (bzw. Adapter) reißt ja einige Dienste auf 0.0.0.0 auf.

wäre es denn bei diesen Adaptern möglich 0.0.0.0 gegen definierte IPs zu ersetzen?

Frage geht natürlich auch an @devs

[Thomas Braun]

@homoran

Kann ich nichts zu sagen. So tief blicke ich da auch nicht rein.

[Homoran]

@thomas-braun deswegen der Nachsatz

[Feuersturm]

@homoran sagte in 0.0.0.0 Day - Schwere Lücke:

@thomas-braun sagte in 0.0.0.0 Day - Schwere Lücke:

Der ioBroker (bzw. Adapter) reißt ja einige Dienste auf 0.0.0.0 auf.

wäre es denn bei diesen Adaptern möglich 0.0.0.0 gegen definierte IPs zu ersetzen?

Frage geht natürlich auch an @devs

Setz es doch mit auf die Agenda fürs nächste Dev Meeting

[A Former User]

@feuersturm

wenn wir schon beim Thema Sicherheit sind, dann aber auch gleich den Admin auf https beschraenken...

[Homoran]

@ilovegym sagte in 0.0.0.0 Day - Schwere Lücke:

@feuersturm

wenn wir schon beim Thema Sicherheit sind, dann aber auch gleich den Admin auf https beschraenken...

der lauscht ja auch auf 0.0.0.0

[mcm1957]

@homoran said in 0.0.0.0 Day - Schwere Lücke:

@ilovegym sagte in 0.0.0.0 Day - Schwere Lücke:

@feuersturm

wenn wir schon beim Thema Sicherheit sind, dann aber auch gleich den Admin auf https beschraenken...

der lauscht ja auch auf 0.0.0.0

Moment
Wenn ich den Artikel richtig lese geht es darum dass Browser keine OUTGOING connections mehr an die Adresse 0.0.0.0 senden sollen.

Bei den Adaptern wird aber 0.0.0.0 als Wildcard "Lausch auf allen Adressen die das System anbietet" verwendet. Das ist auch lt. dem Artikel und genanntem RFC zulässig bzw. normal.

Der Fehler / das Sicherheitsloch besteht "nur" bei Browsern bzw. Code der in irgendeiner Form verbindungen aufbaut.

Bin zwar kein Netzwerkspezialist - aber nach meinem Verstäbdnis betrifft dieses Problem ioBroker maximal dort wo outgoind Verbindungen aufgebaut werden - NICHT aber dort wo es um die Auswahl der Interfaces geht.,

[mcm1957]

@ilovegym said in 0.0.0.0 Day - Schwere Lücke:

@feuersturm

wenn wir schon beim Thema Sicherheit sind, dann aber auch gleich den Admin auf https beschraenken...

NEIN

Man kann darüber nachdenken den Default anders einzustellen. Aber wenn der ioBroker nicht von außen zugänglich ist dann bringt https außer einem erhöhten Aufwand absolut nichts. Das Verschlüsseln der Daten im LAN bringt nur dann mehr Sicherheit wenn jemand davon ausgehen muss, dass sein lokales LAN abgehört wird. Und der Zugriff selkbst wird durch https um nicht merh gesichert.

Nebenbei wünsche ich allen viiiiiel Spass dem durchschnittlichen User hier Zertifikate nahe zu bringen,

[Thomas Braun]

@mcm1957 sagte in 0.0.0.0 Day - Schwere Lücke:

Bin zwar kein Netzwerkspezialist

Bin ich auch nicht. Deswegen wollte ich auch eigentlich nichts mehr dazu beitragen, weil das nicht mein Gebiet ist.
Nur braucht es für derartige Verbindungen nicht zwingend einen Browser. Das kannst du auch über andere Geschichten anleiern.

[mcm1957]

@thomas-braun said in 0.0.0.0 Day - Schwere Lücke:

Nur braucht es für derartige Verbindungen nicht zwingend einen Browser. Das kannst du auch über andere Geschichten anleiern.

Ja - natürlich. Jede Software die Verbindungen AUFBAUT (bzw. aufbauen kann) darf keine Verbindung zu 0.0.0.0 aufbauen bzw. Pakete dorthin senden. Insofern sind Adapter potenziell betroffen.

Aber die hier zitierten "listen on all interfaces 0.0.0.0) sind (m.E.) eine Sache. Listen sendet nicht sondern lauscht (no na :-). Und 0.0.0.0 ist hie rnur eine Wildcardbeschreibung und sicherheitsmäßig m.E. ident zu einem extra listen je Interface.

Also sehe ich hier keienrlei Grund für eine Panik oder großflächige Codeanpassungen.

Aber warten wir mal ab was Netzwerkspezialisten dazu sagen. @apollon77 hast du dazu mehr Fachwissen?

[Thomas Braun]

Wenn ich mir anschaue, welchen Diensten da Code untergejubelt werden konnte bzw. welchen nicht

Don’t trust the localhost network because it is “local”—add a minimal layer of authorization, even when running on localhost. Jupyter Notebook developers did a great job at this, adding a token by default.

gibt mir das zu denken.

[Homoran]

@thomas-braun sagte in 0.0.0.0 Day - Schwere Lücke:

add a minimal layer of authorization

und das geht doch nur wenn man

@mcm1957 sagte in 0.0.0.0 Day - Schwere Lücke:

den Admin auf https beschraenken...

NEIN

würde.
ohne https kein auth, oder?

Denn

@mcm1957 sagte in 0.0.0.0 Day - Schwere Lücke:

Nebenbei wünsche ich allen viiiiiel Spass dem durchschnittlichen User hier Zertifikate nahe zu bringen,

kannst du das IMHO auf einen Großteil der User ausdehnen

[mcm1957]

@homoran said in 0.0.0.0 Day - Schwere Lücke:

ohne https kein auth, oder?

Also nach meinem Verständnis kann man ein Authentifizierung (z.B. Username/Passwort) auch ohne https machen. Auch jestzt kannst du bei Admin einstellen, dass du nur mit Usernamen und Passowrt rein darfst - ganz ohne https. Und https selbst bringt keine Authentifizierung des Client mit (zumindest im Normalfall). Bei keiner der öffentlich lesbaren Webseiten die via https erreichbar sind authentifiziere ich ich mit meinem Browser in irgendeiner Weise. Unterschied ist nur, dass der Client prüfen kann ob die Webseite die er sieht die ist die er erreichen wollte. Dass das aber auch eher Theorie ist steht auf einem anderen Blatt. Oder prüfts du bei jedem Aufruf deiner Online Bank das Zertifikat? Ich nicht. Ergo kann eine Fakeseite mit irgendeinem Zertifikat (das es via Lets Encrypt ja trivial gibt) eine saubere https Verbindung herstellen. Das haben auch die Browserhersteller erkannt und google hat aus diesem Grund zB. das Schloss Symbol entfernt. https bedeutet nicht sichere Webseite sondern nur dass die Daten am Weg zum Webserver nicht mitgelesen werden können (von Firewalls im Firmenumfeld die die tls Verbinsung mittels privater Zertifikate aufbrechen mal abgesehen). Persönlich halte ich das Risiko dass jemand meinen Traffic im LAN zu einer Fake ioBroker Seite umleitet für sehr überschaubar (gering).

Siehe z.B.
https://www.golem.de/news/google-chrome-koennte-auf-https-schloss-verzichten-2107-158203.html

[haus-automatisierung]

@mcm1957 sagte in 0.0.0.0 Day - Schwere Lücke:

Wenn ich den Artikel richtig lese geht es darum dass Browser keine OUTGOING connections mehr an die Adresse 0.0.0.0 senden sollen.

So sehe ich das auf den ersten Blick auch. Verstehe den Ausgangspost in Kombination dazu überhaupt nicht. Wie hängt das zusammen?

@thomas-braun sagte in 0.0.0.0 Day - Schwere Lücke:

Der ioBroker (bzw. Adapter) reißt ja einige Dienste auf 0.0.0.0 auf. Wenn die dann auch noch als root laufen, prostmahlzeit.

Kannst Du mal bitte ein Angriffsszenario skizzieren und warum das ein Problem ist?

Wenn man einen Dienst auf 0.0.0.0 hören lässt, heißt das doch einfach nur, dass aus jedem IP-Adressebereich / von jedem Interface die Verbindungen angenommen werden. Die meisten hier werden wohl eh nur ein Interface am System haben. Macht also keinen Unterschied was man dort einstellt (für 99,999% der Nutzer hier).

[mcm1957]

@haus-automatisierung said in 0.0.0.0 Day - Schwere Lücke:

Kannst Du mal bitte ein Angriffsszenario skizzieren und warum das ein Problem ist?

Ich glaube da besteht ein Missverständnis zwischen LISTEN ON ALL INTERFACES [0.0.0.0] und einem Get von der Adresse 0.0.0.0 (http://0.0.0.0/ShowData)

Kann aber auch sein, dass ich völlig blind bin.

[Thomas Braun]

Remote Code Execution hört sich jetzt nicht so lustig an.

[MartinP]

@thomas-braun Meiner Interpretation nach muss folgendes gegeben sein

1. Eine Sicherheitslücke im Webserver von Iobroker, die Einschleusen von Schadcode über einen Request ermöglicht

2. Eine Browsersitzung im lokalen Betriebssystem-Kontext des Iobroker, damit ein Request an 0.0.0.0 das Ziel 127.0.0.1 erreichen kann.

Wenn man sich bei der Einrichtung des Iobroker ein Headless System ausgesucht hat, sollte man Safe sein. Windows User oder Linux Desktop User die keine VM aufgesetzt haben, sondern direkt installiert haben, sollten Vorsichtig sein.