Design: Sicherheit erklären

Hi!

Ich habe eine Frage: Wäre es in diesem Zusammenhang sinnvoll, auf Folgendes einzugehen:

"Abgesehen davon können Programme, die auf Quellsprachenebene undefiniertes Verhalten aufrufen, in WebAssembly-Programme kompiliert werden, die alles andere tun, einschließlich des Verfälschens des Inhalts des Anwendungs-Heaps, Aufrufen von APIs mit beliebigen Parametern, Hängen, Überfüllen oder Verbrauch beliebiger Mengen von Ressourcen (innerhalb der Grenzen)."
https://github.com/WebAssembly/design/blob/master/CAndC++.md#undefined-and-implementation-defined-behavior

Woran ich denke, ist die Bereitstellung von Kontext / Referenzen, die (vielleicht) für Webentwickler mit nicht-muttersprachlichem Hintergrund von Nutzen sein können - durch Beispiele und weitere Diskussionen.

Zum Beispiel MSC14-C von CERT Keine unnötigen Plattformabhängigkeiten einführen listet vier verschiedene Arten von nicht portierbarem Verhalten (Unspezifiziertes Verhalten, Undefiniertes Verhalten, Gebietsschemaspezifisches Verhalten, Implementierungsdefiniertes Verhalten) mit Beispielen auf. MSC15-CPP. Verlassen C-Compiler können einige Rundumprüfungen stillschweigend verwerfen , was in diesem Zusammenhang besonders bemerkenswert sein kann (Robert Seacord erörtert dies ausführlicher in "Silent Elimination of Bounds Checks" ).

tiefergehende Behandlungen:

• Was jeder C-Programmierer über undefiniertes Verhalten wissen sollte #1/3
• Was jeder C-Programmierer über undefiniertes Verhalten wissen sollte #2/3
• Was jeder C-Programmierer über undefiniertes Verhalten wissen sollte #3/3
• Eine Anleitung zu undefiniertem Verhalten in C und C++, Teil 1
• Eine Anleitung zu undefiniertem Verhalten in C und C++, Teil 2
• Eine Anleitung zu undefiniertem Verhalten in C und C++, Teil 3

Andere potenziell relevante Ratschläge:

• INT02-CPP.
• INT08-CPP.
• INT10-CPP.
• INT18-C.
• INT32-C.

Würde ein eindeutiger CSP-Header zur Steuerung von Wasm-Dateien helfen? Ich habe das Gefühl, dass Websitebesitzer möglicherweise verhindern möchten, dass Unterressourcen wasm laden.

Das ist eine interessante Frage. Auf jeden Fall sollten wir Websites erlauben, das dynamische Laden und die Evaluierung von WebAssembly in den gleichen Fällen zu verbieten, in denen sie eval und Function verbieten (dies würde einfach aus der ES6-Modulintegration und CSP-Prüfungen auf Loader herausfallen

Es lohnt sich, auf #53 hinzuweisen, um einige der Sicherheitsbedenken beim dynamischen Verknüpfen zu diskutieren.

@jfbastien yup CORS und SRI sollten Entwicklern nach Möglichkeit zur Verfügung stehen.

@lukewagner Ich denke, es hängt von dem Zugriff auf die Ressource auf niedriger Ebene ab, den wasm ermöglicht. Wie Sie sagen, ist es nur JS. Es scheint jedoch, dass das übergreifende Ziel von Wasm dem Maschinenmetall am nächsten kommt; eine CSP-Direktive zur globalen Kontrolle wäre wünschenswert.
Im Laufe der Zeit wäre auch eine detailliertere Herangehensweise an die anderen Funktionen besser.

Die anderen unmittelbaren Möglichkeiten sind die Verwendung der Berechtigungs-API für andere Zugriffe auf niedriger Ebene.

Naja, nah am Metall in Bezug auf die Leistung. Aus Sicherheits-, Berechtigungs- und Sandboxing-Perspektive gibt es keine Diskussion darüber, dass WebAssembly von JS abweicht.

Das war nicht das Gefühl, das ich sowohl von den Post-MVP- als auch von Brendan Eichs-Ankündigungen hatte, aber ok :+1:

Ich denke, was Sie meinen, ist, dass wir uns darauf geeinigt haben, dass die WebAssembly-Semantik nach dem MVP von dem abweichen darf, was in JS effizient polygefüllt werden könnte. Diese Divergenz würde sich auf Rechenfunktionen beziehen und nichts mit Sicherheit/Berechtigungen zu tun haben. Das bedeutet, dass neue Funktionen zwar nicht _effizient_ polygefüllt werden konnten, aber _konnten_ von einem WebAssembly-Interpreter simuliert werden, der in JS ( Emterpreter-Stil ) geschrieben ist. Es wäre wahrscheinlich gut, diesem Effekt einen Hinweis hinzuzufügen, um das einzugrenzen, was wir mit "von JS abweichen" meinen.

Ja, das wäre sicherlich eine gute Verbesserung des Dokuments, ich hätte das Dokument vielleicht zu schnell gelesen, aber es schien das nicht klar zu machen.

Ich glaube, es war einer von Eichs Gesprächen über das Hinzufügen von mehr Threading- und Speicherfunktionen, die mich glauben ließen, dass wasm neue Funktionen bekommen würde. Ich vermute, dass diese wahrscheinlich auch zu JavaScript hinzugefügt werden und der üblichen Überprüfung neuer Funktionen unterliegen.

"Nicht anders als Sicherheits-POV als JS" ist jetzt in Web.md enthalten .

Ich würde die Unterscheidung lieber besser erklären. Sich auf JS zu beziehen, ist aus einer eigenständigen Perspektive nicht sehr schön, und ich denke, wir möchten die Sicherheitsoberfläche von JS reduzieren (z. B. ursprungsübergreifende Skripte und dergleichen).

Dazu komme ich, nachdem ich auf der CppCon einen Vortrag darüber gehalten habe :-)

Für diejenigen, die an der Verwendung von WebAssembly als Ziel für kryptografische Implementierungen interessiert sein könnten, wäre es nützlich, die Unterschiede zwischen dem JS/asm.js-JIT und dem WebAssembly-JIT in Bezug auf die Unterstützung von Implementierungen mit fester Zeit zu erläutern. Ich denke speziell an Operationen wie Bitshifts, nach JIT eingeführte Verzweigungen, bedingte Sprünge oder Lookups oder andere Änderungen, die das JIT vornehmen kann, die zu Timing-Lecks führen könnten.

Wenn Entwickler von WebAssembly keine Erwartungen haben sollten, Implementierungen mit fester Zeit besser zu unterstützen, als wir es bereits mit asm.js haben, wäre es hilfreich, dies als Teil der Ausarbeitung der Sicherheitsauswirkungen von WebAssembly für das Anwendungsdesign anzugeben. Wenn WebAssembly einige Möglichkeiten bietet, Anwendungen besser zu härten als das, was derzeit existiert (jetzt oder nach MVP, ich habe die Spezifikation nicht ausführlich gelesen), wäre es auch großartig, darauf näher einzugehen. https://github.com/jedisct1/libsodium.js/issues/24#issuecomment -128002942 enthält weitere Informationen zu den bestehenden Problemen rund um clientseitige JavaScript-Krypto.

Das ist übrigens alles sehr spannend. :D

Vereinbart, dass wir eine klärende Erklärung haben sollten, wie von @dconnolly vorgeschlagen. Bisher haben wir diskutiert, dass es für MVP keine Garantien dafür gibt, was das JIT kann/nicht kann, und dass Konstantzeitalgorithmen zumindest für MVP nicht die richtige Verwendung von wasm sind. Dies kann sich in Zukunft ändern.

Meine derzeitige Meinung ist, dass externe APIs (wie sie vom Einbetter wie der Webplattform angeboten werden) besser positioniert sind, um solche Garantien zu bieten, da Sie oft Assembler und ein gutes Verständnis der Mikroarchitektur benötigen, um richtigen zeitkonstanten Code zu schreiben. Betrachten Sie das extreme Beispiel einer CPU, die eine dynamische Binärübersetzung durchführt: WebAssembly kann nicht garantieren, was eine CPU kann/nicht kann. Meiner Ansicht nach hat WebAssembly ein zu hohes Abstraktionsniveau, um echten zeitkonstanten Code auszudrücken.

Cool, danke für die Aufklärung. Einverstanden, dass Webplattform-APIs der beste Ort für solche Dinge sind, insbesondere für Primitive ( Notizen ). Wir freuen uns auf diese zusätzliche Sprache zum Thema Sicherheit und wird allen anderen helfen, die die Auswirkungen von WebAssembly falsch interpretieren könnten. :+1:

@jfbastien , gilt alles, was Sie über wasm-Timing-Garantien gesagt haben, heute noch?

Ich sehe in den aktuellen Dokumenten, dass deterministische Ausführung ein Ziel ist, außer in einer kleinen Liste dokumentierter Randfälle, die für Konstantzeitalgorithmen potenziell positiv klingt. webassembly.org/docs/security erkennt jedoch an, dass Timing-Angriffe möglich sind, und listet einige potenzielle zukünftige Abschwächungen auf. noch" oder "Es können Seitenkanal-Schwachstellen eingeführt werden, die mit einem typischen C-Compiler nicht passieren würden".

Abgesehen von den harten Garantien wäre es hilfreich, zumindest ein Gefühl dafür zu bekommen, wo wir stehen zwischen "Konstantzeitalgorithmen werden definitiv zu 100% vermasselt" und "es gibt keinen offensichtlichen Grund, nicht immer Timing-Eigenschaften zu erwarten, die mit der nativen Binärausgabe von Clang vergleichbar sind". Um @dconnolly zu 'use asm' Anweisungen vollständig respektieren, als auch solche wie die von Chrome, die es etwas lockerer spielen .

@buu700 deterministisches Ergebnis für alle Opcodes bedeutet nicht, dass das Timing für jeden Opcode garantiert ist. Clang garantiert auch keine Ausführung mit konstanter Zeit, und konstante Zeit ist nicht alles, was Sie brauchen, wenn Sie infoleak-sensitiven Code schreiben.

Im Moment unternimmt WebAssembly keinen Versuch, irgendetwas in Bezug auf Infoleaks zu garantieren.

Verstanden, danke für die Klarstellung des Abschnitts zum Determinismus @jfbastien.

In Bezug auf Timing / Seitenkanäle (und das Ignorieren von Garantien oder das Fehlen davon) hört es sich so an, als ob die Spezifikation zu diesem Zeitpunkt nichts Relevantes darüber enthält und noch keine nützlichen Daten darüber, wie die tatsächlichen Implementierungen im Vergleich zu Clang sind? Worauf ich nach dem Lesen Ihres früheren Kommentars wirklich gekommen bin, ist, ob es einen inhärenten Grund dafür gibt, dass wasm-Implementierungen in diesem Bereich notwendigerweise immer _schlechter_ als gcc/clang sind. Sie hatten den Abstraktionsgrad als Bedenken erwähnt, aber es war nicht klar, was Sie als Basisvergleich für ein "ausreichend" konstantes Timing (natives C, Assembly, Hardware usw.) verwendet haben.

Mit anderen Worten, angesichts der Wahl zwischen dem Ausführen von infoleak-sensitivem Code auf Clang und einer hypothetischen besten / ausgereiftesten / am meisten infoleak-gehärteten möglichen Implementierung der heutigen WebAssembly-Spezifikation, wäre erstere nach Ihrem Verständnis offensichtlich immer noch vorzuziehen?

Zu diesem Zeitpunkt würde ich mich weder auf Clang noch auf WebAssembly für Code verlassen, der Infoleak-empfindlich ist. Der einzige Weg, den ich derzeit kenne, um tatsächlich die gewünschten Garantien zu erhalten, besteht darin, Assembler zu schreiben, das Handbuch für die jeweilige CPU zu lesen, die ich anvisiere, und in enger Zusammenarbeit mit dem Kernel. "x86" oder "ARM 64" zu kennen, reicht nicht einmal aus, wenn Sie wirklich Timing-unabhängig sein möchten.

Sie können mit einigen Compilern / Sprachen einige Garantien erhalten, aber wenn ein Infoleak alles ist, was benötigt wird, um Ihren Code zu besiegen, dann ist "einige" keine Garantie genug.

Perfekt, danke, ich denke das beantwortet meine Frage. Einverstanden in allen Punkten zur allgemeinen Infoleak-Bedrohungsmodellierung; Ich wollte nur eine Vorstellung davon bekommen, ob wasm als undichter angesehen werden sollte als jedes andere (asm-freie) C-Kompilierungsziel, was, wie Sie meinen, nicht unbedingt der Fall ist?

Ich glaube nicht, dass "mehr undicht" eine sinnvolle Maßnahme ist. Die Metrik lautet: "Leckt es überhaupt?" Die Antwort für WebAssembly, clang, C++ und C lautet "ja".

Nun, im Besonderen dachte ich an Algorithmen, die entwickelt wurden, um bestimmte Seitenkanalwiderstandseigenschaften mit reinen C-Implementierungen zu erreichen, wie das Beispiel von libsodium/NaCl, das von @dconnolly verlinkt wurde. Es ist sicherlich ideal, wenn etwas jedes mögliche Angriffsszenario übersteht, aber es ist auch nützlich, das Delta zwischen zwei Dingen zu kennen (auch wenn beide irgendwie scheiße sind) und in diesem Fall, ob WebAssembly anstelle eines Linux-ABI verwendet wird ein Ziel wird wahrscheinlich das beabsichtigte Bedrohungsmodell von Libnatrium durchbrechen.

Der verlinkte Kommentar zum libsodium-Problemthread ist sehr informativ darüber, wie die Bibliothek mit asm.js interagiert, aber als Nicht-Experte ist es für mich nicht offensichtlich, wie diese spezifische Analyse für WebAssembly neu geschrieben klingen würde (abgesehen von der i64-Unterstützung und den Browsern). konsistenter im Umgang mit wasm als mit asm.js).

Aber wie auch immer, ich verstehe Ihre ursprüngliche Aussage vor einem Jahr, und alles, was mich wirklich interessierte, war, ob Sie eine stärkere Aussage machten, als Sie es tatsächlich waren (das war eine Spezifikation, die dafür bekannt war, spezifische neue Seitenkanalschwächen einzuführen im Standard-C/Clang nicht zu finden, im Gegensatz dazu ist es auch nicht allgemein für diesen Zweck geeignet), also danke für die Klarstellung.

>

Ich glaube nicht, dass "mehr undicht" eine sinnvolle Maßnahme ist.

@jfbastien , Quantitative Sicherheit ist ein Feld, das sich mit der Messung von gerechtem
das. Die gemeinsame Metrik ist, wie viele Informationsbits von a . preisgegeben werden
erfolgreicher Angriff – 1 Bit vs. 32 Bit, sagen wir, macht einen großen Unterschied (und in
Praxis fast jedes System hat kleine potenzielle Lecks durch die Seite
Kanäle). Oft ist eine solche Quantifizierung jedoch ziemlich schwierig.

>

Ich glaube nicht, dass "mehr undicht" eine sinnvolle Maßnahme ist.

@jfbastien , Quantitative Sicherheit ist ein Feld, das sich mit der Messung von gerechtem
das. Die gemeinsame Metrik ist, wie viele Informationsbits von a . preisgegeben werden
erfolgreicher Angriff – 1 Bit vs. 32 Bit, sagen wir, macht einen großen Unterschied (und in
Praxis fast jedes System hat kleine potenzielle Lecks durch die Seite
Kanäle). Oft ist eine solche Quantifizierung jedoch ziemlich schwierig.

Ich bin mir dessen bewusst und bin völlig desinteressiert, denn ein Leck ist ein Leck. Wenn es für Entwickler wichtig ist, wird es uns (die WebAssembly-Implementierer) irgendwann beißen. Ich denke nicht, dass WebAssembly versuchen sollte, dieses Problem in absehbarer Zeit anzugehen, angesichts unserer anderen Prioritäten und dass WebCrypto bereits als Versuch existiert (trotz der Mängel, die es sonst haben könnte, ist es besser, dieses Problem anzugehen als dort, wo WebAssembly derzeit ist .) ). Sie können dies natürlich in Ruhe erkunden.

@jfbastien , stimmte zu, dass dieses Thema im
Wasm ist nicht undichter als C, und wir kennen keine guten Möglichkeiten, um es anzugehen
es. Aber Vereinfachungen wie "ein Leck ist ein Leck" sind dabei nicht hilfreich
Angelegenheit -- jedes System leckt bis zu einem gewissen Grad, also ist die Menge tatsächlich alles
das zählt. Und nur darauf zu warten, bis "es uns beißt" ist keine Strategie, die
wird bei den wirklich potenziellen Opfern viel Vertrauen erwecken, nämlich
Browser-Benutzer.

stimmte zu, dass ... Wasm nicht undichter ist als C

Schön, danke für die ausdrückliche Bestätigung! Das ist alles, was ich hierher gekommen bin: ein allgemeines Gefühl dafür, womit ich es vergleichen sollte, keine Garantie dafür, ob es "nicht durchsickern" wird.

@rossberg-chromium Ich glaube nicht, dass ich der Idee zustimmen würde, dass wasm nicht undichter ist als C. Am Ende hängt das davon ab, wie jeder Motor alles umsetzt. JavaScriptCore z. B. stuft Code ein und beendet das Tiering-up von Code, wenn ihm der ausführbare Speicher ausgeht. Dies ist ein Leck, das bei C-Code nicht existiert. Ich würde erwarten, dass wasm mit zunehmender Weiterentwicklung von Wasm-Engines wahrscheinlich so undicht sein wird wie so etwas wie die JVM. Letztendlich glaube ich nicht, dass die Spezifikation oder die Implementierer sich bemühen werden, Informationslecks zu verhindern, insbesondere nicht auf Kosten der Leistung.