One of those weeks where I hear a technique (in this case “capabilities”) for the first time in ages, then it pops up everywhere.

@cwebber, I presume you saw this: wasi.dev/ and this bzdww.com/article/163937/ ?

@mala ooh! This is interesting. So WASM might well grow into the new.... Java?

Or the new .NET.

Or the new Javascript.

Take... something... at a modern managed-code runtime, anyway.

It's gotta be better than Javascript in that it's not as big.... right?

@natecull @mala
@Shamar

No.

is way more dangerous than or as its execution is not under the conscious control of the user.

There is no way around this: if you run a runtime that automatically executes programs served by a stranger over HTTP, your security is at risk.

The server (or a , or the provider or the , or a like ) could identify you through the data they get from your navigations on other websites and customize that .

@Shamar @natecull @mala @Shamar it's a pretty trivial addition to a browser to make allowing specific wasm/javascript to execute be opt-in.

@Shamar @natecull @mala @Shamar wasm is objectively better than javascript as a programming language because well, its virtual machine is much more sane.

And as the linked article notes, you can use capabilities to actually put stronger runtime limits on particular wasm programs, which is not really possible with java or dotnet afaik.

Capability-based security is the foundation of many verifiable programs such as seL4. Wasm is also designed with verifiability in mind, unlike javascript, java, or dotnet.

@popefucker @natecull @mala @Shamar

I can't really speak for Java, but model is very fine grained and extremely extensible.

docs.microsoft.com/en-us/dotne

Almost a decade ago, I wrote a framework based on to decouple the functionalities provided by a component (eg a method or a class), the runtime properties of the users (eg their roles, the groups the belong to and so on) and the authorization algorithm.

A customer used this framework to build a capability system.

Suivre

@popefucker @natecull @mala @Shamar

In any case, there is a chicken-egg issue in . The 's system is designed for "non-Web system-oriented API" (see github.com/CraneStation/wasmti for details) and is provided as a polyfill for the that can be imported by a .wasm module.

So code served by stranger (and potentially customized to attack the user) will decide which capabilities it requires.

I mean... are we sure they know what they are doing? 🤣

@popefucker @natecull @mala @Shamar

A capability system makes sense in an operating system (and yes, I guess they know very well what they are doing... they want to do what Gates wanted to become with and ), but in a it doesn't add much to the of the user.

OTOH I could be very convenient to convince most people to move to Fuchsia "because the Browser design is inherently flawed, but Fuchsia can run the same application: try it in your browser!"

@Shamar @popefucker @mala @Shamar

Yeah, I was a bit freaked out by reading that. Polyfills in the browser to give arbitrary Posix-style system access???

@natecull @popefucker @mala @Shamar

I didn't tried it, I can't say what they mean. I guess AJAX will work the same as it works now.

Browser's HTTP cache is inherent to , so it will stay the same too...

And I don't know a single operating system that use capabilities for CPU time slices (despite it might be an interesting approach in a real-time ) or RAM quotas, so I guess that users' computing power will be fully available to an attacker as it is today.

1/

@natecull @popefucker @mala @Shamar

If I'm right, an attacker will still be able to gain control over

- the IPs of the users
- their bandwidth
- their RAM
- their computing power
- their disk (through cache)

as I described in bugzilla.mozilla.org/show_bug.

And given the is going to be an optimized , I'm pretty sure it will be way harder to detect an attack like the one I described months ago and the Russian Government is currently running (last comments in the bug report)

@Shamar @popefucker @mala @Shamar

Can you explain what you think the attack mode is that you describe in the bugzilla? Because it's not clear to me.

You're saying that Javascript code from an evil server can do.... what, precisely, on the local machine? Other than consume CPU cycles to mine cryptocoins, for instance? Isn't Javascript sandboxed off from, eg, the filesystem or arbitrary network packet generation for that whole reason?

@Shamar @popefucker @mala @Shamar

I agree that hard resource limits on network-delivered code is something that we desperately need. I think that's why I have to keep restarting Firefox daily now, because pages just run Javascript and... don't stop.

@natecull @popefucker @mala @Shamar

I'm sorry if the bug report is not clear: originally I tried to write it in a leveled way, so that a browser developer could understand its severity without bad guys to notice it.

Unfortunately they were less smart than I though and tried to negate the issue, to move the discussion on (where they never said if is vulnerable to these undetectable attacks) or arguing that it was not possible to fix it (despite the mitigations proposed).

1/

@natecull @popefucker @mala @Shamar

The class of possible attacks is huge and though simple cache headers, an attacker can easily remove any evidence of the attack.

The first exploit that I wrote is at dev.to/shamar/the-meltdown-of-
The linked fiddler tunnel into your private network to test the open ports on your PC.

Later @rain extended the attack to the other computers on your LAN (behind firewall and proxy) to discover their IP and open ports: rain-1.github.io/in-browser-lo

2/

@natecull @popefucker @mala @Shamar @rain

(Meanwhile I was banned from dev.to/shamar/i-have-been-bann but I'm not sure anymore that it was due only to 's lobbying, as I discovered that one of their admin works for )

Since 2 like these were not enough to convince developers to fix the issue, the Russian Government felt authorized to use the attack to identify the people who were taking counter-measures (probably to build a of ).

3/

@Shamar @natecull @popefucker @mala @Shamar @rain you weren't banned because of "google employees" but because you repeating points ad infintium instead of engaging in dialogue

for the audience at home, this was the thread that was the last straw: lobste.rs/s/pnfmzr/google_cert

@calvin

I engaged on dialogue in any possible way on any possible channel I was able to.

Here can read a chronological history here: dev.to/shamar/comment/5dp2

However the ' admin didn't say that they were banning me for this issue but because of the deviations of my downvotes from the average pf downvotes (not considering all upvotes that were even more).

@natecull @popefucker @mala @Shamar @rain

@calvin @natecull @popefucker @mala @Shamar @rain

In any case, I wasn't just trying to engage.

I was trying to inform people!

It was before the Russian Government started to use those attacks and 's developers (that in the bug report suggested to continue the conversation on ) hadn't yet answered this simple question: "are users vulnerable to this wide class of undetectable attacks?"

They are leaving their users vulnerable without informing them!

That's Linus, from Charles Shultz's strip, Peanuts.

@deejoe

Sorry, you are right: he is Linus.
(I really need to sleep more...)

@Shamar @popefucker @mala @Shamar @rain

I'm sorry but I still don't understand what you're saying at that first link. So I can see why Firefox devs just closed your bug. What exactly IS the problem? What is the thing that Javascript can do, and why shouldn't it be able to do it?

(Note: I don't use JSfiddle, and I'm not about to change my localhosts file. And I'm not going to click on a link that says it's an exploit, without something EXPLAINING what the exploit IS.)

@natecull @popefucker @mala @Shamar @rain

The change to your host file simulated a rebinding.
Actually some ISP rebind by default certain domains to 127.0.0.1 so the attacked might just use these.

But I was naive to introduce such indirection: the attack works even if you don't modify the host file and simply use "127.0.0.1" as the host in the code.

1/

@natecull @popefucker @mala @Shamar @rain

Anyway, this specific attack (that is just one of infinite many one could conceive and was the fifth I conceived myself) is trivial to understand: to test port 1, it create an image with an url like "https://127.0.0.1:1/img.gif" and measure the time for the page to load.

If the port is closed, the page will take a lot of time to load because the browser's timeout have to kick, instead if the port is open it fails fast.

Thus one can map your LAN w/JS.

@Shamar @popefucker @mala @Shamar @rain

Ok so let me get this straight. The entire core of your worry is about

1) portscanning

2) using AJAX queries

3) and cache timing

4) having first tricked the user via dodgy DNS into executing Javascript from a web page that resolves to 127.0.0.1, because it won't work from any arbitrary server IP?

@natecull @popefucker @mala @Shamar @rain

Why you assume I'm dumb?

Please read the article, an attacker can access to any service on your LAN and send over the web any content there through these attack.

Or he can send content inside your LAN.

Or he can poison your cache with illegal contents.

Without leaving evidences.

I mean: the Russian Government is exploiting these attacks in the wide and building a database of people who could detect them.

Do you think they are doing what?

@Shamar @popefucker @mala @Shamar @rain

I wasn't assuming that you are dumb, but I don't think you're communicating well.

I've read your article and I didn't understand it. That's why I'm asking you to explain.

I'm still not hearing you say what the *mechanism* of this exploit is.

What is it that Javascript is doing that it shouldn't do?

@natecull @popefucker @mala @Shamar @rain

> What is it that Javascript
> is doing that it shouldn't do?

That specific is allowing an attacker to tunnel into your private network despite your and .

This is a flaw in the architecture of the as designed by : anyone who is able to identify the targets and serve to their browser (which include, hosting service providers, clouds, cdn, MitM like cloudflare, advertisers and so on) can have it executed.

@Shamar @popefucker @mala @Shamar @rain

Yeah, see, you need to work on your phrasing here. 'Tunnel into' is not a particularly good choice of words because tunnelling protocols are not involved.

The design of the web always did allow any web page to make a link to any local IP address.

I think perhaps what you're saying is that you think AJAX queries should have restrictions on the sites that they can send packets to?

@natecull @popefucker @mala @Shamar @rain

No, it's not enough.

Even making execution opt-in per website and disabled by default (as let you do in the settings, but don't), is not a solution but a partial mitigation.

Other important mitigations address the identification phase, reducing the risk to identify the user that is going to receive the in several ways (not reusing the TCP connection, not sending any cookie when requesting it and so on).

@Shamar @popefucker @mala @Shamar @rain

Yeah, see, just saying 'turn off Javascript', that's why people aren't listening to you. That means turning off all of the Web.

What would mitigate this perceived attack vector SHORT OF turning off Javascript?

How could Javascript be modified to prevent this attack?

@Shamar @popefucker @mala @Shamar @rain

en.wikipedia.org/wiki/XMLHttpR
<< In the early development of the World Wide Web, it was found possible to breach users' security by the use of JavaScript to exchange information from one web site with that from another less reputable one. All modern browsers therefore implement a same origin policy that prevents many such attacks, such as cross-site scripting. >>

So... you're saying you've found a cross-domain exploit. Because this should not be possible?

@Shamar @popefucker @mala @Shamar @rain

<< for example, making an XMLHttpRequest from a page created by foo.example.com for information from bar.example.com will normally fail. >>

So how is your attack able to read arbitary local IP addresses?

@natecull @popefucker @mala @Shamar @rain

The I proposed do not use .

If you can programmatically modify the and trigger a , you can send any request you want anywhere.

Disabling JavaScript BY DEFAULT do not turn of the . That's what a lot of people say, but did you tried?
You didn't.

Most of it work fine.
Even , , and (!!!) work like a charm.

1/

@Shamar @popefucker @mala @Shamar @rain

I understand that you are telling me 'turn off Javascript', but listen - NO. That is the wrong answer.

What you just said in the second paragraph? THAT'S the meat of your bug . Using DOM events instead of XmlHTTPRequest (I don't know why you are hashtagging all of those).

But you never said that in your bug request. That's why people didn't listen.

Afficher plus

@natecull @popefucker @mala @Shamar @rain

Also this is NOT a single cross-domain exploit. It's a wide class of attacks, all undetectable!

Suppose I attack you and put some illegal content (imagine stolen source code) into the cache of your browser and execute from your browser a set of requests to the servers from which it was stolen.

Police follow the IP, find your home and see the stolen sources in your browser cache.

I left no evidence of my attack.

I'm .

What do you do?

Afficher plus

@Shamar @popefucker @mala @Shamar @rain

I thought that XmlHTTPRequest *did* have such restrictions, so that Javascript loaded from a domain could only send queries to hosts on the same domain, but I guess what you're saying is this isn't being restricted for some reason?

@natecull @Shamar @popefucker @mala @Shamar @rain XHR and fetch() have to obey the Same Origin Policy, yes. So either the server has CORS set up, or the attack uses other kind of resource downloads (images, style sheets for instance).

@fabricedesre @natecull @popefucker @mala @Shamar @rain

Exactly.

I create through a malicious jquery.js a 1x1 image equivalent to

<img src="illegal.contents.com/source/co>

When the page load finish, I know the sources are in your cache, I remove the image and reload the javascript with an harmless one to rewrite your cache (I previously served the malicious jquery.js with proper http cache control).

A very advanced technique, don't you think? 😉

@fabricedesre @natecull @popefucker @mala @Shamar @rain

But PLEASE, understand this is just the first attack I conceived. There are tons of possible others!

Afficher plus

@Shamar @fabricedesre @popefucker @mala @Shamar @rain

Ah, I see. Someone on 20 March added this section to the Wiki page. Was it you, or rain?

These few lines at least are MUCH more descriptive about what the actual attack involves.

en.wikipedia.org/wiki/Same-ori

Afficher plus

@natecull @popefucker @mala @Shamar

You can see the code without running it in the @rain's article.

But note, these are just two of the possible attacks.

If your browser authenticate automatically to a service on your LAN (imagine through windows authentication), with a rebinding attack a malicious might access to such service.

It's true you can't frame an arbitrary packet in the browser, but how many services run over HTTP today?

Inscrivez-vous pour prendre part à la conversation
Framapiaf

Framapiaf est un service de microblog similaire à Twitter. Il est libre, décentralisé et fédéré. Il permet de courts messages (max. 500 caractères), de définir leur degré de confidentialité et de suivre les membres du réseau sans publicité ni pistage.