Skip to content
This repository has been archived by the owner. It is now read-only.

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

Open
sungjungk opened this issue Aug 10, 2018 · 6 comments

Comments

Projects
None yet
3 participants
@sungjungk
Copy link
Contributor

commented Aug 10, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Aug 10, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 11, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 16, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented May 7, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented May 15, 2019

@sungjungk

This comment has been minimized.

Copy link
Contributor Author

commented May 16, 2019

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.