iDreamX - Version 3 - Diskussion OpenWebif

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Ich glaube ich weiß woran es liegt.
      Meiner Ansicht nach liegt der Fehler im Open Webif

      Kann irgendjemand einen Kontakt zu den Entwicklern herstellen?
      Ich habe schon des öfteren versucht die anzuschreiben aber nie eine ANtwort erhalten...

      Es gab doch auch mal einen Thread, ich kann den nicht finden... :(

    • Das ist das Problem:


      Der Befehl:

      Quellcode

      1. http://Box_IP/file?file=
      scheint nicht richtig zu funktionieren:

      Quellcode

      1. http://Box_IP/file?file=/etc/enigma2/settings
      liefert ein
      File '/etc/enigma2/settings' not found


      lege ich eine Datei: 'bla' ins root Verzeichnis der Box und dann

      Quellcode

      1. http://Box_IP/file?file=/bla
      kommt
      File '/bla' not found


      lege ich jedoch eine Datei: 'bla' ins root Verzeichnis der hdd und dann

      Quellcode

      1. http://Box_IP/file?file=/hdd/bla

      Funktioniert es und die Datei wird geladen.

      Getestet mit OpenWebif v0.1.3 und VU+ SOLO2 mit VTi Image 5.1.0

    • Hab ich mir fast gedacht, ist die letzte Änderung, die ich committet habe. Der Grund ist, dass über das Web-Interface so jedes File ausgelesen werden kann, unter anderem /etc/shadow, /etc/CCcam.cfg, /etc/tuxbox/config/, ...

      In der /etc/enigma2/settings-Datei stehen unter Umständen auch Passwörter im Klartext drin, im abgesicherten heimischen Umfeld kein Problem, aber da immer mehr Leute (auch wegen Transcoding) eine Portweiterleitung einrichten, oft auch noch ohne Passwort- und HTTPS-Absicherung, halte ich es nicht für eine überragend gute Idee, die Box sperrangelweit offen zu lassen.

      Was für Informationen benötigst Du aus der /etc/enigma2/settings? Vielleicht können wir dafür die API erweitern? Vielleicht gibt es (schon) eine andere Möglichkeit, an die Daten zu kommen?

      PS: Ich habe die Änderung vor ein paar Wochen in diesem Thread vorgeschlagen, da hast Du eingeworfen, dass es keine gute Idee ist, die API einzuschränken, aber ich habe auf meine Nachfrage, warum, keine Antwort bekommen...

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Cimarast ()

    • Original von Cimarast
      Hab ich mir fast gedacht, ist die letzte Änderung, die ich committet habe. Der Grund ist, dass über das Web-Interface so jedes File ausgelesen werden kann, unter anderem /etc/shadow, /etc/CCcam.cfg, /etc/tuxbox/config/, ...

      In der /etc/enigma2/settings-Datei stehen unter Umständen auch Passwörter im Klartext drin, im abgesicherten heimischen Umfeld kein Problem, aber da immer mehr Leute (auch wegen Transcoding) eine Portweiterleitung einrichten, oft auch noch ohne Passwort- und HTTPS-Absicherung, halte ich es nicht für eine überragend gute Idee, die Box sperrangelweit offen zu lassen.

      Was für Informationen benötigst Du aus der /etc/enigma2/settings? Vielleicht können wir dafür die API erweitern? Vielleicht gibt es (schon) eine andere Möglichkeit, an die Daten zu kommen?

      PS: Ich habe die Änderung vor ein paar Wochen in diesem Thread vorgeschlagen, da hast Du eingeworfen, dass es keine gute Idee ist, die API einzuschränken, aber ich habe auf meine Nachfrage, warum, keine Antwort bekommen...


      Mist, da funktionierte anscheinen die email Benachrichtigung nicht und so habe ich von deiner Nachfrage nichts mitbekommen.

      Es geht mit gar nicht um die Datei: /etc/enigma2/settings
      sondern um die Möglichkeit sehr einfach eine beliebige Datei auszulesen.

      Ich könnte sie natürlich über ftp laden und dann lokal auslesen.
      Dadurch wird es aber viel langsamer.

      Ich bin mir auch nicht sicher ob diese Einschränkung zur Sicherheit beiträgt, da man (wenn man will) auch über ftp an die Datei rankommt.

    • Jein; hast Du jemals von irgendwem gehört, der eine Portweiterleitung für FTP eingerichtet hat und auch noch ans Laufen bekommen hat?

      Aber zurück zum Thema: um welche Files geht es Dir? Welche Files holst Du über das /file?file= Interface ab?

    • Ich schätze ich bin nicht der Einzige, der mit dieser Einschränkung große Probleme hat. Andere Entwickler verwenden ja auch die Webinterface-Befehle.

      Ich denke du solltest diese Einschränkung entweder zurücknehmen oder zumindest abschaltbar machen, sonst wird die Entwicklung für VU-Boxen wesentlich komplizierter als für andere...

    • Original von Cimarast
      Jein; hast Du jemals von irgendwem gehört, der eine Portweiterleitung für FTP eingerichtet hat und auch noch ans Laufen bekommen hat?

      Aber zurück zum Thema: um welche Files geht es Dir? Welche Files holst Du über das /file?file= Interface ab?

      Zum Beispiel die Dateien, die bei opkg update erzeugt werden.
      Aber es gibt auch noch andere Stellen wo ich das verwende. Auch in der Zukunft möchte ich darauf zurückgreifen können.

      Ich finde ihr könnt nicht dafür verantwortlich gemacht werden, dass manche Leute kein Passwort setzen.
      Ausserdem gibt es genügend andere webinterface befehle die erheblichen schaden anrichten können /file?file= ist da doch nur ein kleiner Fisch.

    • Original von Cimarast
      Original von relaht
      Ausserdem gibt es genügend andere webinterface befehle die erheblichen schaden anrichten können /file?file= ist da doch nur ein kleiner Fisch.

      Z.B.?

      Wollen wir jetzt wirklich damit anfangen?
      Allein /web/remotecontrol?command= reicht um Unfug ohne Ende zu machen.

      Fakt ist, diese Einschränkung würde (wahrscheinlich nicht nur für mich) viele Tage Arbeit nach sich ziehen. Ich müsste einige Konzepte des Programms völlig neu überdenken.

      Kurz und knapp: Für mich ist das der Super-GAU!

    • Ich bin ja durchaus gewillt, das auf einem für beide Seiten akzeptablen Level wieder zurückzubauen, meinetwegen dadurch, dass man es explizit freigeben muss. Otto-Normal-User weiß oft nicht, was er anstellt, und man sollte ihn wenn möglich schützen. Siehe den zitierten Thread.

      Und bisher hast Du nur Allgemeinplätze angeführt:
      Ausserdem gibt es genügend andere webinterface befehle die erheblichen schaden anrichten können /file?file= ist da doch nur ein kleiner Fisch.


      Kein Grund, jetzt laut zu werden und zu übertreiben:
      Kurz und knapp: Für mich ist das der Super-GAU!

      Der Super-GAU wäre für mich, wenn ich Abends nach Hause komme und meine Festplatte ist von außen formatiert worden.

      Also lass uns bitte wieder konstruktiv werden. Mir fallen auf Anhieb mehrere Lösungsmöglichkeiten ein:
      - Zugriff erlauben, wenn Passwort gesetzt ist.
      - Zugriff aus privaten Subnetzen erlauben.
      - Zugriff aus konfigurierten Subnetzen erlauben.
      - Zugriff explizit in den Settings freigeben.
      - ...

    • Original von Cimarast
      Kein Grund, jetzt laut zu werden und zu übertreiben:
      Kurz und knapp: Für mich ist das der Super-GAU!

      Der Super-GAU wäre für mich, wenn ich Abends nach Hause komme und meine Festplatte ist von außen formatiert worden.

      Man kann doch sogar über die GUI des Webinterfaces alle Filme auf der Festplatte löschen...!


      Ich übertreibe keineswegs. In iDreamX stecken 7 Jahre Arbeit und was für Konsequenzen dadurch auftreten, überblicke ich nicht auf den ersten Blick.
      Dafür muss ich erst tausende Zeilen von Code durchforsten.
      Zum Glück habe ich auch eine Suchfunktion. :)

      Ich wollte auch keineswegs laut werden. Sorry wenn das so empfunden wurde.

      Zwingt die User doch ein Passwort zu setzen.
      Ich denke das ist die praktikabelste Lösung des Problems.
      Das müssen sie ja bei ihrem Computer schließlich auch machen und niemand wird sich beschweren.

      Was hältst du davon davon?
      Beim VTI-Image wird das Passwort setzen zur Pflicht.
      Das würde einen großen Teil der Sicherheitsprobleme lösen. (nicht nur beim Webinterface)

    • Hmm; ein anderer Vorschlag: wenn Du mit Passwort auf die Schnittstelle zugreifst, lasse ich den Request durch. Jetzt muss ich nur noch herausfinden, ob ich das so einfach feststellen kann. Wie wäre das? Ein Passwort müssen die iDreamX-User in der Regel ja sowieso setzen. Und Du kannst das Passwort ja problemlos im Request mit absetzen.

      Übrigens betrifft das nicht nur das VTI-Image, sondern OpenWebif auf allen Boxen - der Patch ist im OpenWebif-Repository drin; ich habe zwei Wochen im OpenPLi-Forum auf Widerspruch gewartet, habe aber nur eine positive Antwort bekommen, bevor ich das committet habe.

      (Und ja, ich weiß, dass man über das Web-Interface meine Festplatte leerräumen könnte; nur formatieren habe ich noch nicht gefunden ;))

    • Original von Cimarast
      Hmm; ein anderer Vorschlag: wenn Du mit Passwort auf die Schnittstelle zugreifst, lasse ich den Request durch. Jetzt muss ich nur noch herausfinden, ob ich das so einfach feststellen kann. Wie wäre das? Ein Passwort müssen die iDreamX-User in der Regel ja sowieso setzen. Und Du kannst das Passwort ja problemlos im Request mit absetzen.

      Ja, damit könnte ich leben. Dann würde ich die User dazu zwingen ein Passwort zu setzen, ansonsten können sie iDreamX nicht benutzen. :D

      Original von Cimarast
      Übrigens betrifft das nicht nur das VTI-Image, sondern OpenWebif auf allen Boxen...

      Oh ha, das macht es ja noch dramatischer.

      Vorschlag: Zwingt die Leute doch ein Passwort zu setzen bevor sie das OpenWebif benutzen können. Ich finde das wäre eine hervorragende Sache. Fast jede Box ist schließlich mit dem Internet verbunden und das würde die Sicherheit erheblich verbessern.
      Wenn das Webinterface ohne Passwort aufgerufen wird, gibt es eine entsprechende Meldung aus.

      Wäre das nicht auch viel einfacher, als bestimmte Befehle vom Passwort abhängig zu machen?
      Auch müsste man sich bei anderen- und zukünftigen Befehlen, die auch schützenswert sind, nicht mehr darum kümmern.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von relaht ()

    • Macht es bitte so, dass iDreamX richtig läuft.

      Auch ich bin der Meinung, dass für die Sicherheitsfragen in erster Linie die User verantwortlich sind. Natürlich war das was du gemacht hast Cimerast eine sehr gute Idee und sinnvolle Erweiterung. Nur wenn es auf der anderen Seite Funktionalitäten behindert, die ich "täglich" nutzen möchte, dann möchte ich lieber die Funktionalität wieder haben.

    • Original von relaht
      Wäre das nicht auch viel einfacher, als bestimmte Befehle vom Passwort abhängig zu machen?

      Ich weiß nicht; vor allem kann ich sowas nicht im Alleingang entscheiden - das ändert die Benutzung des Webinterfaces schon grundsätzlich. Aber der Patch, die File-Funktion von einem authentifizierten Request abhängig zu machen, ist recht einfach. Hab's gerade committet.

      Edit: wenn das Ganze sich als nicht praktikabel herausstellt, können wir es immer noch wieder zurückbauen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Cimarast ()

    • Original von Cimarast
      Original von relaht
      Wäre das nicht auch viel einfacher, als bestimmte Befehle vom Passwort abhängig zu machen?

      Ich weiß nicht; vor allem kann ich sowas nicht im Alleingang entscheiden - das ändert die Benutzung des Webinterfaces schon grundsätzlich. Aber der Patch, die File-Funktion von einem authentifizierten Request abhängig zu machen, ist recht einfach. Hab's gerade committet.

      Edit: wenn das Ganze sich als nicht praktikabel herausstellt, können wir es immer noch wieder zurückbauen.


      Was genau hat sich am Request geändert?

      Wenn man ihn über einen Browser macht sieht das ja so aus:

      Quellcode

      1. http://root:passwort@Box_IP/Webinterface_Befehl

      So geht das aber nur über einen Browser, weil er den "Authorization-Request" im Header auflöst.
      Wenn man das mit einem HTTPSocket macht, funktioniert das so nicht.
      Bei iDreamX mache ich das so:

      Quellcode

      1. HTTPSocket.SetRequestHeader "Authorization", "Basic " + EncodeBase64("root:passwort")
      2. result = HTTPSocket.get("http://192.168.1.104/webinterface_befehl")
      Aber vielleicht ist das für das Webinterface ja das Gleiche...!?
      Ich wollte es nur gesagt haben. (Bin leider kein besonders großer html-Spezialist)

      Wenn du eine lauffähige Version vom OpenWebif hast, hätte ich die sehr gerne zum testen. (Oder ist das zip im github schon soweit?)

      Aber noch einmal zum Grundsätzlichen:
      Ich begrüße es sehr, die Diskussion über die Sicherheit neu anzustoßen!
      Ich bin aber fest davon überzeugt, dass es falsch ist, ein kleines Türchen zuzumachen, dem vermeintlichen Einbrecher aber den Generalschlüssel zu überlassen.
      Zumal durch dieses kleine Türchen auch eingeladene Gäste gehen müssen.
      (toller Vergleich - oder? :D)

      Für mich ist das Flickschusterei und hilft nur sehr wenig das eigentliche Problem zu lösen.
      Bitte das nicht als blöde Anmache verstehen! Es soll konstruktive Kritik sein.