Announcement

Collapse
No announcement yet.

The Greenfield In-Browser Wayland Compositor Is Fast Enough For Gaming

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Weasel View Post
    Dude you are a lost cause. If code exploiting the X11-written-in-WASM exists, then it can exploit the entire system directly by bypassing X11 entirely. Because WASM is arbitrary code execution (within a sandbox, but it can have exploits of course). It's not like the X11-written-in-WASM has higher privilege.
    This is you ignoring the history examples with WiredX.

    Where is the data you are targeting Weasel.

    [wasm malware in browser] This is one sandbox.
    [wasm application in browser] this is in different sandbox. This has the golden data wasm malware wants. This is simple example right. Wasm application can be using canvas and other options in browser that make it hard for the wasm malware.

    Now lets look at greenfield.
    [wasm malware in browser] this again in one sandbox.
    [Greenfield Wayland compositor] this is number 2 sandbox.
    [Greenfield Wayland application running in hidden iframe] number 3 sandbox.

    Yes you now depend on insecure Wasm XSS that the malware now can target. Yes all output from the application is crossing over the XSS that poorly secured. This is also true with WiredX done back in the Java day.

    Running 2 wasm instead of one using greenfield does increase your attack surface area because the messaging between the two wasm applications cannot be secured inside current browsers. .


    arbitrary code execution inside a sandbox does not mean you can access everything. Wasm malware cannot by design go snooping around in memory of other wasm applications running in the same window/tab. Instead Wasm malware end up targeting wasm communication to trick the Wasm application into giving it the information it wants.


    X11 or Wayland in Wasm is going to give large attack surface by increasing the XSS communication.

    Comment


    • #22
      Originally posted by oiaohm View Post
      Now lets look at greenfield.
      [wasm malware in browser] this again in one sandbox.
      [Greenfield Wayland compositor] this is number 2 sandbox.
      [Greenfield Wayland application running in hidden iframe] number 3 sandbox.

      Yes you now depend on insecure Wasm XSS that the malware now can target. Yes all output from the application is crossing over the XSS that poorly secured. This is also true with WiredX done back in the Java day.
      And what stops malware itself from adding hidden iframes? It has the same privilege as the Wayland compositor.

      Comment


      • #23
        Originally posted by Weasel View Post
        And what stops malware itself from adding hidden iframes? It has the same privilege as the Wayland compositor.
        That a presume on the privilege bit.

        Some of the security stuff need does exist now
        https://developer.mozilla.org/en-US/...urce_Integrity.
        This did not exist in the time of wiredX being in serous development.

        Now if you malware is load itself in iframe depend on the browser some browsers will not allow it to create a new iframe.

        The wayland compositor in greenfield is the primary app.

        Remember with the Wayland protocol design being in the iframe against greenfield is not going to allow straight up attack. Now being in the iframe with wiredX due to X11 lack of limitation hello straight up attack.

        Against greenfield the wasm malware will want to target the XSS communication itself so it can pretend to be something its not.

        Weasel there are levels of privilege inside a browser just how these work is not defined by the standards. This is area that need changing so you cannot have a case of like a website advertisement running javascript/wasm malware.... with the privillage todo what ever it likes just because you happen to use a lower security browers.

        Yes the browsers uses commonly use are lower security browsers.

        Remember without using XSS communication how do you think you are going to add a new iframe to a page. All the HTML DOM/page altering operations are XSS communications.

        Yes fun right they added subresource integrity generically but then did not add at fly this resource is read only or this resource can only be modified by X location. Yes a lot of attempt to add that user cannot modify website.

        For administrators who manage Chrome policies from the Google Admin console. As a Chrome Enterprise admin, you can protect your organization's webpages from being modified by Chrome apps and extensio


        Yes it get more stupid. If the malware is a browser extension you can prevent it from messing with particular web pages if you are using particular browsers.

        See weasel there is no unified standard for this stuff. There is example after example that it possible to add the frameworks to the browser standards to make wasm/javascript/java malware mostly a non issue because they would be sandboxed from be able to access anything important but this has never been implemented.

        This flaw is one of the reasons why sometime like greenfield will have trouble getting company take up.

        Comment

        Working...
        X