VB-111328 OAuth session is shared between browser tabs and mail client - security bug report/response

astero

I want to bring up this bug report to the public as I think it worths a public discussion, as it's a matter of utter importance to all Vivaldi users not only me and the Tarquin, the person who replied to it. It is full of nonsense but I'm not gonna discuss each and every sentence in this reply, I will only highlight the most nonsensical and controversial ones.

We do not consider an attacker who has local access to your computer account to be related to security. They relate to privacy, since you have trusted them enough to allow them access to your computer account. Do not give someone access to your computer if you do not trust them, because they can do literally anything that an application on your computer, running in the context of your computer account, can do. They can potentially change how the browser works, forcing it to expose its OAuth access, no matter how much the application tries to protect itself. (And if they have gained access to your computer via some hacking vector, then they can do the same, but the security vulnerability is in whatever gave them local access in the first place.)

The fact that the OAuth session is shared between mail, calendar and web browsing, was largely a design choice, brought about by a change in how Chromium implemented the identity API. Originally, they were separate, but people frequently complained about having to log in in several different places to a service they had already authenticated to. So when the change was made by Chromium, it was kept that way. Chromium apparently does not make it at all easy to make it work any other way by choice (I wouldn't know - I deal with security, not API convenience). However, some people would like it to be different, and it remains to be seen which way will end up being used in future.

Exactly what malicious actor are you worrying about here, where it would be safe to allow them complete access to your mail or calendar accounts and its access tokens, but somehow dangerous to let them access the web version of the same account? If it is authenticated in the email account, whoever has access to the application using that OAuth account access could hijack that access token and use it for access anyway, even if the browser tried to isolate them. If the website chooses to allow an email access token to access a website, then the browser is powerless to restrict the use of that token.

You could of course log in to email in one profile, and use web browsing in another profile, if you wanted to isolate them for convenience purposes. (Use the profiles button to the right of the address field.)

Perhaps you were hoping for this to be a feature request (that is how your forum thread seems to be anyway), but as it was reported as an exploitable security vulnerability, it will receive this reply from the security group instead of it being handled by the mail team. Our assessment is that this is not a security vulnerability, and does not introduce any security risks.

Hopefully this clears things up for you, and sorry, but it means that we cannot help push the mail team for the change you are hoping for.

In my elaboration I will be using OWASP security principles as the simplest yet comprehensive and compiled by the most authoritative open-source organization.

First of all, this passage:

We do not consider an attacker who has local access to your computer account to be related to security. They relate to privacy, since you have trusted them enough to allow them access to your computer account

Absolutely terrible misconception and violation of the most fundamental principle of zero trust. Nobody should design ever any app with a premise that is trusted or cannot be compromised. The dumbest error ever.

The fact that the OAuth session is shared between mail, calendar and web browsing, was largely a design choice

It appeared to be a design flaw and violation of the best practice. There are well-known rules and best-practices of OAuth in the industry that every security professional should know, only Vivaldi folks do not for some reason. These rules are called RFC-8525: OAuth 2.0 for Native Apps and the name "native app" shouldn't confuse anybody, in the doc by "native app" they refer to the app or application that is installed by the user to their device, as distinct from a web app that runs in the browser context only. So, Vivaldi browser must be treated as the native app in the context of OAuth token sharing between mail, calendar and web browsing, not like the browser. And as such, it immediately violated the main rule of the RFC8525

OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice.

The OAuth authentication should never be done through the embedded browser or web-view window generated by the app itself.
Also, this design choice violates three main security principles from OWASP:
Compartmentalize - the OAuth design on Vivaldi is made by “all or nothing” access model, exactly what is discouraged by that principle. Having access to any of the elements (web, calendar or mail) the intruder automatically has full access to all other elements of user profile.
Least Privilege - self-explanatory. You never should allow users more than needed just because "people frequently complained". It is a dead end.
Separation of Duties - self-explanatory. Each OAuth token should serve only 1 program feature, not all.
Complete Mediation - authorization should be checked upon every request for the object. Vivaldi team did exactly the opposite.

So when the change was made by Chromium

some nonsense again. What change was done by Chromium that you are talking about? Chromium never had a mail client and calendar client, so referencing non-existent feature justifying own design choices is unreasonable. You cannot rely on Chromium in that architectural pattern because Chromium has never done anything like that.

You could of course log in to email in one profile, and use web browsing in another profile, if you wanted to isolate them for convenience purposes

this suggestion utterly violates the Usability and Manageability and Leveraging Existing Components principles that say us the design should be easy and maintainable, also decreasing the attack surface. Having several profiles and switching between them constantly neither easy nor maintainable and obviously make the user easier victim for intruder who want to steal your OAuth token.

Ok, I looked through the Vivaldi code in part of OAuth and found that you implemented it via oauth2client which is in \vivaldi-source\chromium\third_party\catapult\third_party\gsutil\gslib\vendored\oauth2client\oauth2client folder of the source. Tarquin probably would want to stress it out to me saying: "take a look, we did it right and implemented the OAuth token via third-party provider like RFC-8252 recommends".
No, you did it wrong. oauth2client was obsolete and deprecated for ages, it doesn't receive enough patches and security updates and will never be, so the OAuth implementation Vivaldi uses is very vulnerable. All the modern apps already switched to google-auth and OAuthLib.
Moreover, there are thousands wonderful samples including those from Google
https://github.com/googlesamples/oauth-apps-for-windows/blob/master/OAuthDesktopApp/OAuthDesktopApp/MainWindow.xaml.cs which show how to properly implement OAuth authentication in desktop apps

// Opens request in the browser.
            System.Diagnostics.Process.Start(authorizationRequest);

            // Waits for the OAuth authorization response.
            var context = await http.GetContextAsync();

            // Brings this app back to the foreground.
            this.Activate();

            // Sends an HTTP response to the browser.
            var response = context.Response;
            string responseString = string.Format("<html><head><meta http-equiv='refresh' content='10;url=https://google.com'></head><body>Please return to the app.</body></html>");
            var buffer = System.Text.Encoding.UTF8.GetBytes(responseString);
            response.ContentLength64 = buffer.Length;
            var responseOutput = response.OutputStream;
            Task responseTask = responseOutput.WriteAsync(buffer, 0, buffer.Length).ContinueWith((task) => 
            {
                responseOutput.Close();
                http.Stop();
                Console.WriteLine("HTTP server stopped.");
            });

something that I didn't notice in the Vivaldi code.
Also I didn't notice PKCE technique is utilized for the Vivaldi OAuth authentication, was it? This is something mandatory for the public apps (like Vivaldi) utilizing OAuth, one can briefly read about that in the blog https://curity.medium.com/brave-mobile-world-oauth-in-native-apps-e1257be0c2d5

I appreciate any comments if something I post here is wrong, but I cannot silently read the layman-style reply I received from Vivaldi Security team.

P.S. Not to mention that by CISA security bad practices it is not recommended to build apps in memory-unsafe languages like C++, but this is out of the equation here.

rnek

@astero said in VB-111328 OAuth :

The dumbest error ever.

This sentiment is not appropriate to this topic.

nomadic

@astero said in VB-111328 OAuth session is shared between browser tabs and mail client - security bug report/response:

Ok, I looked through the Vivaldi code in part of OAuth and found that you implemented it via oauth2client which is in \vivaldi-source\chromium\third_party\catapult\third_party\gsutil\gslib\vendored\oauth2client\oauth2client folder of the source.

This folder is directly from the Chromium source, so not from Vivaldi and not related to the OATH used for mail accounts.

Chromium source:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/catapult/third_party/gsutil/gslib/vendored/oauth2client/oauth2client/

Catapult's purpse:
https://chromium.googlesource.com/catapult/

yngve

@astero I am afraid you are suffering from a few misapprehensions

third_party/catapult

This is a test related submodule library only included in the source tree because some unit tests depends on it, and the gsutil subsystem is a third_party library only used by catapult; it is also found in the third_party/depot_tools submodule, in both cases because those tools can download files from Chromium buckets that require a login, which is provided with an oauth token.

What is actually doing the oauth implementation?

Vivaldi uses the chrome.identity Extension API, defined at
https://developer.chrome.com/docs/extensions/reference/api/identity which is used by extensions and websites to access federated credentials (aka Oauth tokens)

That is implemented in chrome/browser/extensions/api/identity of the chromium source code.

This is the OAuth token retrieval system used by Vivaldi, and it originally separated cookies used for the oauth login from the ones used for browsing. As mentioned to you by Tarquin, that changed a few years ago, due to changes the Chromium made (upstream issue, code change 1, 2) , and since the situation regarding cookie jar separation is complicated (see the discussion on multi-account containers elsewhere in the forums), we have so far not tried to override that upstream change.

We do agree that there are certain privacy concerns about this lack of
separation, but that can be completely mitigated (aside from IP address associations) by using separate profiles, preferably standalone installs; which is actually what one should do anyway if one wants to avoid connecting two identities hosted by the same provider.

If you think the chrome.identity API related cookies should be separated from the browser-wide cookie jar, feel free to report that to the Chromium team at https://issues.chromium.org/new .

For reference, there is already a feature request related to this topic: https://issues.chromium.org/issues/40746265

tarquin

You are still confusing security and privacy. This page should help to clear things up for you:
https://vivaldi.com/security/how-we-rate-security-issues/

You may also wish to note that OWASP is not generally relevant to installed software. It is a useful project, but their primary focus is on website security, where the vectors are very different. They also are not infallible, since the content is created by their users, who may be mistaken about the impact of some things, and there are many cases where they say things which actually do not improve security in any way, but make it harder to legitimately test a site. Therefore, the content of that website should be taken as a guideline which should be carefully considered because it might have a security impact, but not treated as a hard rule since it often does not have a security impact.

As mentioned by Yngve, it is the Chromium browser engine that handles the identity code, and it is Chromium that made the change. And in case you needed clarification; Vivaldi is a Chromium app, meaning that it runs as if it were an extension, which is why it uses extension APIs.

Again, you are welcome to your opinion about whether the behaviour of the mail/calendar client is inconvenient, but it does not have any security impact. We don't mind you asking the mail team to change it. In fact, at Vivaldi, we actually encourage you to provide such feedback, because your feedback is what is used to determine if changes should be made. However, we will not push teams to make changes by claiming that they are important for security, unless they are actually important for security.

Note also that it is generally more productive to reply to a person individually when they reply to your bug report, if you have some point that needs to be discussed further, rather than trying to rally on a public forum. My email had asked you if you had some attack vector that we had overlooked. That was an invitation to reply, if you had identified some actual security threat.

/"The Tarquin"

stilgarwolf

Eran Hammer, former lead author for the OAuth 2.0 project:
OAuth 2.0 and the Road to Hell

astero

@yngve said in VB-111328 OAuth session is shared between browser tabs and mail client - security bug report/response:

but that can be completely mitigated (aside from IP address associations) by using separate profiles

absolutely non-viable and not usable recommendation, considering the well-known fact that Vivaldi is notoriously known for crashing with multiple profiles

https://forum.vivaldi.net/topic/102980/vivaldi-crashing-when-third-profile-is-open