@mala ooh! This is interesting. So WASM might well grow into the new.... Java?
Or the new .NET.
Take... something... at a modern managed-code runtime, anyway.
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 #CDN, or the #hosting provider or the #cloud, or a #Cloudflare like #MitM) could identify you through the data they get from your navigations on other websites and customize that #program.
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.
In any case, there is a chicken-egg #security issue in #WASM. The #WASI's #capability system is designed for "non-Web system-oriented API" (see https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-overview.md for details) and is provided as a polyfill for the #Web that can be imported by a .wasm module.
So #WebAssembly 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? 🤣
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 #DotNET to become with #WASM and #Google #Fuchsia), but in a #browser it doesn't add much to the #security 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!"
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 #HTTP, 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 #OS) or RAM quotas, so I guess that users' computing power will be fully available to an attacker as it is today.
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 https://bugzilla.mozilla.org/show_bug.cgi?id=1487081
And given the #WASM is going to be an optimized #binary, 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 #Mozilla bug report)
Can you explain what you think the attack mode is that you describe in the bugzilla? Because it's not clear to me.
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 #Lobsters (where they never said if #Firefox is vulnerable to these undetectable attacks) or arguing that it was not possible to fix it (despite the mitigations proposed).
The class of possible attacks is huge and though simple #HTTP cache headers, an attacker can easily remove any evidence of the attack.
The first #PoC exploit that I wrote is at https://dev.to/shamar/the-meltdown-of-the-web-4p1m
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: https://rain-1.github.io/in-browser-localhostdiscovery
(Meanwhile I was banned from #Lobsters https://dev.to/shamar/i-have-been-banned-from-lobsters-ask-me-anything-5041 but I'm not sure anymore that it was due only to #Mozilla's lobbying, as I discovered that one of their admin works for #Google)
Since 2 #exploits like these were not enough to convince #Firefox 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 #db of #suspects).
for the audience at home, this was the thread that was the last straw: https://lobste.rs/s/pnfmzr/google_certbot_letsencrypt#c_2xs6cg
I engaged on dialogue in any possible way on any possible channel I was able to.
Here can read a chronological history here: https://dev.to/shamar/comment/5dp2
However the #Lobsters' 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).
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 #Mozilla #Security's developers (that in the bug report suggested to continue the conversation on #Lobsters) hadn't yet answered this simple question: "are #Firefox users vulnerable to this wide class of undetectable attacks?"
They are leaving their users vulnerable without informing them!
Sorry, you are right: he is Linus.
(I really need to sleep more...)
(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.)
The change to your host file simulated a #DNS 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.
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.
Ok so let me get this straight. The entire core of your worry is about
2) using AJAX queries
3) and cache timing
Why you assume I'm dumb?
Please read the article, an attacker can access to any #HTTP 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?
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.
> is doing that it shouldn't do?
This is a flaw in the architecture of the #Web as designed by #WHATWG: anyone who is able to identify the targets and serve #JS to their browser (which include, hosting service providers, clouds, cdn, MitM like cloudflare, advertisers and so on) can have it executed.
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?
No, it's not enough.
So... you're saying you've found a cross-domain exploit. Because this should not be possible?
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.
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.
What do you do?
I create through a malicious jquery.js a 1x1 image equivalent to
A very advanced technique, don't you think? 😉
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.
You can see the code without running it in the @rain's article.
But note, these are just two of the possible attacks.
It's true you can't frame an arbitrary #TCP packet in the browser, but how many services run over HTTP today?
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.