Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

NoScript bug? #973

Closed
KOLANICH opened this issue Jul 10, 2020 · 3 comments
Closed

NoScript bug? #973

KOLANICH opened this issue Jul 10, 2020 · 3 comments
Labels
invalid

Comments

@KOLANICH
Copy link

KOLANICH commented Jul 10, 2020 •
edited by Thorin-Oakenpants

Name Firefox
Version 78.0.1
Build ID 20200630195452
NoScript 11.0.33 true {73a6fe31-595d-460b-a920-fcc0f8843232}

The OS is Ubuntu 20.04.

All the other webexts are disabled and the browser has been restarted.

<!doctype html>
<html>
	<head>
		<title>NoScript bypass</title>
		<script>
			alert("hello world");
		</script>
	</head>
</html>
@KOLANICH
Copy link
Author

P.S. The file has been served over HTTP using a local web server on 127.0.0.1. In the wild the bypass has been observed in Google search results (not all the queries, it seems it depends on a query, the query was a constant from a very popular open source library written in C).

@hackademix
Copy link

This was a 11.0.33 regression from the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1650305, and it's fixed in 11.0.34 (already in auto-update).

@KOLANICH, if you wanted to do something useful you could have reported in a place where I could actually notice it.
I've seen your troll "report" just because someone else reported it here: https://forums.informaction.com/viewtopic.php?p=102453#p102449

And fortunately I had already fixed the issue by that time.

@Thorin-Oakenpants Thorin-Oakenpants changed the title 4YI: Yet another catastrophic failure of NoScript NoScript bug? Jul 11, 2020
@KOLANICH
Copy link
Author

@hackademix,

  1. My main goal was to warn the people to be careful. When I saw the bug, I had to flip javascript.enabled to mitigate it. I was pretty sure that somewhen it will reach you and be fixed.
  2. It was not the first time NoScript CSP-based protection has been bypassed (including compromise within Tor Browser, so for Tor Browser I recommend not to rely on NoScript and just set javascript.enabled into false, even if it will break pdf.js and some of the about: pages).

I cannot blame you for Mozilla's design choices (the proper solution is to implement capabilities equivalent to javascript.enabled but per a browser tab, and allow extensions to change them, see https://bugzilla.mozilla.org/show_bug.cgi?id=1553791 for more info). But it is obvious that any protection based on CSP is pretty unreliable, CSP was not designed for this use case, in fact the browsers have not been designed with supporting such usage of webextensions in mind. I feel like CSP-based protection is not enough and should be supplemented by filterResponseData: we should just cut all the active content out of the HTML. Of course it will cause overhead and latency (again, the proper solution with smaller overhead can be https://bugzilla.mozilla.org/show_bug.cgi?id=1553791 ) and some maintaince burden (we also need to sanitize on* attrs in HTML, and the list of them needs maintainment, I wonder if we can parse the list from Firefox source code available on DXR), but it is better than allowing malware to be run, right?

https://forums.informaction.com

Long ago I have tried to sign-up there, but was presented with an unsolvable reCAPTCHA. As you see, your forum is very visitor-friendly. Have never visited that forum after that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
invalid
Milestone
No milestone
Development

No branches or pull requests
3 participants
@KOLANICH @hackademix @Thorin-Oakenpants