ETS 6.3.X - alles wird gut!

[hthoma]

Ja, aber diese Sequenznummer ist im Gerät gespeichert und kann durch die ETS nicht überschrieben werden Nur ein Werksreset hilft da.

Und nach INT_MAX kann man nicht einfach wieder mit 0 weitermachen? So einen wrap-around kann man schon vernünftig implementieren, das machen z.B. kryptographische Netzwerkprotokolle ja auch. Die fangen typischerweise auch nicht bei 0 als Sequenznummer an, sondern bei einem Zufallswert, weil sonst die bekannten Sequenznummern angegriffen werden könnten.

[Konsti1]

was saufen die?

Wo finde ich eine Info dazu?

Zum Thema der Abschaffung der manuellen Filtertabellen ist mir noch etwas aufgefallen. Die Abschaffung wird ja unter anderem damit begründet, dass die entsprechenden GAs ab jetzt mit einem Tunneling-Slot der IP-Schnittstelle verbunden werden sollen. Dabei wurde jedoch offenbar vergessen, dass nicht alle IP-Interfaces ihre Tunneling-Slots als solche im Applikationsprogramm angelegt haben, sondern als "herstellerspezifische Schnittstelle". Diese lassen sich nicht mit Gruppenadressen verbinden. Ist zwar nur ein Detail aber irgendwie trotzdem nervig...


Hier beide Varianten im Vergleich:
Screenshot 2024-12-14 010725.png

[Oups]

Dummy?

[thewhobox]

Der Grund warum nicht wieder bei 0 angefangen ist würde ja bereits genannt.
Damit sollen Replay Attacken verhindert werden.
Ja die werden vll nicht oft ausgenutzt heutzutage, aber es hat sich auch Jahrzehnte lang keiner beschwert, dass haufenweise Ports von Schnittstellen offen im Internet hingen, bis es einer ausgenutzt hat.

Ich finde es gut, dass die KNXA hier Sicherheit wirklich implementiert.

Auch wenn das zu einem von vielen Bugs nach dem Update führt.
Aber auch nur, weil er erst jetzt mit einer Meldung ausgegeben wird.

Gruß Mike

P. S. Klaus Gütter hatte auch gesagt, dass ein Überlauf erst nach mehreren Tausend? Jahren erfolgt. Ein Überlauf ist somit nicht mal möglich im Lebenszyklus eines Gerätes.

[DerStandart]

Mich würde interessieren, wie dann solch hohe Werte zu Stande kommen können?

[mumpf]

Das ist immer das Problem mit Bugs: Das weiß man erst, nachdem man den Bug gefunden und gelöst hat.

Vielleicht sagt es uns Klaus Gütter ja, sobald es eine Lösung gibt.

Gruß, Waldemar

[hthoma]

Der Grund warum nicht wieder bei 0 angefangen ist würde ja bereits genannt.
Damit sollen Replay Attacken verhindert werden.

Das ist für mich nicht schlüssig.

P. S. Klaus Gütter hatte auch gesagt, dass ein Überlauf erst nach mehreren Tausend? Jahren erfolgt. Ein Überlauf ist somit nicht mal möglich im Lebenszyklus eines Gerätes.

Trotzdem tritt es offenbar auf. Und wenn das so ist dann wäre ein Replay der Sequenznummer 0 nach INT_MAX ja ein Replay von vor 90000 Jahren, also nichts was praktisch anwendbar wäre. Wenn man da einen wrap-around zulassen würde und ein Fenster von INT_MAX/2 ansetzen würde hätte man immer noch 45000 Jahre Sicherheit. Ich denke das sollte auch reichen ...

Ich finde es gut, dass die KNXA hier Sicherheit wirklich implementiert.

Ich halte es auch für möglich, daß hier nicht wirklich ganz bis zu Ende gedacht wurde. Siehe:

Ich hab eigentlich noch nie bewusst was programmiert, was auf eine Sackgasse zusteuert, ohne eine Überlaufbehandlung zu machen ...

[thewhobox]

Replay Attack hat nix mit von vor 90000 Jahren zu tun.
Du zeichnet auf und spielst es gleich wieder ab.
Das kann auch vor 5 Minuten sein.

Ich bin kein Sicherheitsexperte und hab auch nie behauptet, dass es keinen Bug gibt (wie man an der Fehlermeldung sieht gibt es den definitiv), aber die KNXA hat sich nun mal Ziele gesetzt die Verbindung sicher zu machen. Dazu zählt nun mal Replay Attacken gänzlich zu unterbinden (ohne Bestimmte zeitbereiche) und das geht nunmal nur, wenn die Sequenz nicht zurückgesetzt werden kann.

Wenn dich das so sehr stört dann mach doch ein Ticket auf. Vll überzeugt du sie ja mit deinen guten Argumenten

[Beleuchtfix]

Aber auch nur, weil er erst jetzt mit einer Meldung ausgegeben wird.

Klaus hat gesagt, die Meldung wurde eingefügt, weil es schon Probleme mit dem Überlauf gegeben hat. Also irgendwo ist da eben noch ein Fehler - sost könnte man die 90000 Jahre aussitzen.
Gruß
Florian

[sewi]

Wenn es offensichtlich Fehler gibt, dann ist eine Überlaufbehandlung trotzdem besser, als mit Vollgas auf eine Wand zuzufahren.

Ich nehme an, die Fehler sind in den Geräten zu finden, und keine konzeptionelle Fehler (denn wenn man als Angreifer die Sequenznummer beeinflussen könnte, hat man hier gleich mal eine DoS Attacke). Und diese Fehler in den einzelnen Geräten sollten also natürlich ausgemerzt werden. Derzeit bekommen die Kunden aber nur die Symptome zu sehen, und müssen Resetten, und regelmäßig in der ETS nachsehen, ob's ein Problem gibt, sonst steht das ganze mal spontan. Damit (mit dem "Anlage kann jederzeit spontan stehen") hätte ich, als Anwender, überhaupt keine Freude - auch nicht mit der Ungewissheit dass, wenn ich mal länger nicht in die ETS schaue, das sich anbahnende Problem nicht merke.

thewhobox Ich bin vom Problem nicht betroffen. Generell bin ich nicht der Typ, der z.B. bei OSS Probleme meldet. Hab ich ursprünglich gemacht, sogar mit Pull Requests. Tu ich nicht mehr. Und zwar, weil es immer auf's gleiche rausläuft (und ich sehe das nicht nur bei mir, sondern auch in anderen Bug Reports). Da kommen dann Anmerkungen wie "wenn du's besser kannst, wieso mach's du's nicht selbst" und "das ist kein Fehler sondern muss so sein", und ich hab ganz ehrlich weder die Lust noch die Energie mich mit Leuten herumzustreiten. Wird nach dem dutzenden Mal langweilig und unlustig.

[Klaus Gütter]

Ein paar Hintergrundinformationen:

Es geht hier um die "Sequence Number for Tool Access" (Abschnitt 2.3.3 in AN158). In dieser Ressource speichert das Gerät die Sequenznummer, die es zuletzt von der ETS empfangen hat. Von der ETS empfangene Secure-Telegramme werden vom Gerät nur akzeptiert, wenn ihre Sequenznummer höher ist.

Der Wert wird vom Gerät verwaltet und kann nur immer größer werden, bis zum Limit 2 ^48-1 (0xFFFF FFFF FFFF). Wenn dieser Wert erreicht ist, akzeptiert das Gerät keine Secure-Telegramme mehr. Die einzige Möglichkeit, den Wert wieder kleiner zu machen, ist ein Werksreset. Dabei wird der Wert wieder auf einen "vernünftigen" Wert gesetzt, bei jedem Werksreset aber auf einen höheren Wert als beim letzten Werksreset.

Die erste Aktion, die die ETS ausführt, wenn sie mit einem Gerät sicher kommunizieren will, ist ein "Sync": die ETS fragt dabei das Gerät nach der Sequenznummer, die es von ihr erwartet und adaptiert die eigene Sequenznummer dementsprechend. Dieser Vorgang ist über den ToolKey gesichert. Das ist die Stelle, die sich in der ETS 6.3.0 geändert hat: der Wert wird hier jetzt auf Plausibilität geprüft, Werte >= 0xFF00 0000 0000 werden jetzt nicht mehr akzeptiert. Bei solchen Werten ist definitiv etwas falsch gelaufen und davor die Augen zu verschließen macht keinen Sinn.

Wie kommt nun ein derart hoher Wert zustande? Da gibt es theoretisch drei Möglichkeiten:

1. ein Bug in der ETS, die ihre eigene Sequenznummer aus unbekannten Gründen plötzlich auf so einen hohen Wert pusht.
   Wir haben den entspr. Code sorgfältig reviewt und können uns nicht vorstellen, wie das passieren kann. Aber natürlich ist das auch nur eine Variable im RAM und 100% ausschließen lässt sich da nichts.
2. eine andere Software, die den Toolkey kennt, könnte ein Telegramm mit so einer hohen Sequenznummer gesendet haben, ob aus Versehen oder als Angriff.
   Da zeigt übrigens noch einmal, dass die Kenntnis des ToolKey nicht unnötig verbreitet werden darf, sei es über knxproj (+Passwort) oder das Keyring-Backup (+Passwort). Eine Visualisierung soll daher nur das "Interface Information File" bekommen, nicht das "Keyring Backup File"; aber das ist ein anderes Thema.
3. ein Bug im Gerät. Das könnte ein Fehler in der Verarbeitung von gesicherten Telegrammen, ein Fehler bei der Persistenz oder ein Hardwarefehler sein. Ein kritischer Zeitpunkt ist beispielsweise Spannungsverlust: hier muss das Gerät mit der verbleibenden Energie den aktuellen Wert in den nicht-flüchtigen Speicher schreiben. Wenn das nicht gelingt, kann bei nächsten Aufstarten alles passieren.

Das Ganze wird in der ETS 6.2 leider dadurch verschärft, dass die ETS nur einen Sequenzzähler für die gesamte sichere Kommunikation benutzt hat. Wenn ein Sync mit einem Gerät also die Sequenznummer der ETS auf so einen wilden Wert gepusht hat, macht die ETS damit weiter und "infiziert" dadurch möglicherweise weitere Geräte. Das kann in der ETS 6.3 nicht mehr passieren, hier wird die eigene Sequenznummer für jedes Gerät separat verwaltet. Daher kann ich nur dazu raten, die ETS 6.3.0 zu benutzen.

[traxanos]

Die einzige Möglichkeit, den Wert wieder kleiner zu machen, ist ein Werksreset. Dabei wird der Wert auf einen "vernünftigen" Wert zurückgesetzt, bei jedem Werksreset aber auf einen höheren Wert als beim letzten Mal.

Das ist für mich aber ein Widerspruch. Wie genau ist das gemeint. Entweder es setzt den Zähler zurück oder eben nicht.

[Klaus Gütter]

Gemeint ist "... als beim letzten Werksreset". Habe es in obigem Beitrag jetzt anders formuliert.

[thewhobox]

sewi das wäre aber nur das behandeln von Symptome (hier sogar uaf Kosten der Sicherheit, wenn auch nur gering) und nicht der Ursache!
Das ist (für mich) immer der falsche Weg.
Es löst einfach nicht das Problem, was von Klaus nun sehr detailliert beschrieben wurde.

[traxanos]

Gemeint ist "... als beim letzten Werksreset". Habe es in obigem Beitrag jetzt anders formuliert.

Sorry aber damit ist mir immer noch nicht klar was passiert. Bedeutet das wenn ich 10 Werksresets durch geführt habe, das der Zähler dann bei 11 ist? Oder gibt es eine andere Logik. Und was ist wenn der letzte Werksreset dann noch größer war als 0xFF00 0000 0000 ist 🤯

Und was mich auch interessiert, was ist der Hintergrund. Ich würde ja schon erwarten, wenn ich ein Gerät zurücksetze dass es den gleichen zustand annimmt wie bei Werksauslieferung.