Closed Bug 1487081 Opened 6 years ago Closed 6 years ago

Undetectable Remote Arbitrary Code Execution Attacks through JavaScript and HTTP headers trickery

Categories

(Firefox :: General, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: giacomo, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180807170231

Steps to reproduce:

This class of attacks is simply described with a short analysis or their geopolitical and legal implications at https://medium.com/@giacomo_59737/the-web-is-still-a-darpa-weapon-31e3c3b032b8#5eab


Pre conditions:
- Either:
  - Control a web site  (either by being the owner or by controlling its hosting) using javascript that authenticate or otherwise identify users and/or user groups
  - Control a CDN and be able to identify users through info collected over several sites (thing of Google Cloud CDN, Amazon AWS and so on)

Undetectable Remote Arbitrary Code Execution Attack:

One can serve to one user or to a specific set of users, only once, a malicious javascript that got control of several users' resources

- their IP
- their bandwith
- their computing power
- their RAM
- their disk (through browser cache)
- potentially others resources (gained through access to system vulnerabilities, think about Spectre/Meltdown)

to execute or coordinate an attack to a third party's web site, forging evidences on the users' machine that indict the users' themselves.

As a simple example the server/CDN could put in the browser cache illegal contents that would be trivial to find during a forensic analysis. 

After the attack the JavaScript (originally served with proper Cache-Control) can replace itself in the browser cache with a harmless version from the same URI, leaving no evidence of the attack.

Further attacks can retrieve the previously installed illegal contents from the cache, (verifying they are the illegal cached ones by timing the load time) and send them over the Internet, for whatever reason.

And so on, the simple fact that the browser bindly execute customizable programs open to a wide set of attacks despite the sendboxing and same origin policy.

Some of the cache related attacks can be achieved with other techniques (eg custom CSS + HTTP Cache controls + pages that reload themselves through HTML META refresh) but they are more observable and risky.
They should be fixed anyway, but have a lower impact over the users' security, people safety and Free Speech


Actual results:

Several resources of an unaware user have been used against him, in various ways and outcomes depending on the laws of his Nation.

Also, an actual criminal could use the existence of this wide class of attacks to gain plausible deniability.


Expected results:

The browser should not blindly execute programs that could be customized to attack the user. 

This sort of attacks will be made even worse through the distribution of optimized WebAssembly (that will be way more obscure than obfuscated JavaScript)
Isn't this why Sub-Resource Integrity was created?
Flags: needinfo?(giacomo)
This is not a bug in Firefox.
Bugzilla is not a discussion forum.

Furthermore, what you seek to discuss is not specific to Mozilla or Firefox.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Flags: needinfo?(giacomo)
Resolution: --- → INVALID
To clarify, this post is not intended to stop the discussion. It just needs to move to a forum that is meant for discussions.
Please read our etiquette and contributor guidelines at <https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>.

I also noticed that people discuss this in other discussion forums already. E.g., https://lobste.rs/s/vwcetz/undetectable_remote_arbitrary_code
(In reply to Frederik Braun [:freddyb] from comment #2)
> This is not a bug in Firefox.

Are you saying that these attacks are not possible?

If so, can you please elaborate?

> Bugzilla is not a discussion forum.

Indeed this is a bug report.

Before filling the report I searched for similar issues: I've found some but none actually tackling the core problem.

> Furthermore, what you seek to discuss is not specific to Mozilla or Firefox.

True. Several other browsers are affected too, but:

1. This doesn't means that it's not a bug in Firefox
2. As a browser "built for people, not for profit" I think you are more interested about the topic.

Furthermore I was suggested by a Mozilla developer to fill a bug here: https://wandering.shop/@callahad/100621620793416331/embed
The current behavior appears to be dictated by the various specifications of the web. How would you "fix" this bug?

Dan: what did you have in mind?
Flags: needinfo?(dan.callahan)
(In reply to Daniel Veditz [:dveditz] from comment #5)
> The current behavior appears to be dictated by the various specifications of
> the web. 

Well... fortunately they are "Living" Standards, so fixing Firefox might fix them too...

> How would you "fix" this bug?

Well, given the severity of the issue, as a first step I would release an emergency fix that disable JavaScript (and Meta Refresh) without looking at the user settings.

Then I would deploy a mid term fix so that:

- Meta Refresh and JavaScript are disabled by default
- Both can be enabled on a per website basis,
  - SubResource Integrity is made mandatory (at least for JavaScript): page
  - For each URI record SHA256 of last downloaded content and warn the user if the page change their SRI
  - Warn the user about scripts served with suspect HTTP headers

Obviously this leave the door open for page that:

- are visited only once
- are visited for the first time

thus I would also mark as "Not Secure" web pages visited for the first time that require JavaScript.

In the long term, we will need less primitive operating systems that are able to distribute the computation in a safe way.
(In reply to Giacomo from comment #6)
> (In reply to Daniel Veditz [:dveditz] from comment #5)
> > The current behavior appears to be dictated by the various specifications of
> > the web. 
> 
> Well... fortunately they are "Living" Standards, so fixing Firefox might fix
> them too...
> 
> > How would you "fix" this bug?
> 
> Well, given the severity of the issue, as a first step I would release an
> emergency fix that disable JavaScript (and Meta Refresh) without looking at
> the user settings.
> 
> Then I would deploy a mid term fix so that:
> 
> - Meta Refresh and JavaScript are disabled by default
> - Both can be enabled on a per website basis,
>   - SubResource Integrity is made mandatory (at least for JavaScript): page
>   - For each URI record SHA256 of last downloaded content and warn the user
> if the page change their SRI
>   - Warn the user about scripts served with suspect HTTP headers
> 
> Obviously this leave the door open for page that:
> 
> - are visited only once
> - are visited for the first time
> 
> thus I would also mark as "Not Secure" web pages visited for the first time
> that require JavaScript.
> 
> In the long term, we will need less primitive operating systems that are
> able to distribute the computation in a safe way.

Disabling JavaScript by default would break the web, and many users would not know that they need to enable JavaScript in order to "fix" the web. Furthermore, if this is an issue then it is an issue that spans all browsers and would require coordination and planning between all browsers to successfully implement, which a large grace period for developers to fix their websites to not require JavaScript.

When the solution to a problem is to build "less primitive operating systems" then that seems like enough reason that it's not a bug in Firefox. :/
Oh, I forgot to mention that on browser exit, I would remove from the cache all resources downloaded by pages that have Meta Refresh and/or JavaScript enabled.
(In reply to Bailey Stoner from comment #7)
> Disabling JavaScript by default would break the web, and many users would
> not know that they need to enable JavaScript in order to "fix" the web.

It have been appointed to me by Frederik that this is not a discussion forum.

I hope he will forgive me if I make you notice that most users do not know that they need to DISABLE JavaScript to avoid the risk of these attacks.

And honestly, editing about:config to disable JavaScript could be defined as "Insecurity through obscurity".

> Furthermore, if this is an issue then it is an issue that spans all browsers
> and would require coordination and planning between all browsers to
> successfully implement, which a large grace period for developers to fix
> their websites to not require JavaScript.

To be honest I think that the safety of people is more important than the development costs.

> When the solution to a problem is to build "less primitive operating
> systems" then that seems like enough reason that it's not a bug in Firefox.
> :/

Are you stating that the attacks described above cannot affect a Firefox user?

That would settle the matter.

Otherwise, the status of this bug should be changed and the issue fixed as soon as possible. 


That's why this is the first question to answer here: the ATTACKS described above possible in Firefox?
(In reply to Daniel Veditz [:dveditz] from comment #5)
> Dan: what did you have in mind?

I had RESOLVED INVALID in mind; this is the Web functioning as designed.
Flags: needinfo?(dan.callahan)
(In reply to Frederik Braun [:freddyb] from comment #3)
> To clarify, this post is not intended to stop the discussion. It just needs
> to move to a forum that is meant for discussions.
> [...]
> I also noticed that people discuss this in other discussion forums already.
> E.g., https://lobste.rs/s/vwcetz/undetectable_remote_arbitrary_code

That link to that discussion is currently broken.

I retrieved last contents from my Firefox cache, added a <base> tag to preserve formatting and published on github for future references.

https://shamar.github.io/documents/Mozilla-Bug1487081-Attachments/Undetectable_Remote_Arbitrary_Code_Execution_Attacks_through_JavaScript_and_HTTP_headers_trickery__Lobsters.html

Feel free to suggest another platform if you need more info that are not appropriate for bugzilla.

We can even continue on the fediverse from https://mastodon.social/web/statuses/100638280108943999 if you prefer.
Cross-posted to Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=879381

As for possible mid term mitigations I also realized that:

- the requests generated by <script> and <stile> and the request whose response would be executed with eval() should 
  - not contain ANY Cookie or other HTTP headers that could be used to identify the user 
  - be done over different TCP connections

This is just a mitigation, since the IP could still be used to identify the user in certain conditions, but it would help in several others.
Another mitigation would be to avoid sending new requests for view-source.

I noticed that, depending on the HTTP headers of the response that served a page, "View Page Source" GET a new copy from the server: the user didn't ask to view the source of the page on the server, but the one that was rendered and executed to produce what he is seeing.

This might seem a subtle difference, but could cover an attack.
> as a first step I would release an emergency fix that disable JavaScript (and
> Meta Refresh) without looking at the user settings

is this a joke? if you disable javascript you are going to break large chunks of
the internet. here are just a few sites that would be partially or completely
broken:

- http://bandcamp.com
- http://gfycat.com
- http://github.com
- http://google.com
- http://reddit.com
- http://soundcloud.com
- http://stackexchange.com
- http://vimeo.com
- http://youtube.com

if you have a legitimate concern, you should do the sane thing and, oh i dont
know, send a patch to javascript? JavaScript is out, you cant unring that bell.
so when you post (2) issues and a blog post with the sky is falling you come off
looking absurd, and rightfully so.
> if you disable javascript you are going to break large chunks of the internet.
> here are just a few sites that would be partially or completely broken: [...]

I'm sorry for them. But they can be fixed too.

Anyway, here is the Proof of Concept of one of the many possible attacks your users are vulnerable to:

https://dev.to/shamar/the-meltdown-of-the-web-4p1m

Please follow the instructions and try the JSFiddle script by yourself.


I think you (and Google... and every other WHATWG member) have the right to choose to NOT FIX this class of attacks to protect your legittimate COMMERCIAL interests. Really, your money, your time... your brand.

But if you choose so, you should clearly inform your users.
Including corporate ones. And governements.


As for me, I don't care much about how I look. 
Absurd? Fine. It's better than troll, after all... ;-)

I just care about my many friends all over the world that are vulnerable to these attacks because I taught them to trust Mozilla.
I know that "this is the Web functioning as designed", but I have received a report of one of these attack conducted by a Russian Government's website to portscan the visitors machines.

The script url is at https://rkn.gov.ru/5a71c95863f38b1dcfcbb763.js but the page that was serving this was not included in the report.

At a first glance there are several suspect statements in the code which totally resemble the attacks I described here (and in the PoC I published some months ago). Look for "127.0.0.1" for a starting point in your forensics. Other suspect points are the loops from 1 to 2^16 - 1, but I can't dwell deeper right now.

I can't further analyze the script till tomorrow evening (and maybe later) so I thought it was my duty to inform you.

Obviously there could be several other explainations, including incompetence, but since incompetence is so spread in our field to provide plausible deniability for actual attackers... it's better to be more careful than not.

Also another similar PoC exploit of these attacks waa published shortly after mine to show how to portscan and map the whole networks of website visitors, tunnelling through their firewall and proxy: https://rain-1.github.io/in-browser-localhostdiscovery


I strongly suggest you to reconsider both the emergency fix and the stable mitigations I proposed in this bug report.

Or to deploy alternative mitigations to protect Firefox users.

In any case, please inform people.
Little update: the script is simply included in the homepage of the web site https://rkn.gov.ru/

I dumped a beautified version at https://pastebin.com/embed_iframe/2VH55Lu0 and it is easy to see how it scan ports on 127.0.0.1 looking for some specific security tools (see lines 2615 and following).
You need to log in before you can comment on or make changes to this bug.