ETS 6.3.X - alles wird gut!

[Punker Deluxe]

Dafür hat die KNXA keine Zeit, sie hat genug zu tun Bugs für dich zu kreieren um dich zu ärgern.

[BadSmiley]

Bei meinem Mitarbeiter ist es jetzt auch das 1. mal passiert. Wir checken beide mehrmals täglich Projekte ein und aus, aber warum auch immer, bei einem Projekt steht jetzt sein Name in Klammern.

Hey KNX A, als Idee für die Zukunft "Sie nerven die Bugs wie zu wenig Arbeitsspeicher? Hier ein Link für eine 80€ "Arbeitsspeichererweiterungsapp" für die ETS 6.3!" oder "Sie nerven so Bugs wie Ihr Name in Klammern? Hier ein Link für eine 80€ "Nameentfernungsapp" für die ETS 6.3!"
Ich sage euch, das wird der Brüller für alle ETS Nutzer und ihr kriegt noch ganz viel mehr Zuspruch.

[TomasM]

Du musst über Deinen Account die bestehende Bindung der Cloud-Lizenz an Deinen Rechner entfernen und dann diese über die ETS wieder zuweisen: https://my.knx.org/en/my-account/products

Rein Theoretisch sollten alle die ein Dongle besitzen auch eine CLoud Lizenz mit dem selben Schlüssel haben... Dann kann man wenigstens noch weiterarbeiten wenn der Dongle irgendwo vergessen wird bzw. geschrottet ist ... Ja.. Klar schwarze Schafe die dann ggf. 2x benutzen dürfen spucken hier wieder in die Suppe.. aber dennoch... Gehen solte es.. Wir sind doch alle ehrlich..

Dann wäre der Test auch viel genauer da in mehr Leute testen könnten und es fühlen sich weniger Leute als Beta Tester. Mal überlegen.. Weniger Geld werdet ihr durch die Aktion sicher nicht verdienen..

Tomas

[traxanos]

Völlig unmöglich, da landet das Gerät erst nach Millionen von Jahren.

So wie die aktuelle Sequenznummer

Replay Attacks

Ein echter Werksreset sollte nur physikalisch möglich sein. Somit greift das Argument nicht.

[Klaus Gütter]

Bedeutet das wenn ich 10 Werksresets durch geführt habe, das der Zähler dann bei 11 ist?.

Das ist der Implementierung überlassen. Die Anforderung ist nur, dass der neue Startwert mindestens 20 höher sein muss als der letzte.

Und was ist wenn der letzte Werksreset dann noch größer war als 0xFF00 0000 0000 ist

Völlig unmöglich, da landet das Gerät erst nach Millionen von Jahren.

wenn ich ein Gerät zurücksetze dass es den gleichen zustand annimmt wie bei Werksauslieferung.

Es wäre dann sofort anfällig für Replay Attacks.

[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.

[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.

[Klaus Gütter]

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

[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]

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.

[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.

[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

[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

[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 ...

[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