HM-Sec-Key - automatisches öffnen - Sicherheitsrisiko

[mbkirk]

sorry für das "Schreien" Fett-Druck hätte gereicht.

Logfile kommt per PN, DANKE an darkbrain85 !

[mbkirk]

Hallo,

ich habe nun die Key-Matic:

von der CCU-Raspi ab-gelernt und in den Werkszustand versetzt.
alle alten Programme und Einstellungen per Screenshot "gesichert"
alle betroffene Programme gelöscht.
die direkten Verknüpfungen ZU "RC-Keys" (die ich letzte Woche noch angelegt hatte) wieder gelöscht.

DANACH:

die KEY-Matic neu aufs Haustürschloss ein-gelernt, diesmal klappte die Initialisierungsfahrt,
=> das Schloss wird mit "Entriegeln", wirklich nur entriegelt und nicht wie vorher geöffnet.

Key_Matic wieder an die CCU-Rapsi angelernt (vorerst ohne direkte Verknüpfungen zu den RC-Keys)

jetzt erstelle ich meine Programme wieder:

Dann beobachte ich mal, wie das weiter geht,

Anmerkung bei mir lief das seit 5 Jahren ohne Probleme! (nur so wegen den Bemerkungen)

[mbkirk]

so....

ich habe das Programm "Handsender entriegelt+öffnet" gelöscht.
Das war der professionelle Rat von darkbrain85, VIELEN DANK für Deine Mühe.

Mal sehen was nun wird.

[darkbrain85]

so....

ich habe das Programm "Handsender entriegelt+öffnet" gelöscht.
Das war der professionelle Rat von darkbrain85, VIELEN DANK für Deine Mühe.

Mal sehen was nun wird.

Deaktivieren hätte auch erst mal gereicht, aber löschen geht natürlich auch.
Ich bin gespannt ob es jetzt wieder passiert.

An sich ist selbst bei einem Reboot der Zentrale keine Bedingung des Programms wahr. An sich dürfte es nicht auslösen.
Aber da es das einzige Programm ist, welches überhaupt eine Öffnung der Tür triggert, wüsste ich sonst auch nicht was da los ist.
Andererseits scheint deine CCU auch keinen reboot mitten in der Nacht zu machen. Es bleibt also mysteriös!

Vielleicht ist das Programm auch defekt. Wäre ja nicht das erste mal, dass ein Programm nicht das macht was es soll...

[swahl]

So, ich melde mich nun auch mal wieder mit Neuigkeiten.

Ich habe genau vor einer Woche das Update noch einmal versucht, da ich die Türe in meinem Urlaub besser im Blick hatte. Bis dahin hat meine alte Version (2.27xxx) mit all den im Beitrag geposteten Programmen fehlerfrei seinen Dienst verrichtet.
Offensichtliche Fehler in den Programmen hatte keiner im Forum finden können, so dass ich wieder auf die Version zurückgegangen war, mit der alles über ein Jahr problemlos lief.

Was soll ich sagen, seit dieser einen Woche läuft alles seither ebenfalls fehlerfrei. Ich habe folgende Dinge anders gemacht:
- mittlerweile gibt es eine neuere Version 3.45.5.20190330 (statt 3.43.15.20190223)
- habe kein StromPi3 mit der Datei strompi versucht zu aktivieren.
- kein Update der Add-Ons (Cux 1.10b, XML-API 1.13). Den Cux Dämon habe ich nicht in Verwendung. Die XML-API in Verbindung mit Io-Broker schon. Dort wurde seither auch nichts verändert und es beschränkt sich auf die Bewegungsmelder Events, die dann ein Bild von meinen IP Kameras holen.

Ich habe wieder exakt dieselbe Backup-Datei eingespielt wie zuvor. Ich beobachte weiter, eventuell ist beim Backup einspielen ja etwas schief gegangen und nun tut alles.

(und ja, Programme können sich im Fehlerfall auch pseudo-random verhalten. Deterministisch sind sie dennoch alle).

[olifall]

Hallo zusammen,

ich habe die Keymatic auch schon seit 2 Jahren und hatte nie Probleme.

Vor 6 Wochen habe ich die CCU2 durch eine Raspberrymatic 3.41.11.20190126 ersetzt, seit dem hat sich meine Tür auch 2 mal selbständig geöffnet. Zum Glück war meine Frau in beiden Fällen zu Hause. Ich habe nur ein Programm, das mir die Keymatic durch ein Tastenfeld von aussen mit dem richtigen Code öffnet.

Für mich hört sich das alles hier nach einem Problem von der Raspberrymatic an.

Ich werde auch mal das neue Update 3.45...... installieren und schauen was passiert.

Gruss Oli

[Xel66]

Für mich hört sich das alles hier nach einem Problem von der Raspberrymatic an.

Möglich, aber ich finde absolut keinen Grund, wenn RM die Keymatic automatisch ansteuern würde, warum auch nicht andere Aktoren von dem angeblichen Problem betroffen sein sollten (z.B. Licht schaltet sich ohne jeglichen Trigger ein oder aus). Insofern ist es eher unwahrscheinlich, dass dieses ein Zufallsprodukt ist. Es ist viel mehr davon auszugehen, dass die Ursache in einer Programmierung liegt. Es wurde im Forum schon öfter berichtet, dass Schaltvorgänge vermeintlich ohne Trigger und zugehörige Programme ausgeführt wurden (auch schon zu CCU-Zeiten) und es wurde vom Anwender Stein und Bein geschworen, dass keine Programme vorhanden bzw. alle mit Zugriff deaktiviert wären.

Nach viel Recherche kam in fast allen Fällen raus, dass es doch noch ein Programm/Script gab, welche im Hintergrund liefen (gerade bei Scripten, die direkt auf Geräte zugreifen ist dieses eher schwer zu finden, weil man hier nicht die "Programme"-Schaltfläche in der Geräteübersicht nutzen kann). Beim Rest waren Direktverknüpfungen oder ganz simple Programmierfehler. In Frage kommt auch eine Eigenart von Programmen, die beim häufigen Editieren falsch abgelegt werden und sich dann eben nicht so verhalten wie vermeintlich hinterlegt (gerade wenn Systemvariablen verwendet werden und diese ggf. im Nachgang editiert wurden). Hier hilft nur das Löschen des betroffenen Programms und das Neuanlegen (nicht kopieren!).

Ich betreibe selbst seit Mai 2014 eine Keymatic, die auch von Programmen angesprochen wird (sowie natürlich über drei Handsender und eine Tasterschnittstelle in der Steuerung der Türsprechanlage). Früher lief das System auf einer CCU2 seit ca. Mai 2017 auf einer Raspberrymatic. Und meine Tür ist bisher nicht ein einziges Mal von selbst ohne nachvollziehbaren Grund ver-/entriegelt bzw. geöffnet worden. Außer bei unserer Abwesenheit wird die Keymatic ausschließlich elektronisch angesteuert (also keine Handbedienung am Drehrad oder per Schlüssel). Nur der Nachbar öffnet und schließt die Tür für den Post- und Blumendienst mit einem Schlüssel, wenn wir länger abwesend sind. Hier sind aber sämtliche Programme mit Zugriff auf die Keymatic über die Systemvariable "verreist" verriegelt und es laufen keinerlei automatische Schließvorgänge ab.

Ich würde eher davon ausgehen, dass die Keymatic von Hand bedient wurde und so der Zustand "unbekannt" war. Durch das Triggern eines Programms für einen bestimmten Zustand hat vermutlich dann die Keymatic versucht, durch das Anfahren der Endlagen einen konsistenten Zustand herzustellen. Den aktuellen Drehwinkel kann sie eben nur über die Endlagen zuverlässig feststellen. Somit wäre wieder ein Programm, welches ggf. den aktuellen Zustand nur herzustellen versucht, die Ursache. Eine Suche in dieser Richtung wird sicherlich Erfolg bringen.

Gruß Xel66

[grissli1]

Ich habe auch von CCU2 zu RM gewechselt und hatte nie Probleme mit meiner Keymatic. Bei keinem Update und auch sonst nie.
Also sicherlich kein RM Problem.

[swahl]

Hallo,

ich habe nochmals den A/B Vergleich gemacht, da ich momentan ja 3 Installationen auf unterschiedlichen SD-Karten habe.
1) das ursprüngliche System 2.27.8.20170501 (seit Erscheinen fehlerfrei)
2) 3.43.15.20190223 (hier hatte ich pro Tag etwa 1 Tüföffnung)
3) 3.45.5.20190330 (seit etwa 4 Wochen fehlerfrei)

System 1 und 3 laufen fehlerfrei, in 2 bekomme ich wieder Türöffnungen wie zuvor beschrieben. Die Backup-Datei von 1) wurde sowohl für 2) als auch 3) verwendet. Weitere Einzelheiten habe ich ja bereits geschrieben.

Bisher hat keiner einen Fehler in den Programmen gefunden und bei diesem A/B Test läuft überall dieselbe Konfiguration. Wie ihr ja lesen konntet, war im Log bei den "selbständigen" Öffnungen stets der Status "bekannt" angegeben.
Direktverknüpfungen gibt es wie beschrieben nicht (das wurde mir hier ja richtiger Weise empfohlen zu ändern).

@Xell66:
- gibt es noch Programme, die ich nicht über die "Programme und Verknüpfungen" Übersicht sehen kann? Wie erstelle ich diese dann?

- Was meinst du mit der "Eigenart, dass Programme durch mehrfaches Verändern, falsch gespeichert werden"? Das klingt doch eher in Richtung meiner Vermutung, dass beim Import meines Backups etwas schief gelaufen sein muss. Das muss nicht zwangsläufig immer und bei jedem so sein.

Da könnten z.B. Cache Probleme etc. reinspielen, die dann stark vom jeweiligen Speicherinhalt, -Adressen und Ablauf abhängen. Da kann ich ein Lied von singen; das war letzte Woche z.B. wieder mal der Fall, als ich einen Code debuggen musste. Allerdings haben wir hier eine etwas andere Ausgangslage mit 4 A53 (64bit) und 2 R7 (32bit) ohne Betriebssystem, dafür mit FPGA und Lauterbach debugger. Da hatte in einem speziellen Fall die Größe für die Cache Invalidierung nicht gepaßt. Das ist in diesem Programmzweig von etwa 100 000 Tests einmal aufgetreten, je nach Timing und Ablauf. Nur soviel dazu, dass es kein Fehler sein kann, wenn er nicht in allen Fällen auftritt. So etwas ist tückisch und schwer zu finden. Wie das ganze mit einem BS aussieht, weiß ich nicht, da fehlt mir die Erfahrung. Ich mache normalerweise den Logikanteil auf dem FPGA und meine Treiber laufen auf bare-metal.

Werden die Skripte eigentlich interpretiert oder gibt es einen Zwischencode/Objektcode? Wenn der Code interpretiert und nicht vor-kompiliert wird, müsste ja in irgendeiner Datei der eigentliche Quelltext liegen, den man sich anschauen und überprüfen kann.

Für mich hat es sich letztlich erstmal erledigt, nachdem mein System wieder funktioniert. Vermutlich hätte es auch gereicht, ein neues Backup einzuspielen oder die Programme nochmals neu anzulegen, wie du es auch vorschlägst.

Jedenfalls wollte ich nochmals eine Lanze brechen für meine Mitstreiter hier, die ebenfalls betroffen sind. Wahrscheinlich ist es oft ein Anwenderfehler, aber gerade wenn die Probleme direkt nach einem Update auftreten und keiner einen Logikfehler in den Programmen findet, die bisher jahrelang funktioniert haben, ist es doch etwas seltsam.

[Xel66]

- gibt es noch Programme, die ich nicht über die "Programme und Verknüpfungen" Übersicht sehen kann? Wie erstelle ich diese dann?

Es gibt unten die Schaltfläche "Systeminterne Programme einblenden". Programme erstellst Du dafür, indem Du die Option in der Erstellmaske (rechts) aktivierst.

- Was meinst du mit der "Eigenart, dass Programme durch mehrfaches Verändern, falsch gespeichert werden"?

So, wie ich es geschrieben habe. Mir fallen jetzt keine Suchworte ein, um entsprechende Threads zu finden. Mit etwas Aufwand sollten diese aber zu finden sein. Die Erkenntnis ist nicht neu.

...dass beim Import meines Backups etwas schief gelaufen sein muss.

Nein, das hat damit nichts zu tun. Die "defekten" Programme werden intern anders gespeichert, als sie in der Edit-Maske dargestellt werden. Hier kommt es zum Abspeichern falscher Triggerarten ("bei Aktualisierung" anstatt "bei Änderung"). Wenn die Programme falsch gespeichert wurden, dann sind sie auch im Backup kaputt. Dann würde es aber beim nochmaligen Einspielen nicht wieder funktionieren. Dein "Fehler" muss etwas anderes sein.

Da könnten z.B. Cache Probleme etc. reinspielen

Ohne da tiefer drinzustecken würde ich das eher verneinen. Die Abläufe in einer CCU sind "anders" als auf einer SPS oder PC.

Wenn der Code interpretiert und nicht vor-kompiliert wird, müsste ja in irgendeiner Datei der eigentliche Quelltext liegen, den man sich anschauen und überprüfen kann.

Die liegen, wie die gesamte Programmdatenbank auch in der /etc/config/homematic.regadom als XML-Code. Als interpretierter Code muss das nicht unbedingt (außer zur Laufzeit) irgendwo anders zu finden sein.

...aber gerade wenn die Probleme direkt nach einem Update auftreten und keiner einen Logikfehler in den Programmen findet, die bisher jahrelang funktioniert haben, ist es doch etwas seltsam.

Die Ursache hierfür kann auch sein, dass gerade nach einem Update das System frisch gebootet ist, und sich Systemvariablen ggf. in einem anderen Zustand befinden können als in der Laufzeit vorher. Insofern sehe ich keinen Grund, die Ursache für das beobachtete Verhalten im "Betriebssystem" zu suchen. Erst recht nicht, wenn es jetzt wieder funktioniert und an den Stellen eher nicht geschraubt wurde. Schon gar nicht, wenn nur ein einziger Aktortyp (eben die Keymatic) davon betroffen sein sollte.

Gruß Xel66