GmsCore leaking Google account password on login

[ghost]

Describe the bug
On login, there are logs with D tag from GmsAuthLoginBrowser shows my Google account mail address and password. It even shows up when adb is run without root, which is not good for security.

Steps to reproduce the behavior:

1. Open MicroG Settings
2. Add a Google account
3. Login with your Google account
4. Check logcat with adb logcat | grep GmsAuthLoginBrowser

Expected behavior
No passwords should be shown in logcat.

System
Android Version: R
Custom ROM: CAOS v313

Additional context
If you have 2FA enabled (SMS code, call, etc) it will show the code too.
09-19 07:55:44.497 6278 6464 D GmsAuthLoginBrowser: JSBridge: getDroidGuardResult: ["nullnull4null9nullnullnullnullnullnullnullnull239405null2"]
The login code was 239405

[ghost]

Can confirm , it does this for me as well.

[binary-glitch00103011]

Can confirm, research is being done to exploit.

[AnierinBliss]

Pretty sus

[Razuuu]

amogus sus

[akc3n]

Thanks @flawedworld for pointing out that this has been around for 7 years.

GmsCore/play-services-core/src/main/java/org/microg/gms/auth/login/LoginActivity.java

Line 445 in 96cfe2b

Log.d(TAG, "JSBridge: getDroidGuardResult: " + s);

[Terminator-J]

... as they said at Chernobyl:
"Whoopski."

[Dark-Matter7232]

NSA connection confirmed.

[DraconicNEO]

Just confirmed this for myself. This is a pretty serious bug, might want to get on this soon.

[binary-glitch00103011]

I have ethics most could appropriate. However in 3 days, I've worked it out, without a CEH or any formal training. It's trivial so no need to release a white paper, or a whack-a-mole proof-of-concept, I've made my point; but who else, that isn't so forthcoming? My research makes no noteworthy revelations and wouldn't aid in the development of better security, thus I'll refrain.

[dimaryaz]

Hey guys, I have a workaround for everyone: don't give adb access to anyone you don't trust! adb lets you do all kinds of bad things.

Also, if you think leaking the password to adb log is bad, I have even worse news for you. MicroG also sends your password over the internet, to a company known for making money off of users' data: Google!

But seriously: yes, it's a bug, but it's not the end of the world.

[binary-glitch00103011]

My method requires native exicution but requires no permission hence it would require creative deployment, many methods of which are well known. Your right dimaryaz, remote console is another angle, which could be mitigated with simple settings discipline. Sorry, the word choice is to obfuscate, I fear I spell out the obvious too much as is. Agreed, this is an important bug, and a seurity concern, but far from the end of the world. PCAP logs show that plain passwords aren't exposed so it seems it's local logs only. This without even peeling at code, but now I'm curious, thought I'll likely be quickly out of my depth.

[Terminator-J]

So... just to confirm, does it only post the account credentials to the log during the activity of actually adding a new google account to the device? That's the only time I saw it doing that.
It doesn't just repeatedly print it even if you're not modifying/adding more Google accounts, correct?
In which case, until microG is updated with the logging removed, the practical security measure for most folks is "format userdata, flash your rom & preferred (minimal!) microG package, factory reset, make sure you're not plugged into the computer, reboot to system for first boot setup, connect to wifi/mobile data and log in to any/all Google accounts you plan to have on the device, reboot so the logcat buffer gets cleared, and THEN you can go about installing things like magisk for root if desired or any 3rd party apps... and then don't add any more Google accounts so it never invokes the microG gmscore account authentication activity again, unless you factory reset and wipe userdata first."
... right?

[ghost]

Hey guys, I have a workaround for everyone: don't give adb access to anyone you don't trust! adb lets you do all kinds of bad things.

Also, if you think leaking the password to adb log is bad, I have even worse news for you. MicroG also sends your password over the internet, to a company known for making money off of users' data: Google!

But seriously: yes, it's a bug, but it's not the end of the world.
@dimaryaz

This is a highly nonsensical and unproductive comment. You're comparing something all protected by TLS to a password being stored and logged in plain text, not hashed or anything. ADB is not required to get logs from logcat either. Selecting the bug report option in Developer Options will dump logs.

Edit: There is also a READ_LOGS permission for apps to read logs. This is not strictly an ADB issue.

[binary-glitch00103011]

Zanthed, you just broke my exploit, I hadn't tested without bug report turned on. It seems without adb, root, bug reports, or extremely old systems (Android 4.1 or older) I can't get logs from another app. So unless someone has something more cleaver than I, it seems being mindful of your settings is sufficient to protect non rooted users. For rooted users; I'm not sure, I don't have a device I'm willing to wipe to test Terminator-J's method, however I'm investigating the viability of it.

[EDIT: I just triggered a permissions dialogue. Selecting 'Allow' fixes my exploit but it's very blantant that wack-a-mole is accessing logs from other apps so...]

[TommyTran732]

Hey guys, I have a workaround for everyone: don't give adb access to anyone you don't trust! adb lets you do all kinds of bad things.

Also, if you think leaking the password to adb log is bad, I have even worse news for you. MicroG also sends your password over the internet, to a company known for making money off of users' data: Google!

But seriously: yes, it's a bug, but it's not the end of the world.

I am not sure what you are saying. You are literally using a Google account, Google has control over your Google account. It's not "bad" or "good". It's just how it is. It doesn't matter if MicroG sends your Google account password to Google or not, so long as its encrypted during transport.

Storing passwords in plain text in any form, waiting to be extracted, is a big issue however.

[ghost]

Hey guys, I have a workaround for everyone: don't give adb access to anyone you don't trust! adb lets you do all kinds of bad things.
Also, if you think leaking the password to adb log is bad, I have even worse news for you. MicroG also sends your password over the internet, to a company known for making money off of users' data: Google!
But seriously: yes, it's a bug, but it's not the end of the world.

I am not sure what you are saying. You are literally using a Google account, Google has control over your Google account. It's not "bad" or "good". It's just how it is. It doesn't matter if MicroG sends your Google account password to Google or not, so long as its encrypted during transport.

Storing passwords in plain text in any form, waiting to be extracted, is a big issue however.

Lol they were joking becuase they said but seriously

[ghost]

Lol they were joking becuase they said but seriously
@SoupSucker

This isn't the place for jokes. Not productive at all.

[fynngodau]

Regarding the READ_LOGS permission, as this has also recently been a topic regarding Exposure Notification's RPIs, Marvin posted this information to the CCTG chatroom:

I think there is a lot of misconception how privileged permissions work on Android.

1. Apps must put the permission request directly in a manifest file. Google does not allow apps in Play Store to request privileged permissions without explanation.
2. Privileged permissions are only granted to apps that are part of the system image and have the permission request in the app version that is on the system image (= updates to system image apps cannot get access to more privileged permissions).
3. Since Android 4.4, apps that want to get a privileged permission must not only be part of the system image (ROM), but also need to reside in a special folder "priv-app". Manufacturers should not put third-party apps in this folder except if there is a very good reason.
4. Since Android 8.0, even if a manufacturer would accidentally put an untrusted third-party app in "priv-app", privileged permissions would not be granted as long as the manufacturer does not explicitly allowlist the specific privileged permission to that app through a configuration file in the system image.

The only risk that I personally can see here is that the password is accidentally sent to a vendor through a custom bug report feature, or using the system Bug Report feature to whomever the report is sent.

[thestinger]

Apps aren't supposed to log sensitive data to the system logs primarily due to them often being shared as part of OS bug reports. Many operating systems have a feature for submitting bug report zips which include the system logs. It's a minor issue especially relative to much more serious problems that are present. Should worry about properly enforcing the Play services API security model and transport security rather than this.

READ_LOGS is signature|privileged|development meaning that it can be granted based on having at least one of those 3 things. It's not solely a privileged permission. The development tag means it can be granted dynamically via persistent state normally set via adb shell. It's also relevant in the verified boot threat model since it's stored as persistent state. Platform signature is also another option. The reason for the privileged system requiring explicit whitelisting now is because those may be third party apps and it's undesirable for them to be able to simply add more privileged permissions in updates based on them being a priv-app without explicit approval by the OS.

[ghost]

Thanks @flawedworld for pointing out that this has been around for 7 years.

GmsCore/play-services-core/src/main/java/org/microg/gms/auth/login/LoginActivity.java

Line 445 in 96cfe2b

Log.d(TAG, "JSBridge: getDroidGuardResult: " + s);

Doesn't fix the root of the problem, but it works (kinda)...