Nein, es geht vielmehr um das Gesamtbild. Weiter oben habe ich geschrieben „Firefox bietet daher einen guten Kompromiss zwischen Datenschutz, Sicherheit und Anpassbarkeit“. Die Verwendung von Rust garantiert natürlich keine fehlerfreie Software, aber besonders häufig auftretende Schwachstellen werden eliminiert. Gerade an den kritischen Punkten erzielt man dann mit vergleichsweise wenig Aufwand eine erhebliche Verbesserung.
Verwendet man eine Browser Engine die sogar komplett in Rust geschrieben ist (z.B. servo), dann reden wir von einer potentiellen Angriffsfläche die (im Vergleich zu jetzt) um ein vielfaches kleiner ist. Millionen von Codezeilen sind immun gegen die (aktuell) häufigsten Ursachen für Schwachstellen. Ob dann eine Sandbox innerhalb einer Anwendung dann noch relevant ist, wird sich zeigen.
Hast du mal nachgesehen an welchen Stellen in Chrome/Chromium Rust verwendet wird?
Nachtrag, um diesen Punkt abzuschließen:
Aktuell gibt es nur eine Komponente und die (das wird den ein oder anderen vielleicht überraschen) liegt jetzt außerhalb der Sandbox. Es ist der QR-Code Generator:
Chrome has started shipping some features in Rust; in one case, Chrome was able to move its QR code generator out of a sandbox by adopting a new memory-safe library written in Rust, leading to both better security and better performance.
Könnte es sein, dass die Anzahl der Add-on Installationen, die im Mozialla Store zu sehen sind, über die Firefox Telemetrie gesammelt werden und dass diejenigen Leute, die JShelter installieren, meistens auch Telemetrie deaktivieren? Könnte sein - oder?
Bitte nicht falsch verstehe - ich bin froh über die rege Teilnahme am Thema - aber:
Wie soll bei diesem Thema ein „armes Schwein“ wie ich entscheiden, was sinnvoll einzusetzen ist, wenn selbst die Experten sich derart uneins sind?
Bei genauer Betrachtung über diesen und ähnliche lautende Threads mit den Teils gleichen Protagonisten wird man feststellen, dass sich die Experten so uneinig nicht sind.
Es treffen lediglich zwei „Denkschulen“ bzw. wenn man so will, zwei Typen von Experten aufeinander.
Hat man die identifiziert, kann man sich einer davon anschließen oder mixen. Ganz nach seinem Bedarf
Generell wird es bei diesem Thema keine allgemeingültige ausschließlich richtige Empfehlung geben.
Ich weiß nicht wie die Zahl im Mozilla Store ermittelt wird. Es geht auch ohne Telemetrie. Bspw. dürfte eine Schätzung über Update-Downloads relativ genaue Werte geben, da die wenigsten Benutzer Extensions side-loaden. Aber selbst wenn man großzügig einen Faktor 10 hinhängt, wäre es zu wenig, da ja noch die ganzen anderen Modifikationen (Extensions, Einstellungen usw.) im Browser hinzukommen und ein Teil der Hardware- und OS-Differenzen, welche die Gruppe an JShelter-Benutzern beim Fingerprinting immer weiter aufteilt, bis man in einer sehr kleinen Gruppe landet oder alleine übrig bleibt.
Kann es sein, dass du Forenmeinungen und Meinungen von Hobbyprojekten mit Expertenmeinungen verwechselst? Die meisten Experten sind sich nicht uneins und normalerweise nicht in einem deutschen Datenschutz-Forum anzutreffen, sondern tauschen sich über andere Wege aus (Issue-Tracker, Konferenzen, Mailinglisten, Social Media (Twitter, Mastodon, …), oder via PM)
Ich würde auf einen GraheneOS einfach die Aliexpress App installieren und den Netzwerkzugriff mit Netguard oder RethinkDNS beschränken. Der App dabei keine Berechtigung geben, welche sie nicht unbedingt braucht.
Die TorBrowser Devs sind innovativ und entwickeln resistFingerprinting (RFP), was laut Design Dokumenten ausdrücklich für den TorBrowser und den Einsatz in Kombination mit dem Anonymisierungsdienst konzipiert wurde.
Dann übernehmen die Devs von Mozilla die Idee und programmieren die Fingerprinting Protection (FPP), die jene Probleme vermeiden soll, die sich aus der Fokussierung auf Tor bei RFP ergeben.
Das hatten wir schonmal:
TorProject hat mit FirstPartyIsolate (FPI) ein Konzept zum Schutz gegen Cookietracking entwickelt - ausdrücklich für den Einsatz im TorBrowser konzipiert (also z.B. keine IPv6 Support).
Die Devs von Mozilla haben die Idee aufgegriffen und mit dFPI ein angepasstes Konzept für den normalen Firefox umgesetzt. Außer beim TorBrowser selbst verwendet heute kein Firefox Nutzer mehr FPI sondern statt dessen dFPI.
Mit RFP und FPP wird es genauso laufen. In ein paar Monaten wird sich die Erkenntnis durchsetzen, das RFP ausdrücklich für den TorBrowser konzipiert ist und FPP für den normalen Firefox Nutzer. Bei einigen Experten früher, bei anderen später.
Ja, das ist schwierig. Auch unter Experten/Entwicklern ist es oft schwer, sich von bestimmten Denkmustern zu lösen - obwohl es ja gerade im digitalen Bereich ständig Veränderungen gibt. Man kann entweder eher oberflächlich bleiben oder sich intensiv mit einem Thema auseinandersetzen. In jedem Fall ist es wichtig, die Vor- und Nachteile aller Optionen abzuwägen, um eine Entscheidung zu treffen. Sollte man dann unzufrieden sein oder sich neue Entwicklungen ergeben, kann man das Thema erneut bewerten und ggf. etwas ändern. Wie @jdevlx schon schrieb, ist ja nichts in Stein gemeißelt Letztendlich ist es sowieso eine Risikoabschätzung, ob bestimmte Ereignisse eintreten oder nicht und das hängt stark davon ab, was der Benutzer macht.
FFI (Browser werden immer einen Teil Code in anderen Sprachen haben und jede Menge Drittanbieter-Code)
Zahlreichen Interaktionen mit Kernel und anderen Systemkomponenten die überwiegend in C/C++ geschrieben wurden
60% (!) aller RCE-Vulnerabilitäten im Content-Prozess in Chromium waren in der JIT-Engine V8. Das sind nur selten memory corruption bugs und allermeistens logische Bugs. Dagegen hilft Rust nichts. Nur um das nochmal zu betonen: gegen 60% (!) der RCE-Vulnerabilitäten hilft Rust nicht!. Das ist ein generelles Problem mit JIT und betrifft deshalb nicht nur Chromium. Chromium entwickelte deswegen eine extra V8-Sandbox (Siehe https://v8.dev/blog/sandbox ).
Logische Bugs außerhalb von JIT
Aus diesen Gründen werden immer Sandboxing und Exploit Mitigations notwendig sein. Ich denke, das sollte auch klar machen, warum die 11% Rust-Code in Firefox nicht so einen großen Effekt haben wie du vielleicht vermutest und andere Sicherheitsmechanismen mehr Gewicht haben.
Zudem ist eine komplette Browser-Engine in Rust Zukunftsmusik und wenn in Zukunft jedes Gerät MTE hat, fallen schon mal ganze Bug-Klassen bei speicherunsicherem Code weg, was den Unterschied zwischen Rust und C+±Code massiv reduziert. MTE ist der größte Fortschritt bei Exploit Mitigations den es bisher gab. Google Pixel 8 (Pro) mit GrapheneOS und Vanadium ist der einzige Browser+OS mit Verwendung von MTE, deaktiviert JIT um die logischen Bugs in V8 zu verhindern, aktiviert zusätzliche Exploit Mitigations und ist in Summe der mit Abstand sicherste Browser auf dem Markt.
Eine einzelne Komponente zu betrachten und die Erkentnisse daraus anschließend auf das Gesamtbild zu übertragen, führt zu fehlerhaften Schlussfolgerungen. Der JIT-Compiler ist ein Teil einer JavaScript-Engine. Die JavaScript-Engine ist ein Teil der Browser-Engine. Die Browser-Engine ist ein Teil des Browsers.
Insgesamt lassen sich durch den Einsatz von Rust rund 70 % aller Schwachstellen vermeiden - das beinhaltet auch die restlichen 40 % aus dem JIT Compiler. Nicht nur, weil Speicherfehler und Pufferüberläufe nicht möglich sind, sondern auch weil ganze Komponenten fehlen (z.B. der Garbage Collector, der nicht nur ein Mal für gravierende Schwachstellen verantwortlich war). Natürlich wird es nicht alle Probleme lösen, aber eben die häufigsten. Wie das in der Realität konkret aussieht, erkennt man an den Zahlen zu Android, die Google nennt: Durch die Migration zu Rust-Code konnten die gefundenen Schwachstellen von 223 (2019) auf 85 (2022) reduziert werden. Keine einzige der gefundenen Schwachstellen lag im neuen Rust-Code, sondern im alten C/C++ Code. Diese Zahlen stammen nicht von mir, sondern wie gesagt von Google.
Eine Sandbox (CVE-2024-3157 = out of bounds) oder MTE (CVE-2023-6241 = use after free , ausführliche Analyse → GitHub) sind immer noch keine unüberwindbaren Barrieren. Ausbrüche aus der Sandbox sind auch 15 Jahre nach der Einführung durchaus möglich und nicht selten, da das zugrundeliegende Problem (Stichwörter: out of bounds, use after free, heap buffer overflow) nicht beseitigt wird. Das wird auch im Google Paper „Secure by Design: Google’s Perspective on Memory Safety“ (Google Security Engineering Technical Report, 04.03.2024) als das eigentliche Problem genannt:
Exploit mitigations complicate exploitation of memory safety vulnerabilities, rather than fixing the root cause of these vulnerabilities.
[…]
After 50 years, memory safety bugs remain some of the most stubborn and most dangerous software weaknesses. As one of the leading causes of vulnerabilities, they continue to result in significant security risk. It has become increasingly clear that memory safety is a necessary property of safe software.
Das bedeutet, dass zwangsläufig auch in der V8-Sandbox bald eine Schwachstelle gefunden wird, die einen Ausbruch aus der Sandbox ermöglicht. Die Ursache dafür werden auch wieder Speichergrenzen sein. Für die JavaScript-Engine V8 könnte es eine Lösung geben, die laut dem Artikel wegen der Performance aktuell noch keine Option ist - wobei Rust in letzten Jahren deutlich performanter geworden ist und daher tatsächlich als Nachfolger zu veralteten C/C++ Code gesehen werden kann und bereits in vielen unterschiedlichen Projekten verwendet wird.
Similarly, disabling the JIT compilers would also only be a partial solution: historically, roughly half of the bugs discovered and exploited in V8 affected one of its compilers while the rest were in other components such as runtime functions, the interpreter, the garbage collector, or the parser. Using a memory-safe language for these components and removing JIT compilers could work, but would significantly reduce the engine’s performance (ranging, depending on the type of workload, from 1.5–10× or more for computationally intensive tasks).
Wie hilft das dem TE nun bei seiner Entscheidung? In der Regel erfordert die Ausnutzung einer dieser Sicherheitslücken das Aufrufen einer präparierten Webseite. Diese Manipulation kann entweder die gesamte Webseite betreffen oder ein Drittanbieter-Skripte, welches dort eingebettet ist.
Du forderst mich zum wiederholten Male auf den Browser als ganzes zu betrachten, und doch ist dein einzig nennenswertes Argument der wenige Rust-Code in Firefox. Wie passt das zusammen? Ich betrachtete Sandboxing, IPC, Kernel-Attack-Surface, Exploit Mitigations, Speicherallokatoren, Compiler-Hardening und natürlich auch Memory Safety. Wenn du dir meine Kommentare noch einmal durchliest, wirst du sehen, dass ich ihn als ganzes betrachte. Dass ich auch hin und wieder speziell auf wichtige Teile hinweise, um beispielsweise den Einfluss von Memory-Safety besser einordnen zu können, ändert daran nichts. Dass du selbst fast nur über das Thema Memory-Safety schreibst, spricht eher für die nicht-ganzheitliche Betrachtung die du mir vorhältst.
Es gibt keine restlichen 40% aus dem JIT-Compiler. Die 60% die ich nannte sind der Anteil an JIT-Bugs aller RCE-Vulnerabilites im Content/Renderer-Prozess. Dabei hilft dir kein Rust. Die Absicherung des Content-Prozess ist eine der wichtigsten Maßnahmen beim Thema Browser-Sicherheit und auch der wichtigste für Sandboxing.
Ich habe schon gesagt, dass die meisten Bugs in Browsern Memory-safety related sind, aber die Frage ist wo sind die gravierendsten, wo starten sie und welche Sicherheitsmaßnahmen gibt es um diese einzudämmen. Du schreibst so als sei FF größtenteils memory-safe, dabei ist nur ein kleiner Teil in Rust und wenn du dir bekannt gewordene Exploit-Chains in Browsers anguckst, wirst du sehen, dass dir der kleine Rust-Anteil niemals all die anderen Sicherheitsbereiche in denen Chromium Jahre voraus ist ausgleicht.
Genauso wenig wie Rust. Schön, dass du eine von wenigen Fällen gefunden hast, wo MTE nicht gegriffen hat. Ändert nichts daran, dass es die größte Innovation im Bereich Exploit Mitigations ist.
Es sind doch jetzt schon in Chromium mehrere Zero-Days für eine erfolgreiche Exploit-Chain notwendig. Dazu musst du dann bei JIT-Code zwei Sandboxen überwinden. Und wie gesagt, Rust hilft dir bei V8 nur in seltenen Fällen. Sandboxing ist ein enorm wichtiger Anteil der Sicherheit, dass du das immer wieder herunterspielst, nur weil sie in C/C++ geschrieben ist, ist einfach nicht valide, da sie trotzdem gut funktioniert. Und dass ich schon zum wiederholten Male gesagt hab, dass Rust gegen die meisten Sandbox-Escapes (logische IPC-Bugs und Kernel-Attacks) nichts hilft, wird auch ignoriert. Das ist was Manfred Paul, der 2024 die 4 populärsten Browser exploitet hat sagt: “To be fair, browser sandboxes are a huge part of these mitigations - and for that I only did the Firefox one (the other stuff was Renderer-Only)” . Er meint damit natürlich den Renderer/Content-Prozess und nicht Servos/Firefoxs Webrender, was im GPU-Prozess ausgeführt wird.
Ob er daraus Erkenntnisse zieht, weiß ich nicht. Ich kann die einseitige Darstellung von Firefox’s Sicherheit nur so nicht stehen lassen.
Sehe ich genauso. Welchen konkreten Vorteil bieten hier nun sichere Programmiersprachen? → siehe das oben verlinkte Google Paper.
Das habe ich nicht geschrieben. Es war (bisher) immer die Rede von Rust u.a. an kritischen Punkten und einen Gesamtanteil von 11 % bzw. 11,5 %.
Ich muss mich an dieser Stelle korrigieren. Die 11 % sind nicht korrekt. Wenn man sich das Chart genauer ansieht, dann sieht man auch Sprachen wie HTML oder JavaScript. Einige dieser Sprachen arbeiten in höheren Abstraktionsebenen und einige dieser Klassen/Dateien liegen im Ordner /testing und können daher ignoriert werden. Schließt man den /testing Ordner aus und führt das Skript zur Berechnung aus, dann kommt man auf diese Verteilung:
Wichtig sind hier eigentlich nur die Anteile von C, C++ und vielleicht auch Teile die aktuell in Assembly geschrieben sind. Belassen wir es aber mal beim direkten Vergleich der Codezeilen Rust, C und C++, dann landet man bei einem „Migrationsstand“ von 21 %.
Rust 21,92 %
C 27,15 %
C++ 50,94 %
Man muss nicht zwangsläufig alles mit Rust ersetzen, um die Sicherheit spürbar zu erhöhen. Google (als Gründungsmitglied der Rust Foundation) hat dazu erst vor kurzem 1 Million Dollar bereitgestellt, um „die Interoperabilität von Rust- mit Legacy-C++ Code zu erhöhen“ (Quelle). Orientiert man sich an den Rules-of-Two, müsste man „nur“ in die untrustworthy inputs nach Rust migrieren.
Genau hier liegt ein Missverständnis vor. Die Speicherfehler, welche dort die gravierenden Schwachstellen verursacht haben (out of bounds und use after free), sind in Rust praktisch nicht vorhanden (= Secure-by-Design) → siehe das oben verlinkte Google Paper.
Egal was man tut, sie lösen halt nicht das ursprüngliche Problem und widerspricht dem Secure-by-Desgn Ansatz. Google sagt in dem Paper:
Exploit mitigations complicate exploitation of memory safety vulnerabilities, rather than fixing the root cause of these vulnerabilities.
Ist das nicht eindeutig?
Google kommt außerdem zu diesem Schluss:
[…] we expect that high assurance memory safety can only be achieved via a Secure-by-Design approach centered around comprehensive adoption of languages with rigorous memory safety guarantees. We see no realistic path for an evolution of C++ into a language with rigorous memory safety guarantees that include temporal safety. As a consequence, we are considering a gradual transition of C++ code at Google towards other languages that are memory safe. Given the large volume of pre-existing C++, we believe it is nonetheless necessary to improve the safety of C++ to the extent practicable. Quelle
Mit anderen Worten: „Wir setzen aufgrund der großen Codebasis auch weiterhin darauf, den C++ Code sicherer zu machen“. Das ist nicht verkehrt, da überall dort wo jetzt aktuell in diesem Moment unsicherer Code aufgerufen wird, eine Sandbox natürlich einen Vorteil bietet.
Google sagt auch ganz klar, dass mit dem aus der Sandbox extrahierten QR-Code Generator, dieser nun eine höhere Sicherheit und eine bessere Performance bietet - beides wird erreicht durch die im Paper genannten Speichergarantien und den geringeren Overhead. Wie passt das zusammen?
Man kann davon ausgehen, dass weitere Komponenten folgen werden - natürlich nicht alle, aber einige. Irren sich Googles Softwareingenieure und reduzieren sie in Wahrheit die Sicherheit? Man kann Google wirklich viel vorwerfen, aber hier in diesem Punkt eher nicht.
Hab ich zur Kenntniss genommen. Ändert aber nichts an der Strategie, den Statements der Großen oder den schon jetzt spürbaren Auswirkungen dieser Umstellung:
„Based on historical vulnerability density statistics, Rust has proactively prevented hundreds of vulnerabilities from impacting the Android ecosystem“ (Dave Kleidermacher, Google Vice President of Engineering, Android Security & Privacy, Quelle)
„While Rust may not be suitable for all product applications, prioritizing seamless interoperability with C++ will accelerate wider community adoption, thereby aligning with the industry goals of improving memory safety“ (Royal Hansen, Google Vice President of Safety & Security, Quelle)
Kein Sorge, ich bin jetzt mit dem Thema fertig. Die Fakten liegen soweit auf dem Tisch. Ich kann nicht mehr tun, als aus diesen Statements und Papers zu zitieren und wichtige Passagen oder Schlüsselwörter markieren. Es ist völlig in Ordnung, wenn man mit den Google Statements und Papers nicht einverstanden ist und die Sache anders sieht, aber vielleicht sollte man den Kontakt mit den Autoren suchen.
Schon wieder dreht sich alles um Rust. Trotz meiner ausführlichen Darlegungen über verschiedenste Sicherheitsaspekte, die alle wichtig für Browser-Sicherheit sind, ist es dein einziges Argument. Ich habe doch ausführlich dargelegt, warum gegen einen Großteil der wichtigen Vulnerabilitäten (60% der Content/Renderer-RCE und die allermeisten Sandbox-Escapes) Rust im Browser nicht hilft. Und das selbst bei 100% Rust-Code im Browser, wovon wir Meilenweit entfernt sind. Also kommen noch all die Probleme von deinen genannten 80% C/C++ -Code (relativ im Vergleich zu 20% Rust) in FF hinzu, für die andere Sicherheitsaspekte umso wichtiger sind, in denen Chromium die Nase deutlich vorn hat. Zudem handelt es sich bei den 80% nur um Code-Zeilen im Browser. Die Interaktionen mit anderem Memory-Unsafe-Code ist noch gar nicht mitgezählt.
Ich weiß ganz genau welche Vorteile sie bieten. Aber ich weiß auch welche nicht.
Ja, es liegt ein Missverständnis vor. Mein Kommentar bezog sich natürlich nicht auf den einen spezifischen Fehler, weil einzelne Fehler irrelevant für eine Diskussion über ganzheitliche Sicherheit sind, sondern auf deine Aussage, dass „Sandbox oder MTE keine überwindbaren Hürden sind“. Rust ist auch keine unüberwindbare Hürde, siehe die vielen logischen Bugs, oder die zahlreichen Interaktion mit unsafe Code wie dem Kernel.
Danke.
Ich bin mit den Statements in den Papers OK. Womit ich nicht daccord bin, ist deine Einordnung in das Gesamtbild Browser-Sicherheit und insbesondere den Sicherheits-Einfluss von Rust in FF in seinem heutigen Zustand (nicht einer hypothetischen Zukunft) vs. all die anderen Aspekte, den du aus Gründen die ich dargelegt habe, überschätzt, und andere Aspekte wichtiger sind. Chromium hat in allen anderen wichtigen Bereichen die Nase vorne. Die Sicherheitsprobleme von Firefox sind z.B. unter Android so gravierend, dass GrapheneOS sich genötigt fühlt, auf der offiziellen Homepage von der Verwendung explizit abzuraten:
Offizielles Statement von GrapheneOS indem es aufgrund Sicherheitsmängel von Gecko-basierten Browsern abrät
Avoid Gecko-based browsers like Firefox as they’re currently much more vulnerable to exploitation and inherently add a huge amount of attack surface. Gecko doesn’t have a WebView implementation (GeckoView is not a WebView implementation), so it has to be used alongside the Chromium-based WebView rather than instead of Chromium, which means having the remote attack surface of two separate browser engines instead of only one. Firefox / Gecko also bypass or cripple a fair bit of the upstream and GrapheneOS hardening work for apps. Worst of all, Firefox does not have internal sandboxing on Android. This is despite the fact that Chromium semantic sandbox layer on Android is implemented via the OS isolatedProcess feature, which is a very easy to use boolean property for app service processes to provide strong isolation with only the ability to communicate with the app running them via the standard service API. Even in the desktop version, Firefox’s sandbox is still substantially weaker (especially on Linux) and lacks full support for isolating sites from each other rather than only containing content as a whole. The sandbox has been gradually improving on the desktop but it isn’t happening for their Android browser yet.
ACHTUNG!
„Zwischen den Zeilen“ der folgenden Frage steht NICHTS! Ich möchte einfach nur wertneutral etwas erfragen und befürchte, dass aufgrund der Natur dieser Frage, diese eventuell missverstanden werden könnte… ACHTUNG!
Den obigen Antworten (Herzliches Danke dafür!) entnehme ich, dass Chrome-basierende Browser hinsichtlich Sicherheit den Firefox-basierenden überlegen sind.
Weiterhin nehme ich an, dass das Surfen im DeepWeb/DarkWeb/Nicht-Clear-Web „gefährlicher“ ist, als auf den Seiten des Heise-Verlags zu schmökern (keine Werbung, nur so was mir gerade in den Kopf kam).
Sowohl der Tor-Browser als auch der Mullvad-Browser, der im Prinzip ein Tor-Browser ohne das „Tor“ ist, sind Firefox-Sprößlinge.
Welcher Grund kann die Entscheidung des Tor-Projektes, von denen ich annehme, dass sie wissen, was sie tun, haben, diese Browser-Basis zu wählen?
Das ist historisch gewachsen. Tor Browser Bundle entstand 2007. Damals war Firefox viel beliebter als heute und fast vier Jahre alt. Chromium hatte 2008 erst sein erstes Release, steckte also noch in den Kinderschuhen. Google begann erst seit ca. 2010 Sicherheit ernst zu nehmen (Aurora Incident als Anstoß). Um 2016 herum begann das Tor Uplift Project durch das immer mehr Tor Browser-Patches zu Firefox upgestreamt wurden mit großer Hilfe von Mozilla. Ohne Mozillas maßgebliche Hilfe wäre Tor Browser bei der heutigen Komplexität von Browsern vermutlich nicht mehr in der Lage alle Browser-Patches komplett alleine zu entwickeln und maintainen. Ob Google das gleiche für Tor Browser tun würde bezweifle ich mal. Zudem wäre der Aufwand eines Umzugs zu Chromium immens. Eine Überprüfung vor ein paar Jahren ergab auch einige Probleme im Chromium-Design, die einem Port im Weg stünden.
Für das Dark Web im Tor Browser den Security Slider verwenden (wenn möglich Safest Mode) und Whonix. Whonix läuft in einer VM, also muss ein Angreifer für einen Host-Compromise zunächst den Browser überwinden, was schon nicht so einfach ist, und einen VM-Escape haben, was schon sehr schwierig ist (und für den VM-Escape ist meistens Root notwendig, also benötigt er noch Privilege Escalation). Damit solltest du mehr als ausreichend sicher sein, wenn du keine Opsec-Fails machst.
Danke für die Erklärungen!
Aufgrund einiger „High Target“-Nutzer des Tor-Browsers denke ich aber, dass das Tor-Projekt weiß, was es tut, wenn es die Firefox-Basis beibehält. Die Alternative wäre, Verfolgte aus Kostengründen möglicherweise ans Messer zu liefern.
Mein Hinweis auf das DarkWeb war nur zur Unterstreichung der Notwendigkeit einer erhöhten Sicherheit hinsichtlich des Browser gemeint.
Ich bin kein Kunde von SilkRoad
GrapheneOS:
Gibt es dort eine bessere Alternative zu Vanadium, wenn einem neben der Sicherheit auch um die Privacy wichtig ist?
Ich denke nicht, dass sie eine realistische Wahl haben.
Wohl eher aus Machbarkeitsgründen.
Vanadium setzt auch auf Privacy, hat zurzeit aber noch mehr Stärken im Bereich Sicherheit. Privacy-Features werden weiter ausgebaut. Wenn man Private-Browsing-Mode verwendet sollte es für Nutzer aber auch schon zurzeit gut genug sein. Wenn du mehr Privacy- und andere Features wie Sync willst empfiehlt GrapheneOS Brave.
Es geht um die „Fehlertypen“ wie „out of bounds“, „use after free“, „heap buffer overflow“. Das sind die häufigsten Auslöser für Schwachstellen, um bspw. aus Sandboxen auszubrechen oder beliebigen Code auszuführen. 70 % aller Schwachstellen entstehen durch dieser „Fehlertypen“. Mit Rust gibt es diese „Fehlertypen“ nicht (= Speichergarantien).
Die Gewichtung stammt nicht von mir: Eine in Rust geschriebene Browser-Kompontene ist sicherer als eine „Sandboxed C++ Komponente“. Je mehr Komponenten gegen die o.g. „Fehlertypen“ immun sind, umso kleiner ist die Angriffsfläche.
@mcc: Gestern gab es bei heise.de ein vielleicht hilfreiches Interview mit Manfred Paul:
Welchen Browser benutzen Sie denn persönlich?
Wichtig beim Browser ist nicht, welchen man nutzt, sondern viel wichtiger ist das „Wie“. Ich würde da ungern eine Empfehlung aussprechen. Man sollte seine Software aktuell halten, nicht auf jeden Link klinken und Ähnliches. […] Für mich ist der Browser nicht Teil einer aktiven Sicherheitsentscheidung, sondern für mich und die allermeisten geht es da auch um Gewohnheit und Komfort.
Allerdings hält der Hacker sich ja sehr bedeckt. Wie man sich konkret verhalten kann/soll beim Browsen wird so direkt nicht erwähnt…oder übersehe ich etwas?
Im wesentlichen sind es die gleichen Regeln wie auch schon seit Jahren: Nicht auf jeden Link klicken, nicht alles mögliche herunterladen, nicht wahllos alle PDFs/E-Mail Anhänge öffnen, … Den gesunden Menschenverstand einschalten und immer etwas skeptisch sein. Zusätzlich verschiedene Browser (u.a. Tor/Mullvad) je nach Anwendungsfall, ein guter Adblocker und möglichst alles blocken, was für eine Webseite nicht notwendig ist (z.B. uBlock Origin im Medium Mode).
14.05.2024 Nachtrag zu
Die JavaScript Engine V8 welche in Chromium eingesetzt wird, hat erwartungsgemäß eine schwerwiegende Sicherheitslücke: Speicherfehler. Die Sandbox (wird seit 06/2022 verwendet; hat 04/2024 den experimentellen Status verlassen) ist wirkungslos, da das eigentliche Problem nicht gelöst wird. Anscheinend gibt es sogar einen Exploit in freier Wildbahn. Dieses Jahr ist das nun bereits die zweite (01/2024 und 05/2024) schwerwiegende Sicherheitslücke in der V8 Engine - inkl. Ausbruch aus der Sandbox. Wobei man alle vorherigen nicht wirklich zählen sollte, da die Sanbox zu dem Zeitpunkt noch als experimentell gekennzeichnet war.
Drittes kritisches Sicherheitsupdate innerhalb einer Woche. Wieder die V8-Engine, dieses mal zwar kein Ausbruch aus der Sandbox, aber beliebiger Code innerhalb ausführbar. Ursache: Type-Confusion/Speichergrenzen. Quelle: heise.de
