InformAction Forums

The <META> redirection block only happens at certain points & I kind of jumped in the middle instead of starting at the beginning & so I'm not clear if it helped in all circumstances.

EDIT:
But what I did get is a warning when after making this post, you wanted to redirect me back to the original thread!

And that too was probably bogus. You saw what appeared to be, but did you check the URL line?

Giorgio Maone wrote:On a side note, as I just said in a commend I dropped on Brian's blog, in next version I'll probably implement a feature to block meta refreshes which are about to happen in hidden tabs.
This will prevent Aviv's variant from working, while keeping meta refresh functionality where needed.

I'd love to see a block meta refresh function in NoScript. Firefox's option to warn you when a meta refresh works okay, but I'd like the ability to whitelist pages I want to allow meta refresh on (such as news sites like CNN) and by default not allow non-whitelisted sites not to meta refresh.

I'd like the ability to whitelist pages

Now that SeaMonkey is able to work with accessibility.blockautorefresh, & once I enabled it, that was my immediate thought.

Please check 1.9.9.81

Giorgio Maone wrote:Please check 1.9.9.81

Thanks, Giorgio, for your great work!

Too confusing for me. I'm not sure what I'm suppose to see or not see?
Setting noscript.forbidBGRefresh to 3, don't know that I'm seeing anything different?
But then ... I'm not sure what I'm suppose to see or not see?

Suppose this is nothing?

therube wrote: But then ... I'm not sure what I'm suppose to see or not see?

Currently nothing on SeaMonkey. I'm checking if I can stuff something for SM in 81 itself before it goes AMO.

@therube:
please retry installing in SeaMonkey now. You won't get the allowable notification you get in Firefox, but the attack should fail and the blockage should be logged in the Error Console.

Thank you Giorgio for the quick update

On the proof of concept page, I still get the gmail image after moving away from tab, and a reload. Interestingly, another reload brings the original page back!

Being that the initial warning/block in the latest version of NoScript appears to work, it's definitely cool, and helpful.

Just wanted to pop in and share my experience w/the latest update regarding this latest threat.

Thanks for making an awesome program, all the updates, and all your efforts!

technerd wrote:Thank you Giorgio for the quick update

On the proof of concept page, I still get the gmail image after moving away from tab, and a reload.

You mean a manual reload (under your control), right?
That's normal because of the way the scriptless page works: it uses CSS to detect whether you're looking at the page or not, and when you're not looking anymore it "takes note" that next refresh must be GMail-like.
NoScript blocks the automatic refresh, but if you do it manually you get the expected GMail page.

technerd wrote: Interestingly, another reload brings the original page back!

Yes, because once the GMail trap has been shown, the "note" gets reset, allowing you to try the PoC ad infinitum.

Let me see if I'm getting this a bit better ...

krebs page: http://krebsonsecurity.com/2010/05/devi ... gets-tabs/
krebs link to aviv's page: http://avivraff.com/research/phish/arti ... ?854817837

blocking JavaScript, or not, is immaterial because JavaScript is not being used

clicking on the link to aviv's page loads the exploit page

at that point, if Forbid META redirections inside <NOSCRIPT> elements is enabled, exploit thwarted

manually reloading the page will expose "Google" (& then rotate to & fro, every so often) [expected]

disable META redirections blocking, but enable noscript.forbidBGRefresh & again, exploit thwarted
still, manually reloading the page will expose "Google" (& then rotate to & fro, every so often) [expected]

@therube:
you got it perfectly right.

More, if you're on Firefox with the forbidBGRefresh option set to 1, you also get a notification identical to Firefox's own accessibility refresh blocking one, with a button to work-around it.

I can verify that the current and all previous attempts at doing this are successfully blocked by NoScript and short of someone manually refreshing a tab only to continue using what they were doing, seems unlikely and if so, then so be it for their lack of attention.

I'm lost and don't understand what I am supposed to set/enable to block this problem in 1.9.9.81.

Can anyone lay out required changes in a straightforward manner? Thanks.

I don't see any difference between 1.9.9.80 and 1.9.9.81

If I open http://www.azarask.in/blog/post/a-new-t ... ng-attack/ in a tab and don't allow scripts to run, when I switch to another tab nothing happens (using both .80 & .81).
If I allow scripts to run on the site and switch to another tab then the tab changes to gmail as described (using both .80 & .81).
Is this the expected behavior?