SafetyNetClientService uses a caller-controlled package name as the identity for the request, with no caller check of its own. That unverified packageName is written to SafetyNetDatabase before anything is sent over the network, and again when the (failing) request completes. verifyWithRecaptcha has the same pattern: it calls db.insertRecentRequestStart(..., packageName, ...) with the same unchecked package name, then reads the app's on-device APK file digest and signing-certificate digest to build the reCAPTCHA request parameters (as/ac/pk).
SafetyNetDatabase entries are read directly by microG's own Settings UI (under "Device attestation") to show,
per app, when it last called SafetyNet and with what result - driven entirely by the unchecked packageName column.
Impact
A zero-permission app can make microG's own Settings UI ("Device attestation") show that any other
installed app made a SafetyNet attest or verifyWithRecaptcha call, even though that
app never did. Since the SafetyNet Attestation backend is shut down, the call itself will fail (visible
in the UI as an error result), so this does not constitute an actual authentication bypass of the
SafetyNet service and does not let an attacker obtain a usable forged attestation.
Patches
Patch will be published as part of 0.3.16.1 and 0.3.17 releases.
Workarounds
Do not trust the request history in the "Device attestation" screen in microG's settings user interface. Or, alternative, disable "Allow device attestation" in microG settings.
Fs00 Reporter
SafetyNetClientServiceuses a caller-controlled package name as the identity for the request, with no caller check of its own. That unverifiedpackageNameis written toSafetyNetDatabasebefore anything is sent over the network, and again when the (failing) request completes.verifyWithRecaptchahas the same pattern: it callsdb.insertRecentRequestStart(..., packageName, ...)with the same unchecked package name, then reads the app's on-device APK file digest and signing-certificate digest to build the reCAPTCHA request parameters (as/ac/pk).SafetyNetDatabaseentries are read directly by microG's own Settings UI (under "Device attestation") to show,per app, when it last called SafetyNet and with what result - driven entirely by the unchecked
packageNamecolumn.Impact
A zero-permission app can make microG's own Settings UI ("Device attestation") show that any other
installed app made a SafetyNet
attestorverifyWithRecaptchacall, even though thatapp never did. Since the SafetyNet Attestation backend is shut down, the call itself will fail (visible
in the UI as an error result), so this does not constitute an actual authentication bypass of the
SafetyNet service and does not let an attacker obtain a usable forged attestation.
Patches
Patch will be published as part of 0.3.16.1 and 0.3.17 releases.
Workarounds
Do not trust the request history in the "Device attestation" screen in microG's settings user interface. Or, alternative, disable "Allow device attestation" in microG settings.