181–190 of 222 posts
Earlier quoted context omitted.
What's the rationale for disclosing vulnerabilities to for example Google before going public (unless the bug is in Google's software)?
Because big players can take remedial action prior to the bug being disclosed to protect users - for example, banning a specific framework from browser extensions.
Why not use Google Caja instead of a separate sandbox?
> My information is that Google stopped supporting angular 1.x months ago. It is now a community driven project. I totally missed this - was there a notice of this posted somewhere?
Earlier quoted context omitted.
I think his point is that running the entire Angular 1.x framework to power a browser extension gives a large attack surface.
Yes. And to answer nchelluri's question: Auto-typing, though I believe that's available only on desktop operating systems.
And on Android (where you set up the password manager as a custom keyboard), and possibly an iPhone
So, there's so many problems with this i don't know where to begin. Since folks have already noted the "not notifying google" issue, let me point out another: Prior to banning, i can find literally no discussion or details about this being about to happen (IE no notice), pretty much ever. You can see it was initially noted here: https://github.com/mozilla/addons-linter/commit/86f4dfb44355... I can find no discussion…
Google has repeatedly been equally abrupt in making breaking changes to other people's apps/products/pages/sites to resolve security problems. I'm glad they do, and I'm glad Mozilla isn't fucking around with stuff like this either.
1. Just because one guy is an idiot does not mean the other should be.
2. You know, you may want to tell people and establish a process for telling people that this is happening (ie it should not take until person files github issue asking what's up when they validate their app to know what's going to be okay and not)
(and if the answer is "google doesn't do that", see #1 :P)
Many commenters here seem to be completely misunderstanding the situation. Browser extensions are really dangerous; if you need to keep your machine secure, you shouldn't use any IMHO. By definition, browser extensions need to be able to access things such as page content. What would stop someone from writing a extension that captures your bank credentials? Nothing. Obviously no security-conscious user is going to in…
You make it sound automatic, but surely this must be manually triggered by the extension in question?
Earlier quoted context omitted.
> It's probably possible to sanitize all external inputs used in the browser extension such that privilege escalation isn't possible, but the Angular team has tried hard with their sandbox solution with no success. Extension developers will hardly do much better, so it makes sense for Mozilla to ban the whole library. Sandboxing in JS should be possible these days. Spin up an iframe, add the sandboxing attribute, loa…
You can't run code that depends on variables in the page context though. If all the input values are serializable, then you can postMessage them into the iframe too, but you can't serialize objects with arbitrary methods, etc. The code you run in the sandbox can't return back a rich object with arbitrary methods because that has to get serialized back out. You can't use getters and setters to transparently proxy all…
Earlier quoted context omitted.
You can't run code that depends on variables in the page context though. If all the input values are serializable, then you can postMessage them into the iframe too, but you can't serialize objects with arbitrary methods, etc. The code you run in the sandbox can't return back a rich object with arbitrary methods because that has to get serialized back out. You can't use getters and setters to transparently proxy all…
I believe you could solve the garbage collection problem with WeakMap.
WeakMaps are more limited than most people seem to expect. They're powerful tools that enable many new powerful patterns, but they don't expose the workings of the garbage collector. They're very different from Java's WeakHashMap for example. In Javascript, the only way you can tell whether the browser is using a garbage collector or not is to try to run out of memory. Without crashing, there's no way for some Javascript code to observe the runtime's GC behavior at all by design.
Many commenters here seem to be completely misunderstanding the situation. Browser extensions are really dangerous; if you need to keep your machine secure, you shouldn't use any IMHO. By definition, browser extensions need to be able to access things such as page content. What would stop someone from writing a extension that captures your bank credentials? Nothing. Obviously no security-conscious user is going to in…
Why is Angular from the extension run on DOM from the page? You make it sound automatic, but surely this must be manually triggered by the extension in question?
Earlier quoted context omitted.
No, the vulnerability specifically has to do with Angular within extensions. Angular trusts the page DOM and uses eval-like functions on code within it. This is relatively fine if the DOM isn't controlled by someone else, but in cases where the DOM is controlled by someone with less permissions (ie. Angular is running in a higher-privilege extension, and the DOM is controlled by some webpage), then then an attacker c…
Don't extensions have their own DOM (like they have in Chrome)? Why would anyone run Angular on a browser page? It would probably conflict with existing application. It looks like Firefox extension architecture has design problems. And I don't like the presentation. One could think that Angular is vulnerable which is not true. The vulnerability appears when it is used in a wrong way in a browser extension.