Security false positives

We occasionally receive false reports of security vulnerabilities in Dart and Flutter applications, generated by tools that were built for other kinds of applications (for example, those written with Java or C++). This document provides information on reports that we believe are incorrect and explains why the concerns are misplaced.

The shared object does not have any fortified functions. Fortified functions provides buffer overflow checks against glibc's commons insecure functions like strcpy, gets etc. Use the compiler option -D_FORTIFY_SOURCE=2 to fortify functions.

When this refers to compiled Dart code (such as the libapp.so file in Flutter applications), this advice is misguided because Dart code doesn't directly invoke libc functions; all Dart code goes through the Dart standard library.

(In general, MobSF gets false positives here because it checks for any use of functions with a _chk suffix, but since Dart doesn't use these functions at all, it doesn't have calls with or without the suffix, and therefore MobSF treats the code as containing non-fortified calls.)

no RELRO found for libapp.so binaries

Dart doesn't use the normal Procedure Linkage Table (PLT) or Global Offsets Table (GOT) mechanisms at all, so the Relocation Read-Only (RELRO) technique doesn't really make much sense for Dart.

Dart's equivalent of GOT is the pool pointer, which unlike GOT, is located in a randomized location and is therefore much harder to exploit.

In principle, you can create vulnerable code when using Dart FFI, but normal use of Dart FFI wouldn't be prone to these issues either, assuming it's used with C code that itself uses RELRO appropriately.

no canary are found for libapp.so binaries

This shared object does not have a stack canary value added to the stack. Stack canaries are used to detect and prevent exploits from overwriting return address. Use the option -fstack-protector-all to enable stack canaries.

Dart doesn't generate stack canaries because, unlike C++, Dart doesn't have stack-allocated arrays (the primary source of stack smashing in C/C++).

When writing pure Dart (without using dart:ffi), you already have much stronger isolation guarantees than any C++ mitigation can provide, simply because pure Dart code is a managed language where things like buffer overruns don't exist.

In principle, you can create vulnerable code when using Dart FFI, but normal use of Dart FFI would not be prone to these issues either, assuming it's used with C code that itself uses stack canary values appropriately.

The binary may contain the following insecure API(s) _sscanf , _strlen , _fopen.

The tools that report these issues tend to be overly-simplistic in their scans; for example, finding custom functions with these names and assuming they refer to the standard library functions. Many of Flutter's third-party dependencies have functions with similar names that trip these checks. It's possible that some occurrences are valid concerns, but it's impossible to tell from the output of these tools due to the sheer number of false positives.

The binary may use _malloc function instead of calloc.

Memory allocation is a nuanced topic, where trade-offs have to be made between performance and resilience to vulnerabilities. Merely using malloc is not automatically indicative of a security vulnerability. While we welcome concrete reports (see below) for cases where using calloc would be preferable, in practice it would be inappropriate to uniformly replace all malloc calls with calloc.

The binary has Runpath Search Path (@rpath) set. In certain cases an attacker can abuse this feature to run arbitrary executable for code execution and privilege escalation. Remove the compiler option -rpath to remove @rpath.

When the app is being built, Runpath Search Path refers to the paths the linker searches to find dynamic libraries (dylibs) used by the app. By default, iOS apps have this set to @executable_path/Frameworks, which means the linker should search for dylibs in the Frameworks directory relative to the app binary inside the app bundle. The Flutter.framework engine, like most embedded frameworks or dylibs, is correctly copied into this directory. When the app runs, it loads the library binary.

Flutter apps use the default iOS build setting (LD_RUNPATH_SEARCH_PATHS=@executable_path/Frameworks).

Vulnerabilities involving @rpath don't apply in mobile settings, as attackers don't have access to the file system and can't arbitrarily swap out these frameworks. Even if an attacker somehow could swap out the framework with a malicious one, the app would crash on launch due to codesigning violations.

We have received vague reports that there is a "CBC with PKCS5/PKCS7 padding vulnerability" in some Flutter packages.

As far as we can tell, this is triggered by the HLS implementation in ExoPlayer (the com.google.android.exoplayer2.source.hls.Aes128DataSource class). HLS is Apple's streaming format, which defines the type of encryption that must be used for DRM; this isn't a vulnerability, as DRM doesn't protect the user's machine or data but instead merely provides obfuscation to limit the user's ability to fully use their software and hardware.

App can read/write to External Storage. Any App can read data written to External Storage.

As with data from any untrusted source, you should perform input validation when handling data from external storage. We strongly recommend that you not store executables or class files on external storage prior to dynamic loading. If your app does retrieve executable files from external storage, the files should be signed and cryptographically verified prior to dynamic loading.

We have received reports that some vulnerability scanning tools interpret the ability for image picker plugins to read and write to external storage as a threat.

Reading images from local storage is the purpose of these plugins; this is not a vulnerability.

When you delete a file using file. delete, only the reference to the file is removed from the file system table. The file still exists on disk until other data overwrites it, leaving it vulnerable to recovery.

Some vulnerability scanning tools interpret the deletion of temporary files after a camera plugin records data from the device's camera as a security vulnerability. Because the video is recorded by the user and is stored on the user's hardware, there is no actual risk.

This section contains valid messages that might be seen with older versions of Dart and Flutter, but should no longer be seen with more recent versions. If you see these messages with old versions of Dart or Flutter, upgrade to the latest stable version. If you see these with the current stable version, please report them (see the section at the end of this document).

The shared object does not have NX bit set. NX bit offer protection against exploitation of memory corruption vulnerabilities by marking memory page as non-executable. Use option --noexecstack or -z noexecstack to mark stack as non executable.

(The message from MobSF is misleading; it's looking for whether the stack is marked as non-executable, not the shared object.)

In older versions of Dart and Flutter there was a bug where the ELF generator didn't emit the gnustack segment with the ~X permission, but this is now fixed.

While automated vulnerability scanning tools report false positives such as the examples above, we can't rule out that there are real issues that deserve closer attention. Should you find an issue that you believe is a legitimate security vulnerability, we would greatly appreciate if you would report it:

• Flutter security policy
• Dart security policy