Login
Newsletter
Werbung

Thema: Die Sicherheit von WebAssembly jetzt und in Zukunft

17 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von lle am Fr, 17. August 2018 um 21:17 #

Da ist ja die Geschichte wieder am Anfang. Die Java Architektur wurde verteufelt, weil von SUN, von andern gern auch mal boykottiert. Und vor kurzem wurde das böse und ja so unsichere Java aus dem Browsern verbannt . Der Youngstar ist WebAssembly. Ja so sicher ... wie echt jetzt JavaScript sicher?... egal ... läuft ja auch auf Windows. Da wird Sicherheit ja vom Mossad, NSA und BND garantiert ;-)

Und jetzt das, GC und Threads, Bytecode und eine VM innerhalb der Browser. Nein Hilfe! Gut das es Google gibt ;-)

Mir stellt sich die Frage warum haben wir es nicht geschafft eine wirkliche Befreiung von Hardware und Betriebssystem zu schaffen. Die technologische Ansatz war mit JAVA da. Mann stelle sich einmal vor wo JAVA jetzt hätte sein können. Ich meine ohne den, ich mache da nicht mit und Unterstütze nur meine eigene Technologie, Krieg, der Neider und falschen Unterstützern. Ja wer war das wohl ;-) Aber geben wir WebAssembly doch auch eine Chance.

Oder vielleicht entwickelt jemand noch eine Script Sprache, eine neue VM, einen neuen Programmiersprachen Dialekt oder Methodik, oder, oder... damit wir am Ende wieder am Anfang sind.

viele Grüße vom Sarkasmus Team Sheldon :-D

[
| Versenden | Drucken ]
  • 0
    Von kickeriki am Sa, 18. August 2018 um 02:26 #

    Ich habe nichts verstanden, was du da geschrieben hast...

    [
    | Versenden | Drucken ]
    0
    Von Anonymous am Sa, 18. August 2018 um 09:57 #

    In der Anfangszeit der IT hat sich das durchgesetzt, was als erstes da war. Darum schlägt sich die Welt immer noch mit so einer unsäglichen Schei*e wie C und C++ rum.

    Nachdem die IT inzwischen in der Hand weniger - in ihrem Segment jeweils marktbeherrschender - IT-Konzerne ist, setzt sich das durch, was mit dem größten Schub in den Markt gedrückt wird.

    Und da geht es nicht um Qualität oder Sinnhaftigkeit, sondern um Dominanz auf dem Markt - egal wie schlecht das eigene Produkt ist.

    [
    | Versenden | Drucken ]
    • mehr Ps:
      0
      Von Anonymous am Sa, 18. August 2018 um 09:59 #

      Im letzten Satz hätte ich statt "Produkt" "Produkt bzw. Standard" schreiben müssen.

      [
      | Versenden | Drucken ]
      0
      Von Antworter am Sa, 18. August 2018 um 19:26 #

      Und was wäre die Lösung um C/C++ loszuwerden? ASM?

      [
      | Versenden | Drucken ]
      1
      Von KönigKalle am So, 19. August 2018 um 16:34 #

      C++ als Müll zu bezeichnen, kann ich nachvollziehen, aber C? Anhand Ihrer Aussagen möchte ich mich schon fast darauf festlegen, dass es sich bei Ihnen um einen Ruby-Programmierer handelt.

      Mahlzeit,

      Kalle König

      [
      | Versenden | Drucken ]
      • 0
        Von milkman am So, 19. August 2018 um 23:18 #

        Komische Aussage, wenn man bedenkt, dass MRI, die Standardimplementierung von Ruby, in C geschrieben ist...
        Scheint wohl auf eine persönliche Einstellung zu einer imho interessanten (wenn auch derzeit noch nicht wirklich performanten) Sprache wie Ruby zurückzuführen zu sein.
        Und ja, ich schreibe seit einigen Jahren Software vA in Ruby.

        [
        | Versenden | Drucken ]
    0
    Von kamome umiodori am Sa, 18. August 2018 um 12:52 #

    Ein halbwegs sicher implementierbares JavaScript (oder ein Teil davon) wäre prima – aber nach über 20 Jahren glaube ich nicht mehr daran. Ich ärgere mich über die häufige Notwendigkeit, JS zu aktivieren – und über unsinnige/schlechte Entwicklungen in HTML und CSS (teilweise sicher aufgrund des Festhaltens an JS), die JS in vielen Fällen unnötig machen würden, z.B. range input ohne Zugriff auf den Wert von CSS aus.

    [
    | Versenden | Drucken ]
    • 0
      Von InterneExplorer am So, 19. August 2018 um 18:32 #

      Ob das jetzt so viel besser würde, wenn CSS noch komplexer würde (es ist bereits turingvollständig und für 3-4 Aufgaben zuständig) und weitere Sicherheitslücken aufreißt (es gibt schon die eine oder andere)?

      Ein halbwegs sicher implementierbare Skriptsprache wäre prima...
      ...ist auf alle Aspekte ausgedehnt aber fast unmöglich.
      Sicher, die Web-APIs sind lächerlich und ungar, aber konzeptionell haben sowohl VMs als auch Prozess-Sandboxen ihre Grenzen.

      [
      | Versenden | Drucken ]
    0
    Von Byte Coder am So, 19. August 2018 um 10:49 #

    Bytecode-Validierung kann man schwerlich bis unmöglich im Nachhinein dranbasteln, wie Java und auch viele andere auf die harte Tour gelernt haben. Und selbst bei den letzen beiden Versuche, ein sicheres Bytecode-Format im Internet zu nutzen, Flash und Silverlight, wurde ewig hinterhergebastelt. Adobe interessiert es halt nicht aber Verschwörungstheoretiker sagen, dass Silverlight auch deshalb eingestellt wurde.
    Ob das Design von WebAssembly in Ordnung ist, wird sich zeigen...

    [
    | Versenden | Drucken ]
0
Von UChef am Mo, 20. August 2018 um 08:29 #

WebAssembly ist ein Format, das es ermöglicht, Code, der wie Assembler aussieht, mit JavaScript auszuführen
Das mag auch richtig sein, aber primär hat Wasm nichts mit JavaScript zu tun!

Quelle:

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine

Man kann eine VM dafür natürlich in JS schreiben und mutmaßlich kann das so auch in den Browsern realisiert sein, eine Notwendigkeit dazu besteht aber nicht!

[
| Versenden | Drucken ]
  • 0
    Von klopskind am Mo, 20. August 2018 um 22:23 #

    Was du sagst, ist soweit korrekt.

    Ich bin Laie, aber vermute der Grund hierfür ist, dass WebAssembly bisher innerhalb der JavaScript-Komponente der Browser-Engines, d.h. innerhalb der selben Verzeichnisstruktur, entwickelt wurde/wird. Wahrscheinlich arbeiten größtenteils die selben Personen/Teams an diesem Code und grundlegende Parallelen gibt es ja ohnehin: Im Quelltext der Internetseiten eingebetteter Code, der heruntergeladen, isoliert eingelesen und (üblicherweise) ausgeführt wird.

    Historisch hat sich WebAssembly quasi aus Projekten oder Experimenten wie asm.js, PNaCl und emscripten entwickelt. Kompatibilität wird mittels polyfill gewährleistet. Dies könnten weitere Gründe sein.

    Ich vermute, dass "stack-based virtual machine" hier ein Implementierungsdetails ist, worauf man sich geeinigt hat, um die gesetzten Ziele besser umsetzen zu können. Eine allgemeine Abwägung von Vor- & Nachteilen findet sich hier.

    [
    | Versenden | Drucken ]
0
Von klopskind am Mo, 20. August 2018 um 09:09 #

Wie steht es denn nun um Firefox und Edge bzw. deren Browser/JavaScript-Engines?

Frau Silvanovich schreibt dazu herzlich wenig, obwohl angeblich alle vier großen Browser(-Engines), die WebAssembly implementieren, untersucht worden seien. Nur zwei ältere Sicherheitslücken werden hier erwähnt, die teils per OSS-Fuzz identifiziert wurden.

Da stellt sich die Frage, in wie weit diese Schwachstellen WebAssemblys tatsächlich struktureller Natur sind. Es wirkt so, als wären die Sicherheitslücken weniger ein generelles Problem von WebAssembly, sondern viel eher stark implementierungsspezifisch.

Daher erscheint mir Frau Silvanovichs Blogeintrag eher wie Marketing/PR als alles Andere. Das einzige Interesse Googles, in anderen Implementierungen Schwachstellen bzw. Sicherheitslücken zu entdecken, das ich erkennen kann, erklärt sich mir nur damit, dass einem Sicherheitsimage/-debakel á la ActiveX, Java, Flash oder Silverlight für WebAssembly vorgebeugt würde.

Natürlich kann ich verstehen, wenn für die eigene Implementierung mehr Aufwand betrieben wird, als für die der Konkurrenz, aber dann muss Frau Silvanovich das auch so deutlich kenntlich machen.

Übrigens:
Ich habe noch nicht herausfinden können, wie ich den Quelltext, also den Byte-Code, bzw. dessen binäres Format anschauen kann? Am diesem Beispiel habe ich das nicht herausfinden können, z.B. Entwicklertools oder Quelltextanzeige im Firefox habe ich nicht dazu bringen können.

Wird es Möglichkeiten zum Disassemblieren des Byte-Codes in ein verständlicheres Format der Programme zu erhalten, die man da so im Driveby lädt und ausführt?

Nicht speziell diesen Artikel betreffend:
Ich sehe hier die Tendenz, dass immer mehr Webseiten unleserliche und unverständliche Quelltexte aufweisen - absichtlich oder unabsichtlich. Viele Webseiten werden heutzutage aussschließlich per JavaScript (teils "obfuskiert") auf die Bildschirme gezeichnet. Die Webseiten oder eher -anwendungen sind/würden damit quasi proprietär. WebAssembly ist ein weiterer Schritt in diese Richtung. Diese halte ich aber für äußerst schädlich für ein freies Internet und (FL)OSS. Trotzdem macht Mozilla mit, obwohl sie sich immer anders vermarkten. Lügt Mozilla seine Zielgruppe erfolgreich an? Ich finde die Entwicklungen seit Gründung der WHATWG größenteils bedenklich. Geht das nur mir so?

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung