Firefox Nightly: Lokaler Dateizugriff in eigenem Prozess für mehr Sicherheit
Die Multiprozess-Architektur Electrolysis (e10s) erreicht nicht nur immer mehr Nutzer, auch die Entwicklung weiterer Prozesse schreitet voran. Als zusätzliche Sicherheitsmaßnahme hat Mozilla nun einen eigenen Content-Prozess für den lokalen Dateizugriff in der Nightly-Version von Firefox 53 aktiviert.
In Firefox 48 hat die neue Multiprozess-Architektur Electrolysis, kurz: e10s, erstmals eine finale Version von Firefox erreicht und wird seit dem für immer mehr Nutzer freigeschaltet. Bisher trennt die Multiprozess-Architektur lediglich Browser und Content voneinander, das heißt, nach wie vor teilen sich alle Webseiten einen gemeinsamen Content-Prozess, so dass es insgesamt zwei Prozesse gibt (beziehungsweise drei inklusive Plugin-Container, sofern NPAPI-Plugins aktiv sind).
In der Nightly-Version von Firefox sieht dies schon etwas anders aus. Während dort für Nutzer von Windows 7 und höher der Quantum Compositor bereits Aufgaben der GPU an einen eigenen Prozess auslagert, und Mozilla daran arbeitet, einen zweiten Content-Prozess standardmäßig zu aktivieren, ist in der Zwischenzeit eine weitere Änderung gelandet, welche einen eigenen Content-Prozess nur für Aufrufe via file://-Protokoll aktiviert.
Diese Maßnahme dient der Sicherheit. Sollte durch ein Sicherheitsproblem ein Content-Prozess kompromittiert werden, kann dieser dadurch trotzdem nicht genutzt werden, um auf lokale Dateien zuzugreifen. Dieser spezielle Content-Prozess besitzt ausschließlich Lese-Rechte auf dem System.
Der zusätzliche Content-Prozess ist derzeit standardmäßig nur in Nightly-Versionen aktiviert und wird über den Schalter browser.tabs.remote.separateFileUriProcess in about:config gesteuert.
Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, firefoxosdevices.org sowie sozone.de.
Hallo Sören,
im Artikel schreibst Du:
„Sollte durch ein Sicherheitsproblem ein Content-Prozess kompromittiert werden, kann dieser dadurch trotzdem nicht genutzt werden, um auf lokale Dateien zuzugreifen. Dieser spezielle Content-Prozess besitzt ausschließlich Lese-Rechte auf dem System.“
Meine Frage hierzu: Sind bei Umstellung des von Dir genannten Schalters „browser.tabs.remote.separateFileUriProcess“ wirklich ALLE Zugriffe auf lokale Dienste wie „http://localhost…“ oder „http://192.168.1.1…“ auf dem eigenen Rechner gesperrt? Wie sieht es aus mit Zugriffen auf den Router oder auf andere Dienste im lokalen Netzwerk (LAN)?
Ich frage deshalb, weil andernorts eine (doch eher umständliche) Lösung über die Firefox Addons uBlock Origin und uMatrix empfohlen wird.
Siehe: https://www.privacy-handbuch.de/handbuch_21g.htm
Handelt es sich hier und dort um dieselbe Problematik?
Hallo,
ich zitiere aus dem Artikel und hebe eine Stelle besonders hervor: "welche einen eigenen Content-Prozess nur für Aufrufe via file://-Protokoll aktiviert"
Lokaler Dateizugriff meint in diesem Kontext immer über das file://-Protokoll, ein Zugriff via http://localhost ist in dem Sinne nichts anderes als der Besuch einer Webseite über das HTTP-Protokoll.
Gesperrt wird außerdem nichts. Es geht darum, dass der Zugriff in einem isolierten Prozess stattfindet, der keine Schreib-Berechtigung besitzt.
Das hat gar nichts mit dem zu tun, worum es hier geht.