Fixed
Status Update
Comments
ma...@google.com <ma...@google.com>
ma...@google.com <ma...@google.com> #2
This looks like a regression from AGP 3.4 to AGP 3.5. Ian, can you have a first look?
vu...@darknavy.com <vu...@darknavy.com> #3
Thank you very much for the reproduction project! It does indeed reproduce the issue locally. The issue appears to be the compiler failing to rewrite the invocation to a public static interface method to target the companion class created while desugaring interface methods. I'll follow up in this issue thread once more information is available and a fix is found.
le...@google.com <le...@google.com>
vu...@darknavy.com <vu...@darknavy.com> #4
Reassigning to Ivan as this is looking like a build issue and I'm not sure if the project configuration needs changing or there is an error in the build system.
Running:
./gradlew :quickstartKotlin:assembleDebug --info
yields output with:
<snip>/.gradle/caches/transforms-2/files-2.1/a4e476e9d975337caa4d7a965148dce1/video-android-4.2.0/jars/classes.jar: D8: Type `org.webrtc.EglBase` was not found, it is required for default or static interface methods desugaring of `void com.twilio.video.EglBaseProvider.<init>()`
More info:
The application has a dependency on com.twilio:video-android:4.2.0 and it appears to include a copy of webrtc somehow. Found it locally in .gradle/caches/transforms-2/files-2.1/HASH/video-android-4.2.0/jars/libs/libwebrtc.jar
The definition of type com.twilio.video.EglBaseProvider in video-android-4.2.0 has an <init> with a static invoke to EglBase::create.
The interface org.webrtc.EglBase is defined in libwebrtc.jar
Outside of gradle, putting libwebrtc.jar in the program path or the classpath when compiling with D8 and a min-api to desugar default interface methods, the call to EglBase::create is correctly rewritten to EglBase$-CC::create.
Running:
./gradlew :quickstartKotlin:assembleDebug --info
yields output with:
<snip>/.gradle/caches/transforms-2/files-2.1/a4e476e9d975337caa4d7a965148dce1/video-android-4.2.0/jars/classes.jar: D8: Type `org.webrtc.EglBase` was not found, it is required for default or static interface methods desugaring of `void com.twilio.video.EglBaseProvider.<init>()`
More info:
The application has a dependency on com.twilio:video-android:4.2.0 and it appears to include a copy of webrtc somehow. Found it locally in .gradle/caches/transforms-2/files-2.1/HASH/video-android-4.2.0/jars/libs/libwebrtc.jar
The definition of type com.twilio.video.EglBaseProvider in video-android-4.2.0 has an <init> with a static invoke to EglBase::create.
The interface org.webrtc.EglBase is defined in libwebrtc.jar
Outside of gradle, putting libwebrtc.jar in the program path or the classpath when compiling with D8 and a min-api to desugar default interface methods, the call to EglBase::create is correctly rewritten to EglBase$-CC::create.
pe...@google.com <pe...@google.com> #5
As a workaround you can add "android.enableDexingArtifactTransform.desugaring=false" to gradle.properties.
In Android Gradle Plugin 3.5 we started dexing and desugaring using Gradle artifact transforms. This allows us to use Gradle caching and parallelism. The way we set up desugaring classpath is by using dependencies information from the POM file. In this case, "video-android-4.2.0" packages libwebrtc.jar inside the AAR and we fail to add those files to desugaring classpath. D8 is unable to resolve types and to rewrite invocation to the generated companion class.
In Android Gradle Plugin 3.5 we started dexing and desugaring using Gradle artifact transforms. This allows us to use Gradle caching and parallelism. The way we set up desugaring classpath is by using dependencies information from the POM file. In this case, "video-android-4.2.0" packages libwebrtc.jar inside the AAR and we fail to add those files to desugaring classpath. D8 is unable to resolve types and to rewrite invocation to the generated companion class.
pe...@google.com <pe...@google.com> #6
Note, I am facing the same issue in an app that uses a library, lets call it libraryB, that make use of webrtc but I don't include webrtc.jar in libraryB, as I use implementation configuration for libraryB. I then generates an AAR of it and import this AAR as a module to make use of it on final app. Therefore in app's build.gradle file I also import webrtc as implementation.
I have attached an android project so you can reproduce this case. webrtclibAAR module is an AAR file generated by running gradle assemble task on webrtclib module
I have attached an android project so you can reproduce this case. webrtclibAAR module is an AAR file generated by running gradle assemble task on webrtclib module
ap...@google.com <ap...@google.com> #7
Continuing my last comment:
Also I've noticed that uploading libraryB to a Nexus Server instead of using AAR as a module works properly
Also I've noticed that uploading libraryB to a Nexus Server instead of using AAR as a module works properly
le...@google.com <le...@google.com> #8
The issue is that we need AAR to have POM alongside to contain all dependency information. When just dropping an AAR to an output directory, this information is lost. However, when publishing to a Maven repo, this information exists.
Also, this is not exactly the same issue as the original reporter reported, but I hope my answer helps :)
Also, this is not exactly the same issue as the original reporter reported, but I hope my answer helps :)
el...@chromium.org <el...@chromium.org> #9
Our team found a fix for this issue. We manage the video-android dependency and had to build that AAR with the latest Gradle plugin (3.5.0). Once we did that, it resolved the crash. Thank you for looking into this problem though.
pe...@google.com <pe...@google.com> #10
Never mind, this is still an issue. We found a false positive in our testing that led us to believe building video-android with gradle plugin 3.5.0 resolved the crash. It is definitely related to storing the AAR to our artifact repository in Bintray. As a sanity check we referenced the AAR locally and it works fine.
Also, thank you for sharing the workaround above! We tested adding that line to the quickstartKotlin's gradle.properties file and it resolved the crash. We'll use this as a temporary solution in the meantime.
(Used a different email address here, sorry for the confusion)
Also, thank you for sharing the workaround above! We tested adding that line to the quickstartKotlin's gradle.properties file and it resolved the crash. We'll use this as a temporary solution in the meantime.
(Used a different email address here, sorry for the confusion)
le...@google.com <le...@google.com> #11
Also, are there plans to resolve dependencies that are packaged outside of what's specified in a POM file within the AAR? Or would we need to ensure that a POM file is always present defining dependencies like libwebrtc.jar? Our team would like to know so we can either prioritize this work or wait for the next release of the Gradle plugin. Thanks!
le...@google.com <le...@google.com> #12
We will handle jars packaged under libs directory in an AAR, so there is no need to add those in the POM file. cmw@ fixed that in 3.6 (he can add more details when it got fixed), so that should work, and there is no need to add e.g. libwebrtc.jar to the POM file.
am...@chromium.org <am...@chromium.org> #13
I think this is fixed in 3.6.0-alpha05 by
https://android.googlesource.com/platform/tools/base/+/f7f446e6c304b035e347eccd181e2b6ee4b16d97#
which merges all of the the libs jars from the AAR into one jar rather than exporting all of them separately, meaning that the classes in an AAR are all desugared together.
which merges all of the the libs jars from the AAR into one jar rather than exporting all of them separately, meaning that the classes in an AAR are all desugared together.
am...@chromium.org <am...@chromium.org> #14
Great! Thank you for the update on this.
da...@google.com <da...@google.com> #15
I'm afraid this is not solved yet. Before my last comment (https://issuetracker.google.com/issues/140508065#comment6 ) I've tested it on Android Studio Canary with 3.6.0-alpha10, and I took the same error.
pe...@google.com <pe...@google.com> #16
That is a subtly different issue, as you are not embedding the AAR. In general please file separate issues.
Your issue is that you've lost the dependency information by importing the aar as a subproject. I wish we didn't have a template for that as it leads to issues like this.
The way to solve your issue is to publish the AAR to e.g. a local maven repository so the dependency information is preserved and everything will work.
Your issue is that you've lost the dependency information by importing the aar as a subproject. I wish we didn't have a template for that as it leads to issues like this.
The way to solve your issue is to publish the AAR to e.g. a local maven repository so the dependency information is preserved and everything will work.
sr...@chromium.org <sr...@chromium.org> #17
Any update on this? This still isn't resolved in 3.5.1 and I'm stuck on the older version still. Several people in this thread have the same issue and are waiting for this to be resolved.
https://github.com/twilio/video-quickstart-android/issues/430
ap...@google.com <ap...@google.com> #18
See #13: This is not resolved in 3.5.1, it is resolved in 3.6.0-alpha05.
pe...@google.com <pe...@google.com> #19
We're considering a cherry-pick for this for a subsequent 3.5.x
sp...@google.com <sp...@google.com> #20
That would be very helpful! The sooner the better.
am...@chromium.org <am...@chromium.org> #21
We encountered the same issue when trying to add JAR file packaged with AAR as a local dependency.
Workaround "android.enableDexingArtifactTransform.desugaring=false" worked for us.
Then I tried 3.6.0-beta01 and 4.0.0-alpha01 and both versions didn't work - issue is still there.
Workaround "android.enableDexingArtifactTransform.desugaring=false" worked for us.
Then I tried 3.6.0-beta01 and 4.0.0-alpha01 and both versions didn't work - issue is still there.
rz...@google.com <rz...@google.com> #22
Re #21:
Thanks for the report. Which artifact contains the interface with a default method, and where is the class that implements it defined? If you are able to share a sample project that would be great.
Thanks for the report. Which artifact contains the interface with a default method, and where is the class that implements it defined? If you are able to share a sample project that would be great.
pe...@google.com <pe...@google.com> #23
I was able to isolate the issue and make a demo project to reproduce it. Tested on Android Studio 3.6.0-beta01 with AGP 3.6.0-beta01 - issue is still reproducible.
Steps to reproduce:
1. Download and import attached project
2. There will be two modules: app and library
app depends on 'library' and on 'androidx.lifecycle:lifecycle-common-java8:2.1.0'
library depends on 'androidx.lifecycle:lifecycle-common-java8:2.1.0'
3. Initial sync will fail because app depends directly on generated AAR. This file would be generated by :library:assemble task inside the /library/build/outputs/aar/
Run ./gradlew :library:assemble to assemble the 'library' module
4. After library is assembled try Gradle Sync button again. Now it should sync just fine.
5. Create an emulator that runs pre-java8 API, I was testing on Nexus 5 API 21 (required to enable desugaring)
6. Run app on the emulator. Upon launch app will crash.
7. In app/build.gradle comment out this:
implementation(name: 'library-debug', ext: 'aar')
And uncomment this line:
implementation project(":library")
8. Try running app again. With this module dependency app will run fine and activity will be displayed.
9. Revert step #7 to make dependency to be 'aar' again
10. In gradle.properties uncomment following line
android.enableDexingArtifactTransform.desugaring=false
11. Try running app. With this workaround app will run fine.
Explanation of the bug cause:
- Lifecycler-common-java8 contains an interface DefaultLifecycleObserver with default implementation on 6 methods
- 'library' has a class 'MyCustomObserver : DefaultLifecycleObserver' which overrides only 2 methods from DefaultLifecycleObserver
- 'app' instantiates 'MyCustomObserver' in its Application onCreate() and attempts to call method on it which is NOT overridden in 'MyCustomObserver'
Checking the bytecode for the case when AAR is used I found that 'MyCustomObserver' would only have two methods in it.
In the bytecode for the module dependency (steps #7-8) 'MyCustomObserver' has 6 methods, where 4 of those are synthetic and pointing to static methods generated by D8 in the 'DefaultLifecycleObserver$-CC' class
To sum things up, it looks like D8 cannot figure out where to get 'DefaultLifecycleObserver' while processing 'MyCustomObserver' - because AAR doesn't have any dependencies - and therefore it doesn't generate any synthetic methods for it.
Steps to reproduce:
1. Download and import attached project
2. There will be two modules: app and library
app depends on 'library' and on 'androidx.lifecycle:lifecycle-common-java8:2.1.0'
library depends on 'androidx.lifecycle:lifecycle-common-java8:2.1.0'
3. Initial sync will fail because app depends directly on generated AAR. This file would be generated by :library:assemble task inside the /library/build/outputs/aar/
Run ./gradlew :library:assemble to assemble the 'library' module
4. After library is assembled try Gradle Sync button again. Now it should sync just fine.
5. Create an emulator that runs pre-java8 API, I was testing on Nexus 5 API 21 (required to enable desugaring)
6. Run app on the emulator. Upon launch app will crash.
7. In app/build.gradle comment out this:
implementation(name: 'library-debug', ext: 'aar')
And uncomment this line:
implementation project(":library")
8. Try running app again. With this module dependency app will run fine and activity will be displayed.
9. Revert step #7 to make dependency to be 'aar' again
10. In gradle.properties uncomment following line
android.enableDexingArtifactTransform.desugaring=false
11. Try running app. With this workaround app will run fine.
Explanation of the bug cause:
- Lifecycler-common-java8 contains an interface DefaultLifecycleObserver with default implementation on 6 methods
- 'library' has a class 'MyCustomObserver : DefaultLifecycleObserver' which overrides only 2 methods from DefaultLifecycleObserver
- 'app' instantiates 'MyCustomObserver' in its Application onCreate() and attempts to call method on it which is NOT overridden in 'MyCustomObserver'
Checking the bytecode for the case when AAR is used I found that 'MyCustomObserver' would only have two methods in it.
In the bytecode for the module dependency (steps #7-8) 'MyCustomObserver' has 6 methods, where 4 of those are synthetic and pointing to static methods generated by D8 in the 'DefaultLifecycleObserver$-CC' class
To sum things up, it looks like D8 cannot figure out where to get 'DefaultLifecycleObserver' while processing 'MyCustomObserver' - because AAR doesn't have any dependencies - and therefore it doesn't generate any synthetic methods for it.
Description
VULNERABILITY DETAILS
The
AIManager
mojo interface can be obtained by the renderer. When binding the receiver, the browser will save the corresponding context to the ReceiverSet [0].Type definition of context:
For requests sent from a regular frame, the context here is actually a raw pointer to
RenderFrameHost
. However, there is no code that guarantees the consistency of the lifecycles ofAIManagerKeyedService
and the iframe.AIManagerKeyedService
can completely outliveRenderFrameHost
! If the iframe is removed before calling the functionality ofAIManagerKeyedService
, it will lead to a UAF.[0]https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/ai/ai_manager_keyed_service.cc;drc=8b00b43b06712a6c61f59f2e9f9230459d2a9025;l=308
[1]https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/ai/ai_context_bound_object_set.h;drc=8b00b43b06712a6c61f59f2e9f9230459d2a9025;l=27
Vulnerability Trigger
An attacker can trigger the UAF with the following steps:
Bind the
AIManager
interface in a child frame.Send this interface handle to the parent frame.
Remove the child frame from the parent frame.
Trigger an IPC call to
AIManager
that uses the already freedRenderFrameHost
object.Our provided POC demonstrates these steps in detail. Please refer to the code for specifics.
Exploitability Analysis
We note that this UAF is not yet protected by MiraclePtr (for details, see asan.txt):
RenderFrameHost UAF is a known vulnerability pattern that is frequently exploited to achieve sandbox escape. For specific examples, refer to case 1 and case 2 .
At least on Windows, using our provided POC, it's easy to achieve full control of
RenderFrameHost
. Below is the crash site displayed by windbg; for a detailed backtrace, see windbg.txt.We believe this vulnerability has extremely high exploitability, is stable, and easy to trigger. We recommend that the Chrome team fix it promptly.
BISECTION
Introduced byhttps://chromium.googlesource.com/chromium/src/+/d37f2ff9881443eca070192a005b9853e8a3bf74
VERSION
Chrome Version: 130.0.6712.0, HEAD + stable
Operating System: All
REPRODUCTION CASE
Host poc files on an HTTP server.
CRASH INFORMATION
Type of crash: browser
Crash log: see asan.txt and windbg.txt
CREDIT INFORMATION
Reporter credit: DARKNAVY(@DarkNavyOrg)