Autor Thema: Sicherheitsproblematik  (Gelesen 1006 mal)

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6955
Sicherheitsproblematik
« am: 17 April 2019, 11:21:09 »
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

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 22887
Antw:Sicherheitsproblematik
« Antwort #1 am: 17 April 2019, 11:52:56 »
Wäre das dann nicht schon eine Art Virenscanner? Die Frage ist ja immer wie erkennt man solchen Schadcode.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline Dr. Boris Neubert

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4569
Antw:Sicherheitsproblematik
« Antwort #2 am: 17 April 2019, 21:41:04 »
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
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Offline justme1968

  • Developer
  • Hero Member
  • ****
  • Beiträge: 19573
Antw:Sicherheitsproblematik
« Antwort #3 am: 17 April 2019, 21:50:05 »
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.
FHEM5.4,DS1512+,2xCULv3,DS9490R,HMLAN,2xRasPi
CUL_HM:HM-LC-Bl1PBU-FM,HM-LC-Sw1PBU-FM,HM-SEC-MDIR,HM-SEC-RHS
HUEBridge,HUEDevice:LCT001,LLC001,LLC006,LWL001
OWDevice:DS1420,DS18B20,DS2406,DS2423
FS20:fs20as4,fs20bs,fs20di
AKCP:THS01,WS15
CUL_WS:S300TH

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 22887
Antw:Sicherheitsproblematik
« Antwort #4 am: 17 April 2019, 21:55:02 »
Ich denke mal das Template sollte da nur als Beispiel dienen. Ich Teile Deine Argumentation
Zitat
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.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline Prof. Dr. Peter Henning

  • Developer
  • Hero Member
  • ****
  • Beiträge: 6955
Antw:Sicherheitsproblematik
« Antwort #5 am: 18 April 2019, 08:54:19 »
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

$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

Offline CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 22887
Antw:Sicherheitsproblematik
« Antwort #6 am: 18 April 2019, 10:17:31 »
Ansätze zum analysieren von Perlcode gibt es ja schon.

AnalyzeCommands()
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3025
    • HMCCU
Antw:Sicherheitsproblematik
« Antwort #7 am: 19 April 2019, 09:52:44 »
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.
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach
Zustimmung Zustimmung x 2 Liste anzeigen

Offline PatrickR

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 716
Antw:Sicherheitsproblematik
« Antwort #8 am: 19 April 2019, 14:27:01 »
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
« Letzte Änderung: 19 April 2019, 14:34:31 von PatrickR »
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16099
  • s/fhem\.cfg/configDB/g
Antw:Sicherheitsproblematik
« Antwort #9 am: 19 April 2019, 16:19:10 »
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.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.

Offline PatrickR

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 716
Antw:Sicherheitsproblematik
« Antwort #10 am: 19 April 2019, 16:55:47 »
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
lepresenced - Tracking von Bluetooth-LE-Tags (Gigaset G-Tag) mittels PRESENCE

"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Rich Cook
Gefällt mir Gefällt mir x 1 Zustimmung Zustimmung x 2 Liste anzeigen

Offline zap

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3025
    • HMCCU
Antw:Sicherheitsproblematik
« Antwort #11 am: 19 April 2019, 17:57:49 »
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  :P
2xCCU3, diverse Komponenten (Fenster, Rolladen, Themostate, Stromzähler, Steckdosen ...)
FHEM mit Raspi für CCU Integration.
IOBroker für UI (VIS), Hue, Sonos usw.
Maintainer der Module FULLY, Meteohub und HMCCU (Schnittstelle CCU-FHEM = best of both worlds approach
Zustimmung Zustimmung x 2 Liste anzeigen