Isn't this why Sub-Resource Integrity was created?
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
Last Resolved: 7 months ago
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?
(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.
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.
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.