Na wer wird denn da gleich verzagen. In dem Artikel steckt auch viel Hoffnung.
Zum einen das hier:
Die Forscher schreiben explizit, dass dies nicht einfach ist und sehr gute Kenntnis der anzugreifenden Software und der Prozessorinfrastruktur des Zielgerätes voraussetzt.
Also verwendet man am besten keine Mainstream Hardware und Software. Und schon hat man das Risiko verringert. Schade nur, dass die Browservielfalt gerade am Kollabieren ist.
Auch hier zeigen die Google Forscher einen Weg auf, ohne gleich alle Hardware in die Tonne zu treten:
Deswegen haben die Chrome-Entwickler sich darauf verlegt, einzelne Webseiten (beziehungsweise Tabs) in getrennten Browser-Prozessen auszuführen. Auf diese Weise verwendet jede Webseite ihren eigenen Adressraum – eine Einschränkung, welche die Prozessor-Hardware kontrolliert und verwaltet. Das verhindert, dass JavaScript-Code, den eine Webseite auf den Rechner des Nutzers lädt, auf den Speicher zugreifen kann, der zum Code anderer Webseiten (oder etwa eines im Browser integrierten Passwort-Managers) gehört.
Man kapselt alles in Prozessen. Durch die MMU getrennt (Jeder Prozess hat seinen eigenen virtuellen Speicherbereich, die nicht überlappen) wird es für einen Angreifer nochmal um ein Vielfaches schwerer an Information aus anderen Webfenstern (=Prozessen) zu kommen.
Aber auch dafür gibt es (wie eigentlich immer) einen Preis: RAM Verbrauch und Ladegeschwindigkeit. Jeder Prozess muss für sich Libraries laden, Bilder, Icons andere Resourcen... und sie im Speicher halten. Die Threads hatten den großen Vorteil, dass alles nur einmal geladen werden musste und dann alle Threads in diesem Prozess auf die gleichen, geteilten Resourcen zugreifen konnten. Nur kriegt man es nicht sicher hin. Aber vielleicht wird das auch über Architektur gelöst. Vielleicht kapselt man die nicht vertrauenswürdigen Teile in eigene Prozesse und verwendet irgendwie geartete IPC (Inter Process Communication) um sie an die sicheren Teile anzubinden. Diese Teile können dann weiter Threads verwenden und damit den Geschwindigkeitsvorteil ausnutzen. Wird man nur ziemlich viel Code umschreiben müssen. Was bei einem Code-Monster wie einem Webbrowser nicht so einfach und bestimmt nicht billig ist.
Liebe Grüße,
Klaren
