Sicherheitsproblematik

[Prof. Dr. Peter Henning]

Je komplizierter das gesamte Framework wird, desto wahrscheinlicher werden üble Tricks.

Ich schlage deshalb vor, dass eine zentrale Funktion bereitgestellt wird, die auf die mögliche Injektion von Schadcode testet.
Beispiel: Jemand könnte ein AttrTemplate bauen, das für irgendein Modul, das als Attribut eine auszuführende Funktion bekommen kann, dieses Attribut mit einer schädlichen Funktion füllt.

Bei der nächsten Ausführung würde dann dieser Schadcode durchlaufen und z.B. Dateien überschrieben.

LG

pah

[CoolTux]

Wäre das dann nicht schon eine Art Virenscanner? Die Frage ist ja immer wie erkennt man solchen Schadcode.

[Dr. Boris Neubert]

Peter, beziehst Du Dich auf den Code, der aus dem FHEM-Repo per Update geladen wird, oder irgendwelchen Code, den sich ein Anwender von irgendwo lädt?

Grundsätzlich müssen wir davon ausgehen, dass bösartige oder auch nur fehlerhafte Module, Templates etc. die vollen Rechte des Users ausnutzen, unter dem FHEM läuft. Ohne Ausnutzung von Sicherheitslücken, über die sich der Code dann ggf. noch erhöhte Rechte verschaffen kann, bedeutet das dann mögliche Totalzerstörung von FHEM, Einbau von Spionen, die nach Hause telefonieren können, etc.

Aufgrund der Tatsache, dass FHEM OpenSource ist, würde man das zwar entdecken und beseitigen können, aber dafür müsste es auffallen, und dann ist es i.d.R. zu spät.

Vielleicht so ein Rechtesystem wie bei Android, sodass die Module mit noch weniger Rechten laufen als FHEM?

Was schwebt Dir vor?

Viele Grüße
Boris

[justme1968]

mal abgesehen vom erkennungs problem das bei einem offenen und interpretierten system nicht lösbar scheint: warum gerade bei den templates ansetzen? jemand der darauf zugriff hat, kommt auch an alles andere und hat noch viel unauffälligere und zuverlässigere manipulations möglichkeiten.

der grosse nachteil ist aber auch der größte vorteil: wir haben ein offenes system. die chance hier durch anschauen probleme zu finden ist zumindest vorhanden.

ich glaube aber das eigentliche risiko für eine fhem installation kommt nicht direkt von solchem code sondern von anwendern die einfach zugriff aus dem internet erlauben. hier hat sich zum glück die letze zeit bezüglich csrf token, telnet deaktivieren und default zugriff nur aus dem lokalen netz schon etwas getan.



zu virencheckern allgemein: wer sich damit beschäftigt hat und sogar schon mal mit den herstellern auf etwas technischerer ebene zu tun hatte weiß das das ganze eigentlich eine ziemliche katastrophe ist. es gibt keinen besseren und besser verschleierbaren angriffsvektor. auch die bilanz bezüglich falsch positiver sowie nicht erkannter probleme ist nicht zu vernachlässigen.

[CoolTux]

Ich denke mal das Template sollte da nur als Beispiel dienen. Ich Teile Deine Argumentation

der grosse nachteil ist aber auch der größte vorteil: wir haben ein offenes system. die chance hier durch anschauen probleme zu finden ist zumindest vorhanden.

[Prof. Dr. Peter Henning]

Virenscanner und Totalschutz sind natürlich kaum realisierbar, aber Kleinvieh macht eben auch Mist. Mir schwebt eine Hilfsfunktion für Modulautoren vor.

Angenommen, ich schreibe ein Modul, das in einem Attribut "FUFU" irgendwelche Funktionsdefinitionen bekommt, die dann ausgeführt werden (gibt es nicht nur bei mir, sondern in ganz vielen Modulen). Die Ausführung erfolgt dann typischerweise durch zwei Zeilen im Modulcode, die etwa lauten

Code: [Auswählen]

$func = AttrVal($name,"FUFU","");
fhem($func);
Die erste Möglichkeit wäre, den Attributwert zu prüfen - etwa darauf, ob er Systemkommandos enthält - und dann eine Warnung auszugeben. Das global-Device könnte eine Liste der Devices bekommen, denen dieses erlaubt ist - und wenn das hier der Fall ist, wird eben keine Warnung ausgespuckt. Dafür würde also so etwas gebraucht wie eine Funktion SecureAttrVal, die man einfach an Stelle von AttrVal einsetzen kann.


Eine zweite Möglichkeit wäre, bei der Ausführung zu prüfen, also statt der Funktion fhem() eine Funktion SecureFhem zu haben. Auch hier derselbe Ablauf: Diese Funktion sieht nach, ob für das ausführende Device die globale Erlaubnis zur Ausführung von (System-)Kommandos vorliegt. Wenn ja, wird ausgeführt. Wenn nein, gibt es stattdessen nur eine Warnung im Log.

LG

pah

[CoolTux]

Ansätze zum analysieren von Perlcode gibt es ja schon.

AnalyzeCommands()

[zap]

Perl bietet so viele Möglichkeiten, Code einzuschleusen, dass jegliche Gegenmaßnahme nur der berühmte "Tropfen auf den heißen Stein" ist.
Mindestens genauso kritisch wie die Einschleusung von Schadcode ist die fehlende Möglichkeit, Passwörter sicher zu speichern. Hier ist jedoch nicht nur die Interpretersprache Perl das Problem, die es ermöglicht, an irgendeiner Stelle das Passwort im Klartext einzusehen, sondern auch die angebundenen externen Systeme, die oft keine Sicherheitsfunktionen wie Auth-Tokens, Session Cookies, Generierung von Passwort-Hashes, etc. anbieten.

[PatrickR]

Mahlzeit!

Perl bietet so viele Möglichkeiten, Code einzuschleusen, dass jegliche Gegenmaßnahme nur der berühmte "Tropfen auf den heißen Stein" ist.

Volle Zustimmung. Wenn man damit jetzt in FHEM anfinge, würde man einen endlosen Wettlauf beginnen, den man nicht gewinnen kann. Zeitgleich würde man die Gegenseite - so sie denn existiert - motivieren, den Code so zu verschleiern, dass man die Schadfunktion nur noch schwer erkennt. Da ist man dann schnell an der Stelle, wo SecureFhem dann eine wie auch immer geartete Sandbox startet, um den Code dynamisch zu analysieren und das auch nur so lange, bis der Schadcode die Sandbox erkennt. Außerhalb von FHEM beteiligt man sich m. E. auch nur deshalb an dem Wettrüsten, weil man einmal damit angefangen hat und zudem sehr gutes Geld damit verdienen kann.

Mindestens genauso kritisch wie die Einschleusung von Schadcode ist die fehlende Möglichkeit, Passwörter sicher zu speichern. Hier ist jedoch nicht nur die Interpretersprache Perl das Problem, die es ermöglicht, an irgendeiner Stelle das Passwort im Klartext einzusehen, sondern auch die angebundenen externen Systeme, die oft keine Sicherheitsfunktionen wie Auth-Tokens, Session Cookies, Generierung von Passwort-Hashes, etc. anbieten.

Naja, wenn ich ein Auth-Token klaue, ist das genauso wirksam wie ein Passwort, es sieht nur anders aus. Der Vorteil ist nur, dass der Nutzer zu anwendungsbezogenen Tokens gezwungen wird, und so jederzeit einen Überblick hat und ausmisten kann.

/Edit: ... und natürlich dass man die Tokens automatisch regelmäßig erneuern kann.

Patrick

[betateilchen]

Der von Peter beschriebene Wunsch ist natürlich nachvollziehbar. Aber in einem so großen Open-Source-Projekt, wie es FHEM inzwischen geworden ist, in dem man selbst einige "offizielle" Modul schon fast als Schadsoftware einstufen könnte, halte ich die Bestrebungen nach einer solchen Sicherheitsumgebung für komplett am Sinn von FHEM vorbei.

Ausserdem ist es - wie bereits beschrieben - jederzeit  problemlos möglich, in einer auf perl basierenden Entwicklungsumgebung jegliche Sicherheitsmaßnahme auszuhebeln, wenn man dies in böser Absicht wirklich tun möchte. Einen großen Anteil dazu tragen externe Blogs und "Fachartikel" auf fremden Webseiten bei.

Man sollte eher allen Anwendern klarmachen, dass sie für die Sicherheit ihres Systems selbst verantwortlich sind. Das fängt schon bei Dingen wie "Zugriff aus dem Internet auf mein FHEM" an. Der Irrglaube, dass das VPN einer Fritzbox eine geeignete Maßnahme sei, dabei eine zuverlässige Sicherheit zu gewährleisten, wird sich wohl leider nie ausrotten lassen.

Letztendlich sollten wir als Entwickler aufpassen, dass wir durch einen Paranoia-Modus das gesamte Projekt FHEM irgendwann nicht komplett unbenutzbar machen.

[PatrickR]

Hi!

Der Irrglaube, dass das VPN einer Fritzbox eine geeignete Maßnahme sei, dabei eine zuverlässige Sicherheit zu gewährleisten, wird sich wohl leider nie ausrotten lassen.

Da Du PMs blockst: Hast Du mal eine kurzes Stichwort zum Thema bzw. eine Referenz?

Patrick

[zap]

Hi!Da Du PMs blockst: Hast Du mal eine kurzes Stichwort zum Thema bzw. eine Referenz?

Patrick

Oja, würde mich auch interessieren, wie man den VPN Zugang einer Fritzbox knackt. Nutze ich nämlich auch seit Jahren. Weiß AVM das? Ich wußte ja gar nicht, in welcher Gefahr ich schwebe