Skip to content
This repository has been archived by the owner on Nov 11, 2022. It is now read-only.

Error on 'exp' type handling in ID Token #57

Closed
sungjungk opened this issue Aug 10, 2018 · 7 comments
Closed

Error on 'exp' type handling in ID Token #57

sungjungk opened this issue Aug 10, 2018 · 7 comments

Comments

@sungjungk
Copy link
Contributor

Problem:
The following errors occurred during the attempt to request ID Token with specifying ‘profile’ or ‘email’ in SCOPES parameter.

terminate called after throwing an instance of 'std::runtime_error'
  what():  Type is not convertible to string

Cause:
When receiving ID Token from Google OAuth Server, ‘exp’ in the token is representing the type of integer. Unfortunately, 'google-api-cpp-client' deals with it as a string type; it causes the above problem. For your information, I attached the format of ID Token received from the server.

{
  "azp": "...”,
  "aud": "...",
  "sub": "...",
  "email": "...@gmail.com",
  "email_verified": true,
  "at_hash": "...",
  "exp": 1533783763,
  "iss": "accounts.google.com",
  "iat": 1533780163
}
@SurferJeffAtGoogle
Copy link
Contributor

Hi Seong-Joong. Thank you for reporting this issue. The code fix looks good too.

I would like to try to reproduce the issue. Is there a simple way to reproduce it?

@sungjungk
Copy link
Contributor Author

Thank you for your prompt reply.

In my PoC, ‘set_default_scopes’ function is called with ‘profile/email’ parameters as follows;

std::unique_ptr<OAuth2ServiceAccountFlow> flow_;
flow_->set_default_scopes(“profile email”);

After I received a token, it contains ID token in forms of JWT.

Currently, it occurred about type handling issue of ‘exp’ in JWT.

@sungjungk
Copy link
Contributor Author

Hi all,

In addition to the above reproducible case, it happens when either 'profile' or 'email' is specified on 'set_default_scopes' function.

After the execution, authentication server returns 'ID token' in forms of JWT (JSON Web Token), that contains an 'exp' element as integers, not a string (see RFC7519).

Before applying this patch, it cannot parse the 'exp' element in JWT properly.

Please check again.

Many thanks!!

@sungjungk
Copy link
Contributor Author

@SurferJeffAtGoogle
What do you think of it as security issue?
I think that it can be used for denial of service attack.

Description
An exploitable unhandled exception vulnerability exists during Google Sign-In with ‘google-api-cpp-client’.
On an OAuth2.0 client, ID token handling can cause an unhandled exception resulting in denial of service.
Once a 3rd party service uses Google Sign-in with ‘google-api-cpp-client’, a malicious user can trigger this vulnerability by requesting the client to receive the user’s ID token from an Google's authentication server.

Attack vector
If a 3rd party service uses Google Sign-In with an app or site via ‘google-api-cpp-client’, malicious user can make Google’s authentication server send the user’s ID token to the client on 3rd party.
During type handling in ID token, it can cause an unhandled exception resulting in denial of service on 3rd party service.
After then other users can no longer login/sign-in to the 3rd party service.

Vulnerability type
CWE-754: Improper Check for Unusual or Exceptional Conditions

Sincerely,

@aiuto
Copy link
Contributor

aiuto commented May 15, 2019 via email

@sungjungk
Copy link
Contributor Author

Thank you for your reply.

I am not talking about flaws of token exposure.
Instead, I just mentioned that above wrong type handling causes an unhandled exception, resulting in denial of service on 3rd party application with Google Sign-In service.

Similarly, there exist several vulnerabilities related to wrong type handling in client libraries.
They mishandled or unhandled certain exceptions, leading to a denial of service in applications that use these libraries.
: CVE-2017-12119, CVE-2018-12680, CVE-2019-9628, etc.

@tmatsuo
Copy link
Contributor

tmatsuo commented Jun 26, 2019

Thanks for filing the issue, but we deprecated this repository, so closing.

@tmatsuo tmatsuo closed this as completed Jun 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants