29

WebGL równie niebezpieczne co Silverlight i Flash. Googler wdeptuje MS w ziemię

Czuję się jak kretyn, że wspominając ostatnio o (nie)bezpieczeństwie WebGL, sam nie pomyślałem o tym co Gregg Tavares z Google wypunktował wczoraj dobitnie na swoim blogu. Zastrzeżenia Microsoftu to… bullshit. Sprzętowa akceleracja grafiki w Silverlight i Flasha niesie za sobą dokładnie te same problemy z bezpieczeństwem. Microsoft chroni swoje podwórko, a nie bezpieczeństwo użytkowników i dlatego odmawia wsparcia tej technologii.  Tavares zwraca uwagę na to, że: Silverlight 5 […]

Czuję się jak kretyn, że wspominając ostatnio o (nie)bezpieczeństwie WebGL, sam nie pomyślałem o tym co Gregg Tavares z Google wypunktował wczoraj dobitnie na swoim blogu. Zastrzeżenia Microsoftu to… bullshit. Sprzętowa akceleracja grafiki w Silverlight i Flasha niesie za sobą dokładnie te same problemy z bezpieczeństwem. Microsoft chroni swoje podwórko, a nie bezpieczeństwo użytkowników i dlatego odmawia wsparcia tej technologii. 

Tavares zwraca uwagę na to, że:

  • Silverlight 5 i Flash 11 oferują te same możliwości co WebGL, udostępniając GPU za pośrednictwem API kontentowi z sieci. Ale są dostępne w najnowszym IE i to najwyraźniej Microsoftu nie martwi.
  • Gregg Tavares sugeruje, że Context IS – „niezależna firma konsultingowa zajmująca się bezpieczeństwem”, tak naprawdę została najęta przez Microsoft. I przyznam, że przyglądając się w jaki sposób jest prowadzona komunikacja (polecam przekonujące wideo) wyników ich „ograniczonych badań” – trudno nie dojść do tych samych wniosków, ponieważ nie ma w nich słowa na temat innych technologii dających sieci dostęp do GPU przez swoje API – jak wspomniałem wyżej Silverlight 5 i Flash 11.
  • Microsoft nie wspierał OpenGL, na którym bazuje WebGL – promując własne rozwiązanie DirectX. Akceptacja WebGL jako standardu w IE, mogłaby zmusić Microsoft w przyszłości do wspierania go również na innych platformach – stawiające deweloperów przed wyborem: WebGL działające absolutnie wszędzie, czy DirectX zamykający ich w ekosystemie Microsoftu.
  • Akurat Windows jest jedynym systemem, który aktualnie umożliwia zapobieżenie atakom DOS, przeprowadzonym za pomocą WebGL poprzez zabicie procesu, który blokuje zbyt długo GPU. Grupa Khronos pracuje właśnie nad podobnym rozwiązaniem dla innych platform.
  • Uruchomienie szkodliwego kodu w Chrome (tu prztyczek w nos dla Mozilli) i IE nie powinno stanowić większego problemu, ponieważ strony są uruchamiane jako oddzielne procesy bez dostępu do plików i sprzętu.
  • Specyfikacja WebGL zakłada walidację wszystkich wprowadzanych przez API parametrów, a tam gdzie błędy dają możliwość ataku, lecz nie da się ich obejść, driver trafia na czarną listę.

Choć jeden z pracowników Microsoftu twierdzi, że wspomniany wcześniej wpis nie jest oficjalnym stanowiskiem MS, a decyzja o nie wspieraniu WebGL jest jedynie wynikiem niedoinformowania (sic!) kierujących rozwojem IE, to trudno pozbyć się wrażenia, że to świadome działanie – zwłaszcza w wykonaniu firmy która stworzyła najwredniejszego potwora nawiedzającego sny speców od bezpieczeństwa przez lata – kontrolki ActiveX.

Tak jak pisałem ostatnim razem: WebGL wymaga pracy, tak samo jak pracy wymagały bugi we Flashu wykorzystywane przez przestępców. To schizofrenia, jeśli Microsoft z jednej strony wspiera standard HTML5 (nowe apki Windows 8, IE 9), a z drugiej chce mu wytrącić z reki najpotężniejszą broń, zastępując ją wtyczką Silverlight. Nie wierzę, aby to się udało. Na którymś etapie, MS będzie musiał tak jak w przypadku IE9 uświadomić sobie, że nie jest pępkiem świata i nie tylko on definiuje standardy.

  1. Dawid Partyka pisze:

    Nie potrafię sobie tego wyobrazić – IE nie jest już najważniejszą przeglądarką, programiści tworzą z użyciem WebGL ciekawe aplikacje (no gry, no), a MS to olewa i wciąż się wzbrania.
    Zmiana przeglądarki to nie taki problem jak zmiana systemu.

  2. Michal Kubiak pisze:

    Tylko że Silverlight o którym mowa to działa we wszystkich przeglądarkach oraz o ile mi wiadomo na Windowsie i Linuxie oraz dodatkowo na Windows Phone.

    1. krefik pisze:

      Silverlight pod Linuksem działa tak, że równie dobrze mogło by go nie być – w zasadzie jedyne aplikacje w których jest powszechnie używany to DRM-owe odtwarzacze filmów. A DRM w implementacji firmy Novell (Moonlight) nie działa.

    2. Dawid Partyka pisze:

      A takie chrome i firefox też działają na każdym systemie

  3. greg pisze:

    cześć! chciałem donieść, że w chrome jest już dostępne rozszerzenie, które umożliwia wyszukiwanie głosowe – i uwaga, na polskich stronach można szukać mówiąc do mikrofonu po polsku!

    tutaj link
    https://chrome.google.com/webstore/detail/hhfkcobomkalfdlmkongnhnhahkmnaad#

  4. zvczxc pisze:

    hmm czy znacie jakies powazne konsekwencje domniemanej niebezpiecznosci flasha … jakos sobie nie przpominam zeby cos komus wycieklo itp.

    flash jest ok, jedyne do czego sie mozna przyczepic to zwiekszenie pradozernosci no ale kochani czy jak sobie puszcze 30klatek w webgl to bedzie lepiej znaczaco?

    1. Żartujesz, prawda?

      Jeśli pytasz na serio – dziurę we Flashu wykorzystano na przykład w ostatnim ataku na RSA – http://it.slashdot.org/story/11/04/02/0332252/RSA-Says-SecurID-Hack-Based-On-Phishing-With-Flash-0-Day.

  5. iSalt0 pisze:

    Qfa, to już nie jest wyścig zbrojeń, to regularna wojna!

  6. Tu Camelek pisze:

    Widział ktoś może adres w przeglądarce zawarty na dołączonym obrazku? :>

  7. Królik pisze:

    Żeby to się nadawało do gier, to sam WebGL to zdecydowanie za mało.
    Po pierwsze wydajność samego JS jest jeszcze ciągle bardzo słaba w porównaniu z SL czy JavaFX – np. u mnie Firefox 4 dostaje od SL ponad 20x: http://www.silverlight.net/content/samples/sl2/silverlightchess/run/default.html.

    Po drugie, nie będzie dużo lepiej (a przynajmniej nie szybko) – stopień skomplikowania maszyny wirtualnej wykonującej programy w języku dynamicznym efektywnie będzie nieporównywalnie wielki w porównaniu nawet do maszyn wirtualnych Javy czy .NET – języki statycznie typowane kompiluje się znacznie łatwiej, a i tak po prawie 20 latach rozwoju VMom nie udaje się pobić wydajnością C++, choć teoretycznie jest to możliwe (w praktyce jednak są bardzo blisko – jeśli różnica jest większa niż 50%, to najczęściej to wina kodu, nie VM).

    Po trzecie, gry wymagają nie tylko wydajności, ale też odpowiedniego stopnia responsywności przy bardzo dużej liczbie obiektów zaalokowanych w pamięci. Do tego jest potrzebny odpowiednio wydajne GC, ze wsparciem ze strony systemu operacyjnego i sprzętu. Na razie najlepsze implementacje JS takiego czegoś nie posiadają, i nie zanosi się na to. Do prostych gier JS będzie idealny, ale na gry pokroju Minecrafta poczekamy jeszcze długo.

  8. Nie dziwie się, że Microsoft nie wspiera OpenGL. W wojnie OG vs DX po prostu wygrali o niebo lepszym produktem a nie tylko bredzeniem o otwartym oprogramowaniu.

    1. sieciobywatel pisze:

      Przekonałeś mnie. Gdzie mogę ściągnąć DitrectX na swojego Androida?
      A teraz niespodzianka: na Windows WebGL używa Direct3D!

    2. Kogo obchodzi D3D na twojego Androida?

    3. Kup sobie Windows Phone to będziesz miał :P

  9. sieciobywatel pisze:

    DOS vulnerability in Silverlight 5’s 3D (similar to WebGL DOS vulnerability) by Benoit Jacob (Mozilla)

    @ Królik
    W Firefoksie masz już typed arrays, w drodze jest bardziej responsywny, incrementalny GC, cały czas szybko rozwija się JIT (na przykład).
    Duża część różnicy w wydajności wynika z nieumiejętnego przenoszenia schematów z innych języków, co powoduje np. aktywację konstruktorów kopiujących tam gdzie jest to zbędne. Co zabiera czas i co gorsza zostawia masę śmieci, które muszą zostać zebrane etc, etc.
    Także w samym JS szykują się zmiany, które zmniejszą te problemy.
    Byłbym bardziej optymistyczny, tym bardziej, że najcięższą robotę i tak odwalą GPU właśnie dzięki WebGL.

    1. Królik pisze:

      Jeżeli będzie tak jak piszesz, to i tak skończy się pewnie na tym, że złożone aplikacje będzie się pisać w czymś innym niż JS i kompilować do JS. Poza tym, w wielu ciekawych grach wcale nie GPU jest wąskim gardłem – może w FPSach pokroju Quake’a tak, ale w grach, gdzie masz jakieś nietrywialne AI czy realistyczną fizykę, to wydajne CPU to podstawa.

      JITy do JS, owszem poprawiają wydajność, ale brak statycznej specyfikacji typów obiektów w JS bardzo utrudnia generowanie wydajnego kodu – np. bardzo trudno robić wywołania inline (a inline daje często 10x różnicę wydajności otwierając drogę do kolejnych optymalizacji), kiedy nie można statycznie zlokalizować implementacji metody. A w 99% sytuacji nie można zlokalizować, bo wszystko jest dynamiczne i rozstrzygane w czasie wykonania.

  10. Grzesiek pisze:

    Jednak warto uzupełnić artykuł o także inne opinie osób o większym doświadczeniu :)

    Jak wiadomo ludzie tacy jak JOHN CARMACK (ID SOFTWARE) którzy całe życie poświęcili OpenGL i mają więcej doświadczenia niż cała firma Google i Mozilla razem ostro krytykują WebGL.

    Trudno nazwać Carmacka osobą która pała miłością do Microsoftu. Przez 15 lat próbował on całemu światu udowodnić że OpenGL jest lepszy niż DirectX. Wszystkie legendarne gry oraz silniki graficzne stworzone w ID Software wykorzystują właśnie OpenGL.

    https://twitter.com/#!/id_aa_carmack

    „I agree with Microsoft’s assessment that WebGL is a severe security risk. The gfx driver culture is not the culture of security”

    „They are orthogonal technologies, but NaCl is much, much easier to make secure than WebGL, even though it sounds scarier doing GL ES from NaCL is clearly just as dangerous as WebGL”

  11. Grzesiek pisze:

    Swoją drogą szkoda że nikt nie robi otwartych debat o technologii. Tak jak debaty telewizyjne :)

    Z jednej strony programiści Google oraz Mozilli promujący WebGL. Mówiący o zaletach technologii

    Z drugiej strony John Carmack (ID Software) oraz ludzie którzy stworzyli XBOX oraz DirectX. Mówiący dlaczego po 15-20 latach pracy nad grafiką/sprzętem uważają że jest to niebezpieczne by strony WWW miały bezpośredni dostęp do hardware.

    Ciekawe czy ktoś byłby na tyle odważny by skrytykować Johna Carmacka :)

  12. Grzesiek pisze:

    „Uruchomienie szkodliwego kodu w Chrome nie powinno stanowić większego problemu”

    Atak DOS poprzez WebGL przygotowany przez… fundację Khronos :)

    https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/extra/lots-of-polys-example.html

    Chrome wytrzymuje zawieszenie się sterowników systemu operacyjnego jednak proces GPU w przeglądarce przestaje działać do restartu aplikacji. Próba kilkukrotnego uruchomienia przeglądarki oraz testu powoduje załamanie się całego systemu operacyjnego :)

  13. Tak czy inaczej niekwestionowanym liderem pod względem (krytycznych) exploitów jest właśnie Adobe z jego runtime’ami (z Flashem na czele oczywiście), więc ten przykład zmienia niewiele.

  14. Królik, Ty po prostu nie masz racji z tymi problemami z dynamicznymi zmiennymi: nie jest prawdą, że nie można inline’ować kodu jeśli występują z nim dynamiczne zmienne. JIT to nie statyczny kompilator, gdzie wszystko dokonuje się na początku, JIT widzi jak używane są zmienne i jeśli widzi, że jakaś zmienna używana jest za każdym razem jako Integer to tak właśnie ją potraktuje! Osobiście nie pamiętam już po prostu kiedy ostatni raz zmieniłem typ danych trzymanych w zmiennej, albo choć czułem taką potrzebę. To że nie deklarujesz typów przy inicjalizacji zmiennej to problem dla statycznych kompilatorów a nie dla optymalizacji w trakcie wykonywania programu.

    Królik: Jeżeli będzie tak jak piszesz, to i tak skończy się pewnie na tym, że złożone aplikacje będzie się pisać w czymś innym niż JS i kompilować do JS. Poza tym, w wielu ciekawych grach wcale nie GPU jest wąskim gardłem – może w FPSach pokroju Quake’a tak, ale w grach, gdzie masz jakieś nietrywialne AI czy realistyczną fizykę, to wydajne CPU to podstawa.
    JITy do JS, owszem poprawiają wydajność, ale brak statycznej specyfikacji typów obiektów w JS bardzo utrudnia generowanie wydajnego kodu – np. bardzo trudno robić wywołania inline (a inline daje często 10x różnicę wydajności otwierając drogę do kolejnych optymalizacji), kiedy nie można statycznie zlokalizować implementacji metody. A w 99% sytuacji nie można zlokalizować, bo wszystko jest dynamiczne i rozstrzygane w czasie wykonania.

    1. Królik pisze:

      Po części masz rację. To fakt, że dynamiczny kompilator może więcej niż statyczny. Ale z tym niezmienianiem typów, to przesadzasz – zmienne w językach obiektowych bardzo często zmieniają typy – poprzez wywołania polimorficzne. W języku statycznie typowanym będziesz mieć w takim miejscu wywołanie wirtualne, które jest bardzo szybkie – kosztuje 1, góra 2 takty CPU. Koszt takiego wywołania w języku dynamicznym jest znacznie większy.

      To że nie deklarujesz typów przy inicjalizacji zmiennej to problem dla statycznych kompilatorów a nie dla optymalizacji w trakcie wykonywania programu.

      Dla tych drugich to też jest problem, bo się muszą dużo więcej napracować. Dużo więcej niż np. JVM. I muszą umieścić w kodzie odpowiednie sprawdzenia na wypadek, jakby odgadnięty typ okazał się być niezgodny z rzeczywistym. Poza tym tego typu analizy ujrzymy w Firefox pewnie nie prędzej niż za 3-4 lata – obecna implementacja działa na zasadzie kompilacji jednej metody na raz, więc większości ciekawych optymalizacji (np. właśnie inferencji typów czy inline) nie jest w stanie wykonać. Stąd na razie jest JS w Firefox jest dużo powolniejszy niż Java czy .NET. W Chromie nieco lepiej, ale Chrome to nie więcej jak 20% rynku.

    2. sieciobywatel pisze:

      Mylisz się. Optymalizacja o której mowa była wprowadzona już w Fx3.5 (TraceMonkey). Dopiero potem wprowadzono wzorowaną na Nitro optymalizację na poziomie metod, co daje gorsze efekty, ale jest bardziej uniwersalne (tracing nie zawsze da się wykonać). To dlatego w wymagających aplikacjach Firefox jest wyraźnie szybszy niż Chrome (np. obróbka kilku mega rekordów). Google skupia się na wydajności na dzisiejszych stronach, dlatego ma lepsze wyniki w testach typu SunSpider czy V8 (nie ujmuję tutaj nic ich inżynierom, Nitro jest naprawdę szybkie… o ile nie wymagamy od niego zbyt dużo).
      Zobacz sobie na przykład:
      http://blog.cdleary.com/2011/06/mapping-the-monkeysphere/

  15. Cornick pisze:

    Pomijając kwestie techniczne – co można zrobić w JS, a czego nie – to JS wymaga dużo więcej mocy obliczeniowej niż F czy SL. Co do tego nie ma wątpliwości. To o czym tu piszą, to daleka pieśń przyszłości. Współczesny, standardowy sprzęt komputerowy nie jest w stanie zapewnić obsługi tych standardów na zadowalającym poziomie, zbliżonym do F czy SL. Tak więc nie tylko trzeba poczekać na rozwój samej technologii, ale też na procesory i karty graficzne zdolne „pociągnąć” tę technologię.

  16. Królik pisze:

    sieciobywatel: Mylisz się. Optymalizacja o której mowa była wprowadzona już w Fx3.5 (TraceMonkey). Dopiero potem wprowadzono wzorowaną na Nitro optymalizację na poziomie metod, co daje gorsze efekty, ale jest bardziej uniwersalne (tracing nie zawsze da się wykonać). To dlatego w wymagających aplikacjach Firefox jest wyraźnie szybszy niż Chrome (np. obróbka kilku mega rekordów). Google skupia się na wydajności na dzisiejszych stronach, dlatego ma lepsze wyniki w testach typu SunSpider czy V8 (nie ujmuję tutaj nic ich inżynierom, Nitro jest naprawdę szybkie… o ile nie wymagamy od niego zbyt dużo).
    Zobacz sobie na przykład:
    http://blog.cdleary.com/2011/06/mapping-the-monkeysphere/

    JS naprawdę szybki wydaje się tylko dlatego, że wszyscy się przyzwyczaili, że jeszcze niedawno był 100x wolniejszy. Natomiast fakty są takie, że przeportowany Quake II wyciąga ledwie 30 FPS, podczas gdy wersja Javowa wyciąga grubo ponad 500 FPS na dobrym sprzęcie. Podobnie jest z przeportowanym niedawno Doomem.

    I co z tego, że 30 FPS wystarczy aby pograć sobie w zabytkową grę, jeśli ktoś inny w szybszej technologii (np. SL, JavaFX, NaCL) zrobi grę również ciągnącą 30 FPS, ale o 10x bogatszej grafice i ciekawszym AI? Czekam na port Minecrafta na JS…

    1. @sieciobywatel: czekałem na Twoją odpowiedź już od poprzednich dyskusji z Królikiem ;)

      Królik, przy każdej dyskusji na temat wydajności JS wspominasz Minecrafta – czyżby dlatego, że jest to jedyna udana i złożona gra napisana w Javie? :)

      A co do Twojego postu pozwól, że go sparafrazuję: JS wolny wydaje się głównie dlatego, że wszyscy się przyzwyczaili, że jeszcze nie dawno był 100x wolniejszy.

      Poczekaj jeszcze chwilę – developerzy dopiero co dostali do rąk te szybsze silniki, dopiero co powstają zoptymalizowane garbage collectory (już nie tylko stop-the-world jak ostatnio pisałeś), dopiero co pojawił się WebGL – jeszcze się Microsoft opiera, żeby go wprowadzić. Ale te rzeczy poprawiają się dramatycznie z miesiąca na miesiąc! Niczego nie ujmując Twojej niewątpliwej wiedzy – straszny z Ciebie niedowiarek w sprawie JS :)

    2. sieciobywatel pisze:

      Stary już jestem, więc pamiętam jak 10 lat temu dokładnie to samo mówiło się o flashu i javie… pożyjemy, zobaczymy.

    1. sieciobywatel pisze:

      Oczywiście masz świadomość, że zostało to opublikowane już po poprawieniu tego w Firefoksie 5? (zapewne także w Chrome, bo Gynvael nie jest idiotą,a wręcz przeciwnie).
      Suchar.

      Nota bene atak jest poprzez Direct3D. Te same problemy będzie miał Silverlight, to samo można zrobić wykorzystując dziurę we Flashu czy innym pluginie.
      Jedyna różnica to, że dziury w swoich implementacjach WebGL będzie łatała Mozilla lub Chrome dla swoich przeglądarek, a przy użyciu Flasha czy „natywnego HTML” (czytaj Silverlight) wszyscy będą zdani na Adobe i Microsoft…