Posts made by doliere

@tnowak This issue has been addressed ! I note your comment for future reports

@burnout426 Ok thanks !

Any comment about this issue ?

@leocg Do you think that Opera should do something, during extensions review process, in order to remove extensions that can be exploited via message passing ?

@leocg Ok thanks. I found that most of the extensions I reported have been removed. But I reported some other 4 that are still on the Opera addons page. Thanks for your highly useful help

@leocg Yes it has been removed. But I have some more to report, can I do it here ?

@leocg Ok I see
What to do now ?

@leocg No I did not !
I do not remember the exact title of the report, but it is related to extensions that can be exploited by web pages via message passing to get access to privileged extensions API.
So maybe
"Exploiting extensions capabilities via message passing"

OR

"Extensions that let scripts in webpages post messages to the extensions in order to bypass SOP, execute arbitrary code in the context of the extension, trigger downloads, read and write extensions storage"

OR

"Via message passing, extensions let web applications get access to sensitive privileged capabilities"

@leocg No I did not.
I checked my mails

@leocg Via the bug report wizard - https://bugs.opera.com/wizard/
I would have saved the bug number, but unfortunately, I did not

@sgunhouse Ok that's a pity, because I do not have a bug number.
May I post it again ?

Could anyone comment on this issue please ?

I reported some extensions posing some security problems, but I could no more track my bug, so I am re-reporting here agains.

Description
Via message passing, extensions can let scripts running in webpages get access to sensitive APIs, such as executing code in the context of the extension, making XMLHttpRequest from the context of the extension and getting the response back, storing data in the context of the extension and retrieving it back later on or triggering the download of arbitrary files on the user computer

Steps to reproduce: Let consider the https://addons.opera.com/en/extensions/details/smaily-dlia-odnoklasnikov/ extension

1. Install it

2. Navigate to https://ok.ru for instance and open the browser console.

3. Send the appropriate message (JavaScript code) to the extension background page

   chrome.runtime.sendMessage("pmpnemphhmmpkcafgpdjanghiaadfbef", {
   			action: "getRemote",
   			url: "https://mail.google.com",
   			blob: null, // Or with data
   		}, function(response){
       console.log("DATA", response);
   });
   

4. If you are logged into your gmail account, the extension reads your emails and displays them in the console. You can replace https://mail.google.com by any URL, the extension will fetch its content and return it back

I have more extensions (around 10) of them, but I cannot upload files.

What should have happened
We think that extensions review process should take into consideration the possibility that extensions let web applications access their privileges APIs. This is a violation of privilege separation between extensions and web applications, and have tremendous consequences: SOP bypass, the execution of arbitrary codes in the context of the extension, access to user cookies, browsing history, access to extensions storage, triggering of downloads, etc.

We would like to bring into discussion an extension capability we thing represent a serious threat: that is the ability for an extension to manipulate CORS headers and make successful unauthorized cross-origin requests.

Simply put, an application A makes an XHR request to B, which does not respond with any CORS headers. This means that normally, any data returned by B will not be delivered to A. Unfortunately, this is not always true. An extension in the browser can add the necessary CORS headers to the response, causing the data to be delivered to A.

There are around 10% of extensions that have the necessary permissions (webRequest, webRequestBlocking, host permissions) to tamper with cross-origin requests/responses headers in order to authorized such unauthorized cross-origin accesses.
The CORS Toggle extension ( https://addons.opera.com/en/extensions/details/cors-toggle/ ) is the only extension we found effectively tampering with CORS headers to allow cross-origin requests.
This extension can potentially break legitimate CORS headers because of an misunderstanding of the CORS mechanism. It always changes or adds the value of the Access-Control-Allow-Origin response header to *. This has the consequence of breaking legitimate CORS headers with credentials.
Installing this extension prevents you from playing youtube videos

But we wanted to know how vendors consider the ability for extensions to manipulate CORS headers. To do so, we wrote the CORSER extension and submitted it for publication.
We were surpised that CORSER successfully passed extension review process and is now a publicly available for download ( https://addons.opera.com/en/extensions/details/corser-authorize-cors-requests/ ). This was done only for research purposes, and the extension is not collecting any user information for us. However, if an attacker (say our A application) is aware of such extension being installed in the user's browser, then it can make successfull cross-origin requests to fetch any data from B, whatever B is: Gmail, Facebook, Twitter, bank application, etc.
Doing so, we confirmed that tampering with CORS headers is considered benign from the point of view of browser vendors, despite the fact that such practice has the consequence of disabling the Same Origin Policy in browsers regarding cross-origin requests.

We would like to know your thoughts about this particular extensions capability.
As for us, we think that the ability for extensions to tamper with CORS and other security-critical headers (CSP, X-Frame-Options) must not be granted directly with permissions like webRequest and webRequestBlocking. We argue that tampering with such headers must be forbidden by default (as is the case for some requests headers such as cache headers) or extensions would have to request dedicated permissions in order to tamper with those headers. For instance, an extension that is willing to tamper with the Access-Control-Allow-Origin header would have to declare it in its permissions. This way, browser vendors can notify users about the fact that an extension that is being installed is requesting the capability to tamper with the declared CORS headers.