FLAG_SECURE don't work on Flutter application

[jonataslaw]

Android flags do not work for screen recording on any device. The video recording displays the content normally.
With exactly the same flags, an application recently migrated from kotlin to Flutter, does NOT record kotlin video (expected behavior), but in Flutter ignores (in the latest version) all android flags.
[Edit:
When I opened this issue, if I added flags to onCreate, and started recording before opening the application, FLAG_SECURE worked. If the app was opened before the video was recorded, it wouldn't work, which shows that there is some code (maybe in FlutterView, or SystemChrome, I suppose) that was clearing all flags. However, in the latest version, with the removal of onCreate from MainActivity, not even that way the flags work, there is no way to make them work]
[EDIT 2 I created a malicious test application that records the user's screen using webrtc and even with FLAG_SECURE enabled I managed to get the screen in streaming video for 1h. I think this vulnerability fix should be a priority right now].

Steps to Reproduce

import androidx.annotation.NonNull
import io.flutter.embedding.android.FlutterActivity
import io.flutter.embedding.engine.FlutterEngine
import io.flutter.plugin.common.MethodChannel
import io.flutter.plugins.GeneratedPluginRegistrant
import io.flutter.embedding.android.FlutterView
import android.view.SurfaceView
import android.view.WindowManager

class MainActivity: FlutterActivity() {
  
  override fun configureFlutterEngine(@NonNull flutterEngine: FlutterEngine) {
    GeneratedPluginRegistrant.registerWith(flutterEngine)
            SurfaceView(applicationContext).setSecure(true)
            this.window.setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE)
            window.setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE)  
  }
}

Logs

[✓] Flutter (Channel beta, v1.12.13+hotfix.6, on Linux, locale pt_BR.UTF-8)
    • Flutter version 1.12.13+hotfix.6 at /opt/flutter
    • Framework revision 18cd7a3601 (9 days ago), 2019-12-11 06:35:39 -0800
    • Engine revision 2994f7e1e6
    • Dart version 2.7.0

 
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
    • Android SDK at /home/jonatas/Android/Sdk
    • Android NDK location not configured (optional; useful for native profiling support)
    • Platform android-29, build-tools 29.0.2
    • Java binary at: /usr/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_232-b09)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at google-chrome

[!] Android Studio (not installed)
    • Android Studio not found; download from https://developer.android.com/studio/index.html
      (or visit https://flutter.dev/setup/#android-setup for detailed instructions).

[✓] IntelliJ IDEA Community Edition (version 2019.3)
    • IntelliJ at /usr/share/idea
    • Flutter plugin version 42.0.4
    • Dart plugin version 193.5731

[✓] Connected device (3 available)
    • Moto Z2 • 0033366099 • android-arm    • Android 9 (API 28)
    • Chrome       • chrome     • web-javascript • Chromium 79.0.3945.88 Arch Linux
    • Web Server   • web-server • web-javascript • Flutter Tools

Sample code that can make any application written in flutter victim of attacks using, for example, flutter_webrtc (or if the application is kotlin / java, you can use the native webrtc plugin in the same way):
Connect to your WEB_RTC SERVER, receive a peer_id (that will be used in the future to read the screen), and call this function anywhere in your app createPeerConnection(peer_id, 'video', true);

Future<MediaStream> createStream(media, user_screen) async {
    final Map<String, dynamic> mediaConstraints = {
      'audio': true,
      'video': {
        'mandatory': {
          'minWidth':
              '640', 
          'minHeight': '480',
          'minFrameRate': '30',
        },
        'facingMode': 'user',
        'optional': [],
      }
    };

    MediaStream stream = user_screen
        ? await navigator.getDisplayMedia(mediaConstraints)
        : await navigator.getUserMedia(mediaConstraints);
    if (this.onLocalStream != null) {
      this.onLocalStream(stream);
    }
    return stream;
  }

  createPeerConnection(id, media, user_screen) async {
    if (media != 'data') _localStream = await createStream(media, user_screen);
    RTCPeerConnection pc = await createPeerConnection(_iceServers, _config);
    if (media != 'data') pc.addStream(_localStream);
    pc.onIceCandidate = (candidate) {
      _send('candidate', {
        'to': id,
        'candidate': {
          'sdpMLineIndex': candidate.sdpMlineIndex,
          'sdpMid': candidate.sdpMid,
          'candidate': candidate.candidate,
        },
        'session_id': this._sessionId,
      });
    };
    pc.onAddStream = (stream) {
      if (this.onAddRemoteStream != null) this.onAddRemoteStream(stream);
    };
    pc.onDataChannel = (channel) {
      _addDataChannel(id, channel);
    };
    return pc;
  }

Its done, knowing the victim's peer_id, you will be able to see her screen, and what she types on the keyboard in any Flutter application, even if FLAG_SECURE is activated.

Reminder, this is a common app that would easily go through the playstore, and anyone who installs it, can have their screen mirrored from a distance. For that there is FLAG_SECURE on android. Bank applications (like a large case that just opted for Flutter, Nubank) in some countries are required by law to have this option enabled, mine for example.
Any other application that involves confidential data, cannot be done with Flutter if there is no way to use FLAG_SECURE.

[jonataslaw]

@dnfield Sorry to mention that, but I wonder if you could take a look at this.

[dnfield]

/cc @matthew-carroll or @mklim who might know more immediately what's going on here

[dnfield]

Using the Kotlin code you specified to make my Flutter app secure, I observe the following:

• adb exec-out screencap -p gives me an empty file (but not if I switch to a insecure app)
• transitioning to the app switcher makes the app tile go black
• adb shell screenrecord records a black screen for the app.

I haven't tried your WebRTC thing yet.

[dnfield]

Are you doing all of this within the same application, or two separate applications?

It seems like some code may be missing from your webRTC example code - it's refering to varaibles not present in the sample.

It may help to just upload a github project that fully reproduces this.

[dnfield]

I grabbed the example from https://github.com/cloudwebrtc/flutter-webrtc. When I use the getUserMedia API, Android Q gives me a big scary warning telling me that this application will be able to record secure information, including passwords, etc.

I don't think this is a Flutter bug or a regression. Can you confirm?

[dnfield]

(I get the warning described here: https://support.google.com/android/thread/13791498?hl=en). I strongly suspect this is just by design in Android, I'm curious about your other app that prevented this.

[dnfield]

Actually, even when I accept that warning and put the app into split screen, it doesn't capture the secure app. I just get a black screen.

[jonataslaw]

Using the Kotlin code you specified to make my Flutter app secure, I observe the following:

• adb exec-out screencap -p gives me an empty file (but not if I switch to a insecure app)
• transitioning to the app switcher makes the app tile go black
• adb shell screenrecord records a black screen for the app.

I haven't tried your WebRTC thing yet.

The Flutter application is installed on a Motorola Moto z2 along with webrtc.
I connect to the peer known both from the browser (where I made a webrtc wrapper) and from a Samsung m20 and get the screen.
I tested it with emulators too, and it didn't work on any of them.

[dnfield]

Sounds like it could be a bug in the Android version on that device.

[jonataslaw]

FLAG_SECURE on emulator https://youtu.be/S4Cf9-6gftk
Remote Screen Leak https://youtu.be/4tUrBzhu4vU

[jonataslaw]

Sounds like it could be a bug in the Android version on that device.

I just tested on 6 different devices, screen recording was possible on all of them.
Can you tell me which android device/API you were successful in? In Android 9 no device worked, neither on the emulator nor on a physical device.

[dnfield]

I tried it on Android Q/10 on a Pixel 4. I'll try later today on an earlier API level device.

[jonataslaw]

Test on Samsung m20 https://youtu.be/H4SbqxMwwNs

[jonataslaw]

Are you doing all of this within the same application, or two separate applications?

It seems like some code may be missing from your webRTC example code - it's refering to varaibles not present in the sample.

It may help to just upload a github project that fully reproduces this.

The code I sent was a sample code to connect to the webrtc server, and send the screen.
In my case, I created a test app that just does this, I provided the code in dart, but the app could be written in Java, Kotlin, Xamarin, RN, or anything else that supports WEB_RTC. This part of the code just opens a peer connection.
I don't see why to put this in the same application, since if someone wanted to send a malicious app written in Flutter, he wouldn't need Flag_secure, he would make it as easy as possible to receive the screen.
The example given was a random app (another app that can be Flutter or whatever), which could have other functions, but at some point it sends a web_rtc connection (intentionally) maliciously. This cannot be prevented, there are hundreds of thousands of apps in the playstore that have code of this type, I noticed in some games installed in the past and I already reported and were removed, but that is beside the point.
Whoever builds a bank application or any application that has a payment method, always inserts FLAG_SECURE on that screen, or on the entire application. I am not talking about 1 application, this is mandatory by law in most countries (in mine for example), and there is not a single bank application that does not use FLAG_SECURE, as this is the only way to prevent spys that can be installed on the cell phone (which is not difficult, for every 100 games in the playstore, at least 5 will have some type of code) obtain credit card data or sensitive data.
In addition, there are applications that monitor logs, and can receive a peer_id from a connection from another application, and make use of it too, I am an expert in information security, but I think this is not in the scope of this issue, and it is not advisable to explain the hundreds of ways to get sensitive data and screen recording from a device.
WHAT IS IMPORTANT TO FLUTTER, is just the possibility to block it. Any application must be able to define FLAG_SECURE for an entire screen or application, to prevent spys that may be installed from displaying sensitive data. And at least in the tested apps, flag_secure didn't work for me.
If you want, I can build a web_rtc server, and provide a spy app using Flutter (to make it easier for you to understand the code) and insert it into a repository for you to do the tests.

[dnfield]

I'm fairly convinced this is an Android bug at this point.

I just tried on Android 7.0 on an Moto G4. I still get a popup (although less scary) warning me that WebRTC will be recording the whole screen. Unlike on Android Q/Pixel 4, it is actually able to record the secure screen.

I'm not sure what Flutter can do about this, and I'm fairly sure that this is an issue not just for Flutter apps.

[dnfield]

FWIW, it should not be possible for a malicious app to record the screen even on lower API levels without the popup asking for permission. Of course, nothing would stop a naive user from accepting that and having a recording going on for ever... But again, I don't think there's anything Flutter can do about this, it's an Android thing.

[jonataslaw]

I grabbed the example from https://github.com/cloudwebrtc/flutter-webrtc. When I use the getUserMedia API, Android Q gives me a big scary warning telling me that this application will be able to record secure information, including passwords, etc.

I don't think this is a Flutter bug or a regression. Can you confirm?

This warning is displayed in the latest APIs, however, it is not displayed at all (Believe me, there are devices that it stays on the notification bar just warning that the screen is being recorded, but there is no popup. There are thousands of different rooms, especially with numerous Chinese devices being launched every day, but that is not the scope of the issue.) and is not a permission, it is merely a warning. Also, imagine the user installing a screen recording application to show someone something. If he accepts that the screen will be recorded, then his screen can be recorded at any time remotely, without warning, but this is a specific Android vulnerability which is not the scope of this issue.
As I said before, anyone can have a spy installed, and it is not difficult to obtain the user's trust with a screen recording tool and use it maliciously, the only way to prevent this is by using FLAG_SECURE. The scope of the issue is not related to Android, and its vulnerabilities, as I am discussing elsewhere.
The scope of this issue is solely the use of FLAG_SECURE on android, and because they work in Kotlin apps, but they don't work in Flutter apps. I believe that at some point FlutterActivity or SystemChrome are ignoring the properties of setSecure (true), or a new instance of SurfaceView is being started and setSecure is ignored. I haven't looked at the structure of FlutterView and FlutterActivity to find out about it, but it's just a guess.

[jonataslaw]

I'm fairly convinced this is an Android bug at this point.

I just tried on Android 7.0 on an Moto G4. I still get a popup (although less scary) warning me that WebRTC will be recording the whole screen. Unlike on Android Q/Pixel 4, it is actually able to record the secure screen.

I'm not sure what Flutter can do about this, and I'm fairly sure that this is an issue not just for Flutter apps.

I tested FLAG_SECURE on the same devices (Moto z2 and Samsung m20) using kotlin right now, and it works on both activitys and fragments. I added FLAG_SECURE only in one tab, and open the front camera with web_rtc in all, and the tab with flag_secure was not recorded. I do not rule out the hypothesis that it could be a bug in Android, however, after these tests, I am almost convinced that there is something in Flutter.

[mklim]

@jonataslaw I'm sorry if this information has already been stated elsewhere in the thread, I'm having trouble parsing the comment chain. Do you mind stating exactly what the behavior on Android is here that Flutter is failing to match? I get that the basic problem is screen recording, but I'm not understanding exactly what capability Android has that Flutter is missing. My best guess is that you're saying that there's a way to set FLAG_SECURE on an Android app so that the warning pop up @dnfield mentioned is never shown and the recording is just silently blocked, is that correct or is it something else?

[jonataslaw]

@jonataslaw I'm sorry if this information has already been stated elsewhere in the thread, I'm having trouble parsing the comment chain. Do you mind stating exactly what the behavior on Android is here that Flutter is failing to match? I get that the basic problem is screen recording, but I'm not understanding exactly what capability Android has that Flutter is missing. My best guess is that you're saying that there's a way to set FLAG_SECURE on an Android app so that the warning pop up @dnfield mentioned is never shown and the recording is just silently blocked, is that correct or is it something else?

I create a Flutter application and add FLAG_SECURE.
Expected behavior: Screen recording or remote screen exposure via WEB_RTC is not possible.
Current behavior:
Defining FLAG_SECURE is the same as not defining, it does not change anything regarding screen recording, but on some devices (some, Xiaomis for example not even this works) it will only prevent Screenshots.
The app can still be recorded by any screen recorder on any Flutter device with FLAG_SECURE with android 9 or lower.

WEB_RTC I just exposed a critical vulnerability related to this behavior, where spys can record the screen of applications Flutter, but they cannot record the screen of applications kotlin, RN, Xamarin, Java and etc., which makes Flutter unsafe for applications that have payments, or banking applications, since the app's screen can be transmitted remotely without any problem via WEB_RTC.

[mklim]

I understand now, thank you for filing this issue and taking the time to explain the problem in more depth.

I did a bit of digging to try and reproduce the difference by using a pure Kotlin test app and a test Flutter app combined with adb shell screenrecord. I wanted to get the barest minimal reproduction case of the problem without any possible extra complications. So far I haven't been able to repro this problem with just ADB, but I'll try next with the WebRTC demo and see if it reproduces there.

Samples:

• Android test case: mklim/test_android_app@531db2e
• Flutter test case: mklim/test_app@fd401af

Steps:

1. Deploy app to device.
2. adb shell screenrecord --size 270x480 --time-limit=3 /sdcard/Movies/sample.mp4 && adb pull /sdcard/Movies/sample.mp4
3. Observe video.

In both cases the video was black except for the phone's status bar with my patch applied (as expected if there were no bug), and displayed the sample app's screen plus the phone's status bar without it (just double checking that adb shell screenrecord didn't have any problems). So I'll try the WebRTC demo next and see what that uncovers.

[jonataslaw]

I understand now, thank you for filing this issue and taking the time to explain the problem in more depth.

I did a bit of digging to try and reproduce the difference by using a pure Kotlin test app and a test Flutter app combined with adb shell screenrecord. I wanted to get the barest minimal reproduction case of the problem without any possible extra complications. So far I haven't been able to repro this problem with just ADB, but I'll try next with the WebRTC demo and see if it reproduces there.

Samples:

• Android test case: mklim/test_android_app@531db2e
• Flutter test case: mklim/test_app@fd401af

Steps:

1. Deploy app to device.
2. adb shell screenrecord --size 270x480 --time-limit=3 /sdcard/Movies/sample.mp4 && adb pull /sdcard/Movies/sample.mp4
3. Observe video.

In both cases the video was black except for the phone's status bar with my patch applied (as expected if there were no bug), and displayed the sample app's screen plus the phone's status bar without it (just double checking that adb shell screenrecord didn't have any problems). So I'll try the WebRTC demo next and see what that uncovers.

I cloned your repository, in the kotlin app I had a black screen, in the Flutter app, I got this:
https://drive.google.com/file/d/1ZUNK2Uo81kITUldHK8OVikR0h8Sc07UA/view?usp=sharing

Have you tested on Android 9 below?
FLAG_SECURE seems to work on android 10, at least on the tested devices.

[mklim]

Have you tested on Android 9 below?

I was testing on Android 9 (SDK 29) wtih a Pixel 1. I just tried again with SDK 27 (8.1) and SDK 23 (6.0) Nexus 6P and saw the same (correct) behavior on my end. Do you mind listing the specific device/android versions you're using to repro the bug? This may have to do with device version too and not just SDK version.

Edited to add: Also just to make sure, are you getting the video through adb shell screenrecord or some other way? Just want to make sure I'm testing it the same way. Thank you again for debugging this!

[jonataslaw]

Have you tested on Android 9 below?

I was testing on Android 9 (SDK 29) wtih a Pixel 1. I just tried again with SDK 27 (8.1) and SDK 23 (6.0) Nexus 6P and saw the same (correct) behavior on my end. Do you mind listing the specific device/android versions you're using to repro the bug? This may have to do with device version too and not just SDK version.

Edited to add: Also just to make sure, are you getting the video through adb shell screenrecord or some other way? Just want to make sure I'm testing it the same way. Thank you again for debugging this!

Android:
Moto z2 play.
Moto z2 Force.
Moto g4.
Lenovo Vibe x3
Lenovo k5
Samsung m20
Samsung galaxy s8

Command:
adb shell screenrecord --size 270x480 --time-limit=3 /sdcard/Movies/sample.mp4 && adb pull /sdcard/Movies/sample.mp4

result:
https://drive.google.com/file/d/1ZUNK2Uo81kITUldHK8OVikR0h8Sc07UA/view?usp=sharing

With remote recorder:
Samsung m20 https://youtu.be/H4SbqxMwwNs
Moto z2 play https://youtu.be/S4Cf9-6gftk

local recorder with emulator:
FLAG_SECURE on emulator https://youtu.be/S4Cf9-6gftk

[mklim]

I also have repro. I can see the Flutter but not the Kotlin app through adb shell screenrecord on a Galaxy A5 running SDK 24 (7.0) with the sample apps I uploaded earlier.

The one thing I can think of is that Flutter UIs are rendered into SurfaceViews, which come with their own setSecure(boolean) API. My current working theory is that maybe for these devices this API is expected to also be set for the SurfaceView to not be shown in addition to the property being set on the window. I think there may be something about Pixel/Nexus devices that stops this from reproducing there? I'm testing this out now.

[jonataslaw]

I also have repro. I can see the Flutter but not the Kotlin app through adb shell screenrecord on a Galaxy A5 running SDK 24 (7.0) with the sample apps I uploaded earlier.

The one thing I can think of is that Flutter UIs are rendered into SurfaceViews, which come with their own setSecure(boolean) API. My current working theory is that maybe for these devices this API is expected to also be set for the SurfaceView to not be shown in addition to the property being set on the window. I think there may be something about Pixel/Nexus devices that stops this from reproducing there? I'm testing this out now.

Hey, that makes a lot of sense!
I was now looking for an opening in setSecure() in the Flutter API, to create middleware that I could turn on or off to proceed with the tests.
I totally agree with your guess.

[mklim]

The SurfaceView#setSecure API appears to be the key here. Calling it fixes the issue for me: mklim/test_app@4a14065.

However unfortunately the new (default) v2 Android embedding doesn't really expose the underlying SurfaceView. My patch is using the v1 embedding in order to get a reference to the SurfaceView easily. (I did test it without the setSecure call just to make sure that alone didn't affect the behavior.)

So to really consider this closed, I think we also need to expose the underlying SurfaceView in the v2 embedding. /cc @matthew-carroll, who mentioned offline that this is already in process for another unrelated issue.

Ideally there'd also be some kind of workaround for any developers on the v2 embedding impacted by this today. I'm going to see if I can come up with some code sample to use as a mitigation in the short term before the new API lands and rolls.

[mklim]

It's possible to set this flag in the v2 embedding today by walking through the View hierarchy (full app example at mklim/test_app@bd36511). That workaround isn't ideal long term because it relies on the internal implementation details of how the Flutter engine creates Views, but anyone impacted by this currently can use that as an immediate workaround now while waiting for a patch exposing the SurfaceView directly to land and roll.

[jonataslaw]

It's possible to set this flag in the v2 embedding today by walking through the View hierarchy (full app example at mklim/test_app@bd36511). That workaround isn't ideal long term because it relies on the internal implementation details of how the Flutter engine creates Views, but anyone impacted by this currently can use that as an immediate workaround now while waiting for a patch exposing the SurfaceView directly to land and roll.

Thanks, thanks, thanks and thanks for this temporary fix, I tested and managed to get the screen via webrtc of everything, except my application that now has a black screen.
I will relate all issues related to this problem to this one, for people who are looking for an alternative fix, and to facilitate the work of closing issues when this one is closed. Thank you for reaching the solution quickly, I would spend a lot of time investigating this myself.

[matthew-carroll]

Access to the underlying FlutterSurfaceView is now facilitated by this change here:
flutter/engine#16552

The change won't be available on master until that engine change rolls into the framework.

Closing this issue as resolved. @mklim offered work around above until the fix rolls in.

[Aqluse]

++ to this issue
Was surprised when it suddenly stopped working for video capturing, while clearly working for other non-Flutter apps on the same device

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.