[RESOLVED] samy.pl bypasses NS content blocking (Java)

Post a reply

Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:

BBCode is ON
[img] is ON
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: [RESOLVED] samy.pl bypasses NS content blocking (Java)

Re: [RESOLVED] samy.pl bypasses NS content blocking (Java)

by Giorgio Maone » Mon Dec 06, 2010 3:37 pm

Giorgio Maone wrote: It's a side effect of logging itself.
[...]
I'm working around this by simply enclosing the logging code in a try {} cacth {} block, since this is quite an edge case.
Fixed in latest development build.

Re: [RESOLVED] samy.pl bypasses NS content blocking (Java)

by Giorgio Maone » Sat Dec 04, 2010 3:14 pm

al_9x wrote:My profile wasn't totally clean, I narrowed it down to specific settings.
[...]
3) noscript.consoleDump=4
[...]

Code: Select all

[NoScript] Error enumerating sites: [Exception... "Component is not available"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: chrome://noscript/content/Main.js :: anonymous :: line 3784"  data: no],undefined
It's a side effect of logging itself.
The LiveConnect interception adds a dummy applet to the page and removes its immediately, in order to trigger the content policy and cause the "Blocked Sites" menu to be populated.
Since the applet has already been disconnected from the document by the time the site enumeration code is hit, when its cached reference gets logged its toSource() method fails because of some property (don't ask me which) not being available anymore.

I'm working around this by simply enclosing the logging code in a try {} cacth {} block, since this is quite an edge case.

Re: [RESOLVED] samy.pl bypasses NS content blocking (Java)

by al_9x » Sat Dec 04, 2010 2:00 pm

My profile wasn't totally clean, I narrowed it down to specific settings.

Starting with a new profile:

1) Apply to trusted
2) remove about:blank from whitelist
3) noscript.consoleDump=4
4) load the test page
5) allow it
6) click PI
8) you should get the partial icon with about:blank in the menu, also, the following error, which is probably the cause:

Code: Select all

[NoScript] Error enumerating sites: [Exception... "Component is not available"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: chrome://noscript/content/Main.js :: anonymous :: line 3784"  data: no],undefined

Re: samy.pl bypasses NS content blocking (Java)

by Giorgio Maone » Sat Dec 04, 2010 12:11 pm

al_9x wrote: Is it possible to be notfified and cache the enabled state?
Unfortunately not. I checked the "plugin-list-updated" notifications (which, together with "plugin-crashed" is the only observable event fired by PluginHost), but it is triggered only by navigator.plugins.refresh().

al_9x wrote: Also, I noticed that after clicking the liveconnect link in http://samy.pl/natpin/ , the page navigates to # (expected), and "about:blank" is shown in the NS menu. It has something to do with the empty iframe on the page.

Code: Select all

<iframe name="A" style="display:none"></iframe>
Normally, about:blank is excluded, but somehow the liveconnect blocking is changing this.
Here's a simple page:

Code: Select all

<a href="#" onclick="alert(java.lang.Math.PI);">PI</a>
<iframe></iframe>
If you disable interception or disable Java, it does not happen.
I can't observe this. Tested both on Minefield and Firefox 3.6.12 (default NoScript options + extended embedding restrictions); all it happens when I click the link is the URL changing to (...)# and the Blocked Objects menu being added of Java-enablement options.

Re: samy.pl bypasses NS content blocking (Java)

by al_9x » Sat Dec 04, 2010 12:51 am

Giorgio Maone wrote:
al_9x wrote:In 2.0.8rc1, it looks like the plugins toggling and liveconnect injection take place even when the Java plugin is disabled. Is that right? Would it not make sense to check before calling interceptLiveConnect? Is it an expensive operation? Perhaps it's possible to be notified and cache the Java state?
It's relatively expensive and in some circumstances (which I coudln't reproduce reliably) it fires a JVM.
Is it possible to be notfified and cache the enabled state?
Giorgio Maone wrote:
al_9x wrote: Also, I noticed that after clicking the liveconnect link in http://samy.pl/natpin/ , the page navigates to # (expected), and "about:blank" is shown in the NS menu. It has something to do with the empty iframe on the page.

Code: Select all

<iframe name="A" style="display:none"></iframe>
Normally, about:blank is excluded, but somehow the liveconnect blocking is changing this.
No idea, investigating. Does it happen also on a reduced test case (the iframe only)? Does disabling liveconnect interception change anything?
Here's a simple page:

Code: Select all

<a href="#" onclick="alert(java.lang.Math.PI);">PI</a>
<iframe></iframe>
If you disable interception or disable Java, it does not happen.

Re: samy.pl bypasses NS content blocking (Java)

by Giorgio Maone » Sat Dec 04, 2010 12:34 am

al_9x wrote:In 2.0.8rc1, it looks like the plugins toggling and liveconnect injection take place even when the Java plugin is disabled. Is that right? Would it not make sense to check before calling interceptLiveConnect? Is it an expensive operation? Perhaps it's possible to be notified and cache the Java state?
It's relatively expensive and in some circumstances (which I coudln't reproduce reliably) it fires a JVM.

al_9x wrote: Also, I noticed that after clicking the liveconnect link in http://samy.pl/natpin/ , the page navigates to # (expected), and "about:blank" is shown in the NS menu. It has something to do with the empty iframe on the page.

Code: Select all

<iframe name="A" style="display:none"></iframe>
Normally, about:blank is excluded, but somehow the liveconnect blocking is changing this.
No idea, investigating. Does it happen also on a reduced test case (the iframe only)? Does disabling liveconnect interception change anything?

Re: samy.pl bypasses NS content blocking (Java)

by al_9x » Sat Dec 04, 2010 12:29 am

In 2.0.8rc1, it looks like the plugins toggling and liveconnect injection take place even when the Java plugin is disabled. Is that right? Would it not make sense to check before calling interceptLiveConnect? Is it an expensive operation? Perhaps it's possible to be notified and cache the Java state?

Also, I noticed that after clicking the liveconnect link in http://samy.pl/natpin/ , the page navigates to # (expected), and "about:blank" is shown in the NS menu. It has something to do with the empty iframe on the page.

Code: Select all

<iframe name="A" style="display:none"></iframe>
Normally, about:blank is excluded, but somehow the liveconnect blocking is changing this.

Re: samy.pl bypasses NS content blocking (Java)

by al_9x » Thu Nov 25, 2010 2:12 am

Giorgio Maone wrote:
al_9x wrote:If you change the code, please bump the version. Why did you remove the logging in the new rc5 (final)?
It slipped in the very early rc5 on my site (lasted 5 minutes or so) and was removed before going in AMO's update channel, because it was on a performance-critical code path and didn't belong in a final RC.
Is a consoleDump test really a performance hit? Being able to optionally see whether or not this interception takes place and also how long it takes, is helpful. I don't see the harm in it, it's effectively a noop when off (default)

Re: samy.pl bypasses NS content blocking (Java)

by Giorgio Maone » Thu Nov 25, 2010 1:49 am

al_9x wrote:If you change the code, please bump the version. Why did you remove the logging in the new rc5 (final)?
It slipped in the very early rc5 on my site (lasted 5 minutes or so) and was removed before going in AMO's update channel, because it was on a performance-critical code path and didn't belong in a final RC.

Re: samy.pl bypasses NS content blocking (Java)

by al_9x » Thu Nov 25, 2010 1:44 am

If you change the code, please bump the version. Why did you remove the logging in the new rc5 (final)?

Re: samy.pl bypasses NS content blocking (Java)

by al_9x » Thu Nov 25, 2010 1:02 am

Giorgio Maone wrote:Please check latest development build (2.0.6rc5).
Confirmed. The only possible problem is lack of notification. On allowed pages you just get the puzzle, and on partial not even that. Maybe that's enough considering the likelihood of liveconnect actually being used, but probably the right thing here is an alert bar offering to allow java and optionally reload the page.

Re: samy.pl bypasses NS content blocking (Java)

by Giorgio Maone » Wed Nov 24, 2010 11:12 pm

Please check latest development build (2.0.6rc5).

Re: samy.pl bypasses NS content blocking (Java)

by Giorgio Maone » Wed Nov 24, 2010 10:48 pm

al_9x wrote:
Giorgio Maone wrote:It works fully on Fx 3.6 (speedup + JVM prevention)

Code: Select all

<script>
watch('java', function() {});
</script>
this starts the vm on 3.6 for me
This doesn't for me, but I run at a very "strange" time (when the documentElement has been created but no script has run yet), so probably the timing plays a role in what is ultimately a bug which has likely been fixed on trunk. However, as I said, I'm ending to temporarily disable the plugin anyway.

Re: samy.pl bypasses NS content blocking (Java)

by al_9x » Wed Nov 24, 2010 10:42 pm

Giorgio Maone wrote:It works fully on Fx 3.6 (speedup + JVM prevention)

Code: Select all

<script>
watch('java', function() {});
</script>
this starts the vm on 3.6 for me

Re: samy.pl bypasses NS content blocking (Java)

by Giorgio Maone » Wed Nov 24, 2010 9:07 pm

al_9x wrote:
Giorgio Maone wrote:However, this is moot because I've just found a wonderful hack which allows me to intercept the java properties without triggering the JVM and without disabling the plugin.
What is it?

Code: Select all

(function() {
      const w = window;
      const k = function() {};
      w.watch('java', k); // wonderful trick reducing w.java resolution by a 100 factor,
      w.watch('Packages', k); // by skipping InitJavaProperties() and undeffing Packages and java
      const g = function() {
        const d = w.document;
        const o = d.createElement("object");
        o.type = "application/x-java-vm";
        o.data = "data:" + o.type + ",";
        d.body.appendChild(o);
        d.body.removeChild(o);
        w.__defineGetter__("java", k);
        w.__defineGetter__("Packages", k);
      }
      w.__defineGetter__("java", g);
      w.__defineGetter__("Packages", g);
    })()
EDIT:
actually it looks like I talked too fast. The code above does reduce the execution time by two orders of magnitude, but unless I disable the plugin the JVM gets instantiated anyway :(
So I'll end combining plugin disablement and the trick above to keep the execution time well under 10 milliseconds while effectively intercepting the Java properties without instantiating the JVM.

EDIT 2
Here's the reason why I was mislead about the extent of the trick above. It works fully on Fx 3.6 (speedup + JVM prevention), but only grants the speedup on Minefield, where the JVM instantiation can only be prevented by disabling the plugin.
However the overhead of the plugin status management is negligible enough not to grant a separate codepath for the 1.9.x branch.

Top