Wear OS PKCE approach problem [313669167]

Fixed

Bug

[AOSP] assigned

Status Update

No update yet.

Description

ko...@porsche.de

created issue #1

Nov 29, 2023 12:11PM

I have installed your testing app and tried the PKCE approach with my setup Real Android device (Pixel5 Android 14) + paired Wear OS API 30 emulator. The flow seems to be correct till the last step with allow the button to come back to the watches. I'm stuck in allow screen and facing an exception on a phone.


 java.lang.SecurityException: Permission Denial: starting Intent { act=android.intent.action.VIEW cat=[android.intent.category.BROWSABLE] dat=com.google.android.wear:/... flg=0x10000000 cmp=com.google.android.wearable.app/com.google.android.clockwork.companion.authentication.AuthenticationRedirectActivity (has extras) } from ProcessRecord{92dda92 4023:org.mozilla.firefox/u0a39} (pid=4023, uid=10039) not exported from uid 10561
 	at android.os.Parcel.createExceptionOrNull(Parcel.java:3057)
 	at android.os.Parcel.createException(Parcel.java:3041)
 	at android.os.Parcel.readException(Parcel.java:3024)
 	at android.os.Parcel.readException(Parcel.java:2966)
 	at android.app.IActivityTaskManager$Stub$Proxy.startActivity(IActivityTaskManager.java:2110)
 	at android.app.Instrumentation.execStartActivity(Instrumentation.java:1873)
 	at android.app.Activity.startActivityForResult(Activity.java:5589)
 	at androidx.activity.ComponentActivity.startActivityForResult(ComponentActivity.java:2)
 	at android.app.Activity.startActivityForResult(Activity.java:5547)
 	at androidx.activity.ComponentActivity.startActivityForResult(ComponentActivity.java:1)
 	at android.app.Activity.startActivity(Activity.java:6045)
 	at android.app.Activity.startActivity(Activity.java:6012)
 	at mozilla.components.feature.app.links.AppLinksUseCases$OpenAppLinkRedirect.invoke$default(AppLinksUseCases.kt:64)
 	at mozilla.components.feature.app.links.AppLinksFeature$handleAppIntent$doOpenApp$1.invoke(AppLinksFeature.kt:14)
 	at mozilla.components.feature.app.links.AppLinksFeature$start$1$3.emit(AppLinksFeature.kt:257)
 	at kotlinx.coroutines.flow.DistinctFlowImpl$collect$2.emit(Distinct.kt:91)
 	at mozilla.components.feature.app.links.AppLinksFeature$start$1$invokeSuspend$$inlined$mapNotNull$1$2.emit(Emitters.kt:67)
 	at kotlinx.coroutines.flow.FlowKt__ChannelsKt.emitAllImpl$FlowKt__ChannelsKt(Channels.kt:128)
 	at kotlinx.coroutines.flow.FlowKt__ChannelsKt$emitAllImpl$1.invokeSuspend(Channels.kt:12)
 	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:9)
 	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:112)
 	at android.os.Handler.handleCallback(Handler.java:958)
 	at android.os.Handler.dispatchMessage(Handler.java:99)
 	at android.os.Looper.loopOnce(Looper.java:205)
 	at android.os.Looper.loop(Looper.java:294)
 	at android.app.ActivityThread.main(ActivityThread.java:8177)
 	at java.lang.reflect.Method.invoke(Native Method)
 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:552)
 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:971)
 Caused by: android.os.RemoteException: Remote stack trace:
 	at com.android.server.wm.ActivityTaskSupervisor.checkStartAnyActivityPermission(ActivityTaskSupervisor.java:1136)
 	at com.android.server.wm.ActivityStarter.executeRequest(ActivityStarter.java:1069)
 	at com.android.server.wm.ActivityStarter.execute(ActivityStarter.java:742)
 	at com.android.server.wm.ActivityTaskManagerService.startActivityAsUser(ActivityTaskManagerService.java:1288)
 	at com.android.server.wm.ActivityTaskManagerService.startActivityAsUser(ActivityTaskManagerService.java:1239)

Do you have any idea why it can happen? I believe its a problem with emulator, but want to hear an expects opinion

deleted

Restricted

0 B

Comments

vi...@google.com <vi...@google.com> Nov 30, 2023 01:51AM

Assigned to vi...@google.com.

vi...@google.com <vi...@google.com> #2Nov 30, 2023 03:36AM

We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

vi...@google.com <vi...@google.com> #3Jan 9, 2024 09:58PM

Marked as fixed.

Thanks again for the feedback! Our product and engineering teams have evaluated the request and responded:

Hello,

An MTE-specific strlen (and all string.h family of functions) is necessary and desirable to detect buffer-overflow bugs.

The example you mention, vector.push_back(toCppString(**).c_str()), is a great example of the type of footgun that exists in C++. Our other tools even specifically mention this as an example of a use-after-free bug that we want to catch.

Some of those specific examples of use-after-free bugs are begnign, however they're still undefined behaviour. MTE catching them is the desired functionality.

Issue 313669167

Description

Issue summary

Comments

vi...@google.com <vi...@google.com> Nov 30, 2023 01:51AM

vi...@google.com <vi...@google.com> #2Nov 30, 2023 03:36AM

vi...@google.com <vi...@google.com> #3Jan 9, 2024 09:58PM

Add comment

Issue metadata