Page 1 of 1
CrossFire: An Analysis of Firefox Extension-Reuse Vulnerabil
Posted: Mon Apr 04, 2016 2:12 pm
by therube
"CrossFire: An Analysis of Firefox Extension-Reuse Vulnerabilities"
PDF:
https://www.internetsociety.org/sites/d ... lities.pdf
http://webcache.googleusercontent.com/s ... n&&ct=clnk
VII. CONCLUSIONS
In this paper, we introduced a novel class of attacks
stemming from extension-reuse vulnerabilities, which arises
from the lack of isolation between Firefox extensions, and
results in capability leaks through global identifiers defined
in the shared JavaScript namespace of the browser.
Re: CrossFire: An Analysis of Firefox Extension-Reuse Vulner
Posted: Mon Apr 04, 2016 3:30 pm
by barbaz
What makes this so special? What qualifies this as an attack?
The whole idea of the current extensions system is that extensions have the same privileges as the browser itself.
(And I've used this type of hackery in the past for my own extensions,
posting publicly what I'm doing, and no one called me a haxxor for it...)
ETA
Plus, a malicious extension could itself include code to do exactly whatever the reused code does, and it'd be the same result either way... so what makes the "vulnerability" here?
NoScript and Malware problem identified???
Posted: Mon Apr 04, 2016 4:49 pm
by GWG
"Top Firefox extensions can hide silent malware using easy pre-fab tool" NoScript was specifically mentioned as vulnerable in todays' article. "The extensions vulnerable to the 255 reuse exploits found included NoScript with 2.5 million users, Video DownloadHelper with 6.5 million users, and GreaseMonkey with 1.5 million users. Adblock Plus with its 22 million users was unaffected."
http://www.theregister.co.uk/2016/04/04 ... efab_tool/
Could we have a comment from No Script dev please.
Re: CrossFire: An Analysis of Firefox Extension-Reuse Vulner
Posted: Mon Apr 04, 2016 5:52 pm
by therube
> What makes this so special? What qualifies this as an attack?
Well, I suppose nothing actually.
Only that a "clean" extension could potentially piggy-back, for nefarious reasons, onto a different (truly clean) extension.
But really what it points out is the failing in using global variables (as a particular point) rather then variables local to a particular procedure.
There was a GREAT article in that respect, I think from Oracle Magazine, May/June 2015, Tom Kyte... yeah, that was it... (now let me see if I can find it online)...
That was easy,
On More-Secure Applications.
(What takes 5 pages in paper form, is only "one" page, electronically. And yes what he says deals with a specific product, but the concepts apply [should apply] everywhere.)
Re: CrossFire: An Analysis of Firefox Extension-Reuse Vulner
Posted: Mon Apr 04, 2016 6:07 pm
by barbaz
therube wrote:> What makes this so special? What qualifies this as an attack?
Well, I suppose nothing actually.
Only that a "clean" extension could potentially piggy-back, for nefarious reasons, onto a different (truly clean) extension.
But really what it points out is the failing in using global variables (as a particular point) rather then variables local to a particular procedure.
Well then in that case the "fix" that Mozilla will implement is WebExtensions.
Re: NoScript and Malware problem identified???
Posted: Tue Apr 05, 2016 5:01 pm
by Giorgio Maone
GWG wrote:
Could we have a comment from No Script dev please.
I
tweeted here about this.
I'll just add that, if anything, this points out that the editorial process should be more careful: if you don't immediately understand what a certain piece of code does, and surely it's the case for
Code: Select all
noscriptBM.placesUtils.__ns.__global__.ns.
loadErrorPage(window[1], $url);
-- just assume it's malicious.
Another
related tweet, to complete the picture.
Re: CrossFire: An Analysis of Firefox Extension-Reuse Vulner
Posted: Tue Apr 05, 2016 11:53 pm
by tinstaafl
Will it be necessary to re-write the NoScript extension for the upcoming Mozilla WebExtensions API?
Re: CrossFire: An Analysis of Firefox Extension-Reuse Vulner
Posted: Wed Apr 06, 2016 12:26 am
by Thrawn
Re: CrossFire: An Analysis of Firefox Extension-Reuse Vulner
Posted: Wed Apr 06, 2016 6:36 pm
by tinstaafl
Thanks for the links. I learned something today! The news articles made it sound like this issue was suddenly newly discovered. And it may take a few users by surprise, even though many devs have been aware for a while.
I am encouraged to see that Giorgio is taking a lead role on this issue, and that the future of NoScript looks bright
Re: CrossFire: An Analysis of Firefox Extension-Reuse Vulner
Posted: Thu Apr 07, 2016 1:20 am
by Thrawn
barbaz wrote:What makes this so special? What qualifies this as an attack?
...a malicious extension could itself include code to do exactly whatever the reused code does, and it'd be the same result either way... so what makes the "vulnerability" here?
The special part is that by piggybacking on another extension, the malicious code may be able to avoid doing anything obviously dangerous, and thus avoid detection in Mozilla reviews.
So it's not really a weakness in NoScript, or other extensions; it's a weakness in AMO.
Re: CrossFire: An Analysis of Firefox Extension-Reuse Vulner
Posted: Mon Apr 11, 2016 3:02 pm
by barbaz
Re: CrossFire: An Analysis of Firefox Extension-Reuse Vulner
Posted: Wed Aug 03, 2016 1:39 am
by cartel
What does this mean for noscript users?
Am I open for attack using noscript.
I'm confused
Re: CrossFire: An Analysis of Firefox Extension-Reuse Vulner
Posted: Wed Aug 03, 2016 2:24 am
by barbaz
cartel wrote:What does this mean for noscript users?
Nothing.
cartel wrote:Am I open for attack using noscript.
No.
cartel wrote:I'm confused
If you set fire to the gasoline in your car, that makes your car vulnerable to being engulfed in flames.
Re: CrossFire: An Analysis of Firefox Extension-Reuse Vulner
Posted: Mon Nov 28, 2016 12:34 am
by Thrawn
barbaz wrote:
If you set fire to the gasoline in your car
Or for a closer analogy - if you leave someone untrustworthy in possession of your car, then s/he can set fire to the gasoline and thus destroy your car
without the need to bring his/her own explosives. Of course, even with some kind of non-explosive fuel, you'd still have big problems in this situation.