Add FLAG_SECURE to Dialog Window If Hosted in Activity with FLAG_SECURE Set [143778149]

Fixed

Bug

Status Update

No update yet.

Description

mm...@commonsware.com

created issue #1

Nov 3, 2019 02:51PM

Android Studio Build:

Android Studio 4.0 Canary 1
Build #AI-192.6817.14.36.5959023, built on October 22, 2019
Runtime version: 1.8.0_212-release-1586-b4-5784211 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 5.0.0-32-generic
GC: ParNew, ConcurrentMarkSweep
Memory: 1981M
Cores: 8
Registry: ide.new.welcome.screen.force=true, debugger.watches.in.variables=false
Non-Bundled Plugins: CheckStyle-IDEA

Version of Gradle Plugin: 4.0.0-alpha01
Version of Gradle: 5.6.1
Version of Kotlin: 1.3.60-eap-25
OS: Ubuntu 19.04

-----------

Steps to Reproduce:
1. UnZIP the attached project and import it into Android Studio
2. Run the app
3. Start recording a screencast (e.g., from Android Studio)
4. Tap the "Show Dialog" button to show an AlertDialog
5. Wait a moment
6. Tap the "OK" button again to dismiss that dialog
7. Stop recording the screencast
8. Look at the screencast

Expected Results: The screencast to be completely empty, as we are recording the functionality of an activity that has FLAG_SECURE set

Actual Results: The AlertDialog appears in the screencast

The attached MP4 is a screencast taken of this app, using a Pixel 4 running Android 10.

----

If you are going to create a Window with WindowManager, you need to see whether we are in a secure window now and propagate that secure status. Otherwise, we wind up in the same situation that we have with the View-based UI framework, where FLAG_SECURE misses lots of content (menus, Spinner, dialogs, toasts, etc.), because we do not control those windows and cannot set FLAG_SECURE on them. See

https://github.com/commonsguy/cwac-security/blob/master/docs/FLAGSECURE.md and

https://issuetracker.google.com/issues/37100029 for historical context.

I think that Dialog should handle FLAG_SECURE itself, either implicitly or via a WindowSecurityPolicy value (see

https://issuetracker.google.com/issues/143778148 for more on that). While it is theoretically possible for use to maintain a SecureDialog composable that adds FLAG_SECURE, we would also need to maintain a SecureAlertDialog composable, along with Secure... variants of everything else in Compose that uses Dialog.

Given that you know whether a DialogWrapper needs to be secure, making it secure is a matter of updating the dialog's window's flags:

if (markAsSecure) window?.setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE)

(assumed to be in the init block of DialogWrapper)

Thanks for considering this!

ComposeInsecure-20191103.zip

138 KB

Download

ComposeInsecureDemo-20191103.mp4

249 KB

Download

Comments

pa...@google.com <pa...@google.com> Nov 4, 2019 12:16PM

Assigned to pa...@google.com.

ch...@gmail.com <ch...@gmail.com> #2Nov 14, 2019 05:38PM

A couple of questions:

1. Have you saw crash in real device or only in simulators?
2. Do you use dynamic feature for language ID?

ap...@google.com <ap...@google.com> #3Oct 5, 2020 04:14PM

Tested on Android 12 Emulator with custom executor, but cannot repro this issue.

pa...@google.com <pa...@google.com> #4Oct 7, 2020 03:21PM

Marked as fixed.

Second crash in the description is from a real device. Experienced it myself on two different Xiaomi phones, plus lots of crashes from users in the Google Play console.
Dynamic features are not used in the application.

As a wild guess, I have downgraded build tools from 31.0.0 to 30.0.3, compileSdk from 31 to 30, and moved all work with Language ID to the service in a separate process (just to be sure that crash can kill secondary process instead of main). This combination is in beta for 2 days by now and I don't see any SIGSEGV crashes.

mm...@commonsware.com <mm...@commonsware.com> #5Oct 11, 2020 02:08PM

Hmm, I feel the crash might be something related to separate/secondary process.

I also changed compileSdk and targetSDK to 31 but still cannot repro this issue.

pa...@google.com <pa...@google.com> #6Oct 13, 2020 10:08AM

On the contrary, there was no separate process before, when crashes started.

In the new build (with the aforementioned changes) I can see SIGSEGV crash, but only one instead of dozens and it has a bit different backtrace:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
liblanguage_id_jni.so (offset 0x11e000)

backtrace:
  #00  pc 000000000003c7c0  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003b960  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bb48  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 000000000003bafc  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000036c98  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000032714  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000031cac  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/split_config.arm64_v8a.apk!lib/arm64-v8a/liblanguage_id_jni.so (offset 0x11e000)
  #00  pc 0000000000057438  /data/app/azagroup.reedy-mF7zTu2bv_ELlbFArwNgqA==/oat/arm64/base.odex (offset 0x57000)

Issue 143778149