WebGL 1.0

    Ich sagte doch im Smalltalk, dass Chrom/Iron Mist und sowas von weit weg von Usability sind :mrgreen:

    Immer herrlich solch publizistische Überschriften zu sehen: WebGL: 3D-Standard gefährdet Firefox und Chrome.

    Auch wenn diverse Journalisten solche Beiträge als Anteil ihrer zu verdienenden Brötchen verstehen, der Schwanz wedelt noch immer nicht mit dem Hund.

    Der traurige Part liegt in dem von der Leserschaft geschenkten Vetrauensvorschuss solcher Postillen.

    Nicht publizistisch, schlichtweg falsch. Nicht die Browswer sind gefährdet, sondern Daten auf dem Rechner :idea:
    Ich habs trotzdem mal deaktiviert, da ich mich damit nicht sooo gut auskenne.

    Man könnte sich hier, soweit das Wissen ausreicht, mal zur Abwechslung mit dem WeGL-Standard beschäftigen. Betirfft ja ja alle Browser, also auch Firefox.
    Die publizierenden Publizisten interessieren eher weniger. Diue Überschrift ist schlecht, der Text selbst geht aber. fefe hat auch schon versucht es auseinanderzunehmen (die "Update" beachten)
    http://blog.fefe.de/?ts=b32cb04e

    Probieren geht über Studieren

    .Ulli erklärte Folgendes:

    Zitat

    Immer herrlich solch publizistische Überschriften zu sehen: WebGL: 3D-Standard gefährdet Firefox und Chrome.[...]


    Solche Beiträge nicht voreilig vorverurteilen. Lese Dich bitte genauer in die Thematik ein. ;)

    Meinen bisherigen Kenntnissen nach, stellt die Interpretation interaktiver Inhalte über WebGL - innerhalb des jeweils eingesetzten Browsers (z.B. Firefox 4 / Chrome / Safari) - theoretisch kein Risiko dar.

    Praktisch geht es jedoch - unter Umgehung der Betriebssystemsverfügungen - um den direkten Zugriff des Browsers auf die Graphik-Hardware des Betriebssystems, was meiner Ansicht nach unüberschaubare Konsequenzen für die eingesetzte Systemsicherheit selber zur Folge haben könnte.

    Sofern ein wie auch immer gearteter Browser uneingeschränkt auf Hardware-Treiber (also in diesem Falle: Graphik-Treiber) des zugrundeliegenden Systems (z.B. Windows) zuzugreifen vermag ist somit - unabhängig vom Browser - logischerweise die geschriebene Treiber-Software für diese GUI (graphische Schnittstelle) das schwächste Glied in der Sicherheits-Kette.

    Grund dafür ist die Tatsache, dass für OEM-Graphik-Treiber (die logischerweise auf der Hardware-Schnittstelle selber aufsetzten und im Anschluss wiederum vom Browser direkt interpretiert werden müssen) bisher noch kein Sicherheitsstandard definiert wurde.

    Hinzu käme obendrein, dass unter Einsatz von Java-Script im Browser als „offene Schnittstelle zum Nutzer hin" die Aufbereitungen solcher graphischen Inhaltsdaten (z.B. der einzelnen Shader einer Graphik) leichter zu berechnen wären was - unter Voraussetzung einer bereits erfolgten Kompromittierung - wiederum anonyme Rückschlüsse auf das jeweils eingesetzte System zuliesse. (Timing-Attacks / Kryptographische Fernanalysen).

    Wie auch immer gearteter Browser haben somit - meiner Beurteilung nach - nichts im Kernel-Modus des Betriebssystems verloren.


    Oliver


    https://wiki.mozilla.org/Blocklisting/B…raphics_Drivers
    http://www.contextis.com/resources/blog/webgl/

    Zitat von Oliver222

    Solche Beiträge nicht voreilig vorverurteilen.

    Da war nichts voreilig.

    Zitat von chip

    So soll es möglich sein, über eine präparierte Webseite so tief ins System einzudringen, dass man über Manipulationen am Grafiktreiber beliebige Programme im Kernel-Modus des Betriebssystems ausführen kann.

    Ein manipulierter Treiber kann so einiges, ihn aber über die API des WebGL zu manipulieren dürfte schwierig sein.

    Zitat von chip

    Gefährdet sind Firefox und Chrome

    Wenn überhaupt, dann sind sie nicht direkt sondern nur über obigem Szenario gefährdet.

    Zitat von Oliver222

    Lese Dich bitte genauer in die Thematik ein. [...] http://www.contextis.com/resources/blog/webgl/

    Dazu gibt es auch einen Kommentar von Peter Strohm WebGL und die Sicherheit

    Zitat von BeeHaa

    die man bequatschen könnte,

    Ohne dir persönlich nahe treten zu wollen, da gibt es nichts zu bequatschen.

    Blogs jeglicher Art und Reputation werden hier immer noch als Rülpsen oder Flatulenz einer Person dieses Planeten abgetan.

    Blogs werden hier nur auf Hinweis und nie freiwillig gelesen, denn sie sind in 99,99% Zeitverschwendung.

    Ulli - die Aufzeichung des Problems zum Verständnis des Laiens halte ich für gelungen,
    ebenso den ersten Link zum Blog/Fefe. Denn wenn ich den folgenden Umstand noch
    dazurechne, ist das Szenario über Hardware fast pefekt
    ► http://www.supernature-forum.de/976068-post110.html


    Grafikkarten haben ebenso ein erneuerbares BIOS.

    .Ulli du darfst dir das Forum hier nicht so vorstellen, daß jeder nur mit dir "quatschen" will. Daher halte ich dein Eigenrölpsen bei so manchem Thema hier für kleinwenig übertrieben, gelinde gesagt. Da kommt man sich gelegentlich vor, als wenn das hier dein Blog sein sollte :klasse:

    Probieren geht über Studieren

    Zitat von Brummelchen

    die Aufzeichung des Problems zum Verständnis des Laiens halte ich für gelungen,

    Trotz dieser feinen Doppelsinnigkeit bin ich anderer Meinung und lege den Großteil unter FUD ab.

    Wenn Passagen wie

    Zitat von supernature-forum

    [...] der sich in die Firmware des DVD ROM/RAM/Brenners schreibt,
    [...] schreibt er sich direkt als allererstes auf die Platte

    auftauchen, kann man eigentlich nur laut aufschreien.
    Das geht nicht. Ohne ein irgendwie geartetes Hilfsprogramm wird der Bösewicht nicht ausgelesen und fortgeschrieben.

    Zurück zum WebGL.
    Es ging ja nicht um ein BIOS sondern um die Ausführung eines Programms.

    Somit soll also ein Bösewicht über diese Schnittstelle so etwas einschleusen können. Was da so eintrudelt durchläuft einen Compiler und wird, so der Compiler nicht gemosert hat, über das regulären API zur Ausführung weitergereicht.

    Nun soll also ein fehlerfreies Programm der GPU ein ablauffähiges Programm für einen x86 oder einen Aufruf eines solchen darstellen. Klappt nicht.

    Nun möge das Programm der GPU selbiges erzeugen. Mit vielen Klimmzügen vielleicht erreichbar und das Ergebnis landet im dafür reservierten Speicherbereich. Und nun gammelt es / er so vor sich hin, es gibt ja keinen der an dieser Stelle ein ausführbares Programm erwartet und es auch ausführt.

    .Ulli erklärte u.A. Folgendes:

    Zitat

    [...]Ein manipulierter Treiber kann so einiges, ihn aber über die API des WebGL zu manipulieren dürfte schwierig sein.[...]


    Das Thema wurde von Dir vermutlich missverstanden - oder ich habe mich im Voraus falsch ausgedrückt...

    Ein OS-Graphikkarten-Treiber wird weniger über die API (also der Schnittstelle zwischen Betriebssystem und System-Anwender) des browsergeführten Web GL´s selber angegriffen (kompromittiert) werden können (wie von Dir dargestellt) - Umgekehrt könnte jedoch ein Schuh daraus entstehen.

    In diesem Szenario müsste dann die API des Web GL´s über den jeweils eingesetzten Browser (z.B. Firefox) u.U. auf einem bereits kompromittierten Hardware-Treiber (Graphik-Treiber) des Betriebssystems selber aufsetzten und diese übertragenen Daten im Anschluss auch als authentisch (wahrheitsgemäss) interpretieren müssen - was wiederum verheerende Konsequenzen für die Anwendungssicherheit der Nutzer solcher "WebGL-Browser" nach sich ziehen könnte.

    Darüberhinaus können - meiner Beurteilung nach - folgende Sicherheitsbeeinträchtigungen wirken:


    Zitat

    a. Ein wie auch immer gearteter Graphik-Karten Treiber (auf den der Browser über WebGL uneingeschränkt zugreifen dürfte), hätte somit grundsätzlich auch Zugriff auf die Gleitkomma-Einheit des Coprozessors so einer Graphik-Karte. Diese FPU (Gleitkommaeinheit /Coprozessor) ist massgebend zur Berechnung ungerader Zahlen. (z.B. für Computerspiele).

    b. Allgemeine Verschlüsselungsverfahren greifen i.d.R. zur Berechnung kryptographischer Chiffrierungen - durch eine generische Berechnung der Verschlüsselung auf Koprozessoren (also der Festkommaarithmetik) - des eigentlichen Hauptprozessors (der CPU) selber zu, um überhaupt in kurzer Zeit qualitative kryptographische Übertragungen berechnen zu können. Der jeweils eingesetzte Hauptprozessor ist für solche Berechnungen nicht geeignet.

    c. Wird nun ein - wie auch immer gearteter und bereits kompromittierter Browser - unter Einsatz von WebGL - von einem unbedarften Nutzer verwendet, so bestünde die Möglichkeit (die Gefahr), eben genau über diese kompromittierte interaktive Schnittstelle (also über den bereits kompromittierten Browser selber), bereits berechnete und vertrauliche Zugangs-Verfahren zuungunsten des Anwenders unter Einsatz einer Scriptsprache (z.B. JavaScript) durch uneingeschränkte Zugriffe auf solche graphischen Coprozessoren wieder zurückzuberechnen.


    Der zugrundeliegende Browser sollte von daher nicht als interaktive Schnittstelle direkt auf Hardware aufsetzen dürfen, deren Treiber-Software u.A. für kryptographische Berechnungen in Hinblick auf vertrauliche Zugänge (Finanzdienstleister, Banken, Behörden, etc.) verwendet wird.


    .Ulli erklärte darüberhinaus Folgendes:

    Zitat

    Zurück zum WebGL.
    Es ging ja nicht um ein BIOS, sondern um die Ausführung eines Programms.


    Nein - Es geht dabei um den uneingeschränkten Zugriff des interaktiven Browsers auf ungesicherte Hardware-Treiber - Nicht um ausführbare Prozesse. Ein ungesicherter Hardware-Treiber verhält sich im sog. eingeschränkten User-Mode (Betriebssystem-Umgebung) immer noch sicherer als im uneingeschränkten Kernel-Mode.


    Ulli stellte obendrein leider Folgendes dar:

    Zitat

    [...]Blogs jeglicher Art und Reputation werden hier immer noch als Rülpsen oder Flatulenz (Aufblähung) einer Person dieses Planeten abgetan.[...]


    Das unterscheidet jene Menschen die sich stetig weiterentwickeln - und solche Blogs verarbeiten - von jenen Menschen, die bedauerlicherweise stehenzubleiben scheinen.

    Das unterscheidet darüberhinaus jene Menschen die dazu tendieren „vorzuverurteilen“ von jenen Menschen, die versuchen ihre Ansichten ständig zu revidieren.

    @.Ulli - Denke mal in Ruhe darüber nach, was Du in Bezug dieses Kommentars geschrieben hast. Wir alle haben die Weisheit und das Wissen nicht mit der Muttermilch aufgenommen, jedoch brauchen wir die Möglichkeiten und das Wissen vieler Anderer (u.A. auch der ganzen Blog-Beiträge) um hier überhaupt weiterzukommen.

    Ich kann mich irren - Jedoch was wir innerhalb dieses Forums in der Zukunft nicht brauchen werden, sind „alteingesessene Mitglieder“, die „glauben“ alles zu wissen, um von daher für neue technische Herausforderungen nicht mehr empfänglich zu sein.


    Oliver

    Ich hab das schon geahnt, ehrlich jetzt, als der 10er Flash mit HW-Unterstützung anfing an einigen Konfigurationen (Windows) so den Grakatreiber gelegentlich aus dem Tritt zu bringen, daß dies zum Kernelstopp (BSOD) führte. Damit haben die Leute überigens weiterhin Probleme. Das war der Vorgeschmack dessen für mich.

    Das resultiert dann in solchen Threads wie "Firefox und Youtube bringen den Rechner zum Absturz"... Ende des Jahres rechne ich mit ersten ProofOfConcept was WebGL angeht. Wahrscheinlich wird es sich erstmal um Nuken handeln. Auch nicht gerade eine harmlose Geschichte.

    Es gibt viele sich sehr toll anhörende Klamotten, die man imho aus dem Netz her erst garnicht versuchen sollte. Es reicht ja nicht, daß aus der heutigen Sicht TCP/IP schon broken by design ist, dann fangen sie noch neuen derartigen Mist einzupflanzen.

    VideoOnDemand und Browsergaming sollen halt die neuen Gäule der Contentmafia sein. Das wird einfach völlig gehirnlos reingedrückt und fertig. Bringt ja Geld. Die Probleme haben dann halt nicht die Anbieter...

    Probieren geht über Studieren

    Zitat von Oliver222

    Das unterscheidet jene Menschen die sich stetig weiterentwickeln - und solche Blogs verarbeiten - von jenen Menschen, die bedauerlicherweise stehenzubleiben scheinen.

    Im Gegenteil, Menschen müssen Blogs ignorieren können weil sonst die eigene Entwicklung stagniert. Bekannterweise hat so ein Mensch nur ein begrenztes Zeitkontingent, dessen Verteilung doch wohl überlegt sein sollte.

    Zitat von Oliver222

    […] jedoch brauchen wir die Möglichkeiten und das Wissen vieler Anderer (u.A. auch der ganzen Blog-Beiträge) um hier überhaupt weiterzukommen.

    Als ob das vor der Erfindung der Blogs nicht möglich gewesen wäre.

    Jedoch gab es einen gewichtigen Unterschied: das Wissen wurde für den Lernenden / Umsetzenden verdichtet und aufbereitet, sei es in Handbüchern, Referenzen, HowTos, etc.

    Zitat von Oliver222

    […] Jedoch was wir innerhalb dieses Forums in der Zukunft nicht brauchen werden, […]

    Du warst für die Nutzung des Plurals autorisiert ? Wenn nein - Was juckt es die Eiche … .

    Zitat von Oliver222

    […] um von daher für neue technische Herausforderungen nicht mehr empfänglich zu sein.

    Diese Meinung kann ich - selbstverständlich - nicht teilen. Zumindest erspare in dem geneigten Leser die fortwährende Verschleppung eines Themas in Richtung Kompromittierung und deren mögliche / hypothetische Ableitungen.