セキュリティの誤検知
- 序章
- よくある懸念事項
- 共有オブジェクトは強化された機能を使用する必要があります
- 共有オブジェクトでは RELRO を使用する必要があります
- 共有オブジェクトはスタックカナリア値を使用する必要があります
- コードでは、_sscanf、_strlen、および _fopen API の使用を避ける必要があります。
- コードではメモリ割り当てに (_malloc ではなく) calloc を使用する必要があります。
- iOS バイナリには Runpath 検索パス (@rpath) が設定されています
- PKCS5/PKCS7 パディングの脆弱性を伴う CBC
- アプリは外部ストレージの読み取りと書き込みが可能
- アプリは file.delete() を使用してデータを削除します
- 時代遅れの懸念
- 本当の懸念を報告する
序章
セキュリティに関する誤った報告を受けることがあります Dart および Flutter アプリケーションの脆弱性、 他の種類用に構築されたツールによって生成される アプリケーション (たとえば、Java または C++ で作成されたアプリケーション)。 この文書は、私たちが信じているレポートに関する情報を提供します。 は間違っており、懸念が見当違いである理由を説明します。
よくある懸念事項
共有オブジェクトは強化された機能を使用する必要があります
共有オブジェクトには強化された機能はありません。 強化された関数は、glibc の一般的な安全でない関数に対するバッファ オーバーフロー チェックを提供します。
strcpy、gets等 コンパイラオプションを使用する-D_FORTIFY_SOURCE=2機能を強化するため。
これがコンパイル済みの Dart コードを指す場合
(例えば、libapp.soFlutter アプリケーション内のファイル)、
Dart コードはそうではないため、このアドバイスは間違っています。
libc 関数を直接呼び出します。
すべての Dart コードは Dart 標準ライブラリを通過します。
(一般的に、MobSF はここで誤検知を受けます。
関数の使用をチェックします。_chkサフィックス、
ただし、Dart ではこれらの機能はまったく使用されないため、
サフィックスの有無にかかわらず呼び出しはありません。
したがって、MobSF はコードを次のものとして扱います。
強化されていない通話。)
共有オブジェクトでは RELRO を使用する必要があります
RELRO が見つかりませんでした
libapp.soバイナリ
Dart は通常のプロシージャ リンケージ テーブルを使用しません (PLT) または Global Offsets Table (GOT) メカニズムはすべて、 そのため、読み取り専用再配置 (RELRO) 技術は使用されません。 Dartにとっては非常に理にかなっています。
Dart の GOT に相当するのはプール ポインターです。 GOT とは異なり、ランダムな場所に配置されます。 したがって、悪用するのははるかに困難です。
原則として、Dart FFI を使用すると脆弱なコードを作成できます。 ただし、Dart FFI を通常に使用する場合も、これらの問題は発生しません。 それ自体が RELRO を適切に使用する C コードで使用されることを前提としています。
共有オブジェクトはスタックカナリア値を使用する必要があります
カナリアが見つかりません
libapp.soバイナリ
この共有オブジェクトには、スタックに追加されたスタック カナリア値がありません。 スタック カナリアは、エクスプロイトによるリターン アドレスの上書きを検出し、防止するために使用されます。 スタック カナリアを有効にするには、オプション -fstack-protector-all を使用します。
Dart はスタック カナリアを生成しません。 C++ とは異なり、Dart にはスタック割り当て配列がありません。 (C/C++ におけるスタック破壊の主な原因)。
純粋なDartを書く場合（を使用せずに）dart:ffi）、
はるかに強力な分離保証がすでにあります
C++ のどの軽減策でも提供できるものよりも、
純粋な Dart コードがマネージ言語であるという理由だけで
バッファオーバーランなどは存在しません。
原則として、Dart FFI を使用すると脆弱なコードを作成できます。 ただし、Dart FFI を通常に使用する場合も、これらの問題は発生しません。 それ自体がスタック カナリア値を使用する C コードで使用されると仮定します。 適当に。
コードでは、_sscanf、_strlen、 と_fopenAPI
バイナリには次の安全でない API が含まれている可能性があります
_sscanf、_strlen、_fopen。
これらの問題を報告するツールは次のような傾向があります。 スキャンが単純すぎる。 たとえば、カスタム関数を見つけるには、 これらの名前は、 標準ライブラリ関数。 Flutter のサードパーティ依存関係の多くは、 これらのチェックをトリップする同様の名前の関数。 いくつかの出来事は正当な懸念である可能性がありますが、 しかし、これらのツールの出力からそれを判断することは不可能です 誤検知が膨大にあるためです。
コードは使用する必要がありますcalloc（それ以外の_malloc) メモリ割り当て用
バイナリは使用できます
_mallocの代わりに関数calloc。
メモリ割り当ては微妙なトピックですが、
パフォーマンスとのトレードオフが必要な場合
そして脆弱性に対する回復力。
単に使用するだけmalloc自動的に示されるものではありません
セキュリティ上の脆弱性のこと。
具体的な報告は歓迎しますが（以下を参照）
を使用する場合calloc望ましいでしょう、
実際には一律に行うのは不適切であろう
全部交換するmallocとの通話calloc。
iOS バイナリには Runpath 検索パス (@rpath） 設定
バイナリには Runpath 検索パス (
@rpath） 設定。 場合によっては、攻撃者がこの機能を悪用して、コードの実行や権限昇格のために任意の実行可能ファイルを実行する可能性があります。 コンパイラオプションを削除する-rpath削除する@rpath。
アプリの構築時に、Runpath Search Path が参照します。
リンカーが動的ライブラリを見つけるために検索するパスへ
(dylibs) アプリによって使用されます。
デフォルトでは、iOS アプリではこれが次のように設定されています。@executable_path/Frameworks、
これは、リンカーが dylib を検索する必要があることを意味します
の中にFrameworksアプリからの相対ディレクトリ
アプリバンドル内のバイナリ。
のFlutter.frameworkエンジン、
ほとんどの組み込みフレームワークや dylib と同様、
はこのディレクトリに正しくコピーされます。
アプリが実行されると、ライブラリ バイナリがロードされます。
Flutter アプリはデフォルトの iOS ビルド設定を使用します
(LD_RUNPATH_SEARCH_PATHS=@executable_path/Frameworks）。
に関係する脆弱性@rpath適用しないでください
攻撃者が持っていないモバイル設定では
ファイルシステムにアクセスすることはできず、任意にアクセスすることはできません
これらのフレームワークを交換します。
たとえ攻撃者が何らかの形でできる交換してください
悪意のあるフレームワーク、
共同設計違反により、アプリが起動時にクラッシュする可能性がありました。
PKCS5/PKCS7 パディングの脆弱性を伴う CBC
があるという曖昧な報告を受けています。 「PKCS5/PKCS7 パディングの脆弱性を伴う CBC」 一部の Flutter パッケージでは。
私たちが知る限り、これは HLS によってトリガーされます。
ExoPlayer での実装
(com.google.android.exoplayer2.source.hls.Aes128DataSourceクラス）。
HLS は Apple のストリーミング形式です。
DRM に使用する必要がある暗号化のタイプを定義します。
これは脆弱性ではありませんが、
DRM はユーザーのマシンやデータを保護しないため
代わりに難読化を提供するだけです
ユーザーがソフトウェアとハードウェアを完全に使用する能力を制限するため。
アプリは外部ストレージの読み取りと書き込みが可能
アプリは外部ストレージへの読み取り/書き込みが可能です。どのアプリでも外部ストレージに書き込まれたデータを読み取ることができます。
信頼できないソースからのデータと同様に、外部ストレージからのデータを処理するときは入力検証を実行する必要があります。 動的ロードの前に、実行可能ファイルやクラス ファイルを外部ストレージに保存しないことを強くお勧めします。 アプリが外部ストレージから実行可能ファイルを取得する場合、 ファイルは、動的ロードの前に署名され、暗号的に検証される必要があります。
いくつかの脆弱性があるという報告を受けています スキャン ツールは画像の機能を解釈します ピッカー プラグインを脅威として外部ストレージに読み書きします。
ローカル ストレージから画像を読み取ることが、これらのプラグインの目的です。 これは脆弱性ではありません。
アプリは file.delete() を使用してデータを削除します
fileを使用してファイルを削除する場合。 delete の場合、ファイルへの参照のみがファイル システム テーブルから削除されます。 ファイルは、他のデータによって上書きされるまでディスク上に存在し、回復することができなくなります。
一部の脆弱性スキャン ツールは、 カメラプラグインがデータを記録した後の一時ファイル デバイスのカメラにセキュリティ上の脆弱性がある可能性があります。 動画はユーザーが録画して保存しているため ユーザーのハードウェア上では実際のリスクはありません。
時代遅れの懸念
このセクションには、次の場合に表示される可能性のある有効なメッセージが含まれています。 Dart と Flutter の古いバージョンですが、今後は使用できなくなります より新しいバージョンで表示されます。 Dart または Flutter の古いバージョンでこれらのメッセージが表示される場合は、 最新の安定バージョンにアップグレードします。 現在の安定バージョンでこれらが表示される場合は、 報告してください (この文書の最後のセクションを参照)。
スタックにはNXビットが設定されている必要があります
共有オブジェクトには NX ビットが設定されていません。 NX ビットは、メモリ ページを実行不可能としてマークすることで、メモリ破損の脆弱性悪用に対する保護を提供します。 オプションを使用する
--noexecstackまた-z noexecstackスタックを実行不可能としてマークします。
(MobSF からのメッセージは誤解を招きます。 スタックが実行不可能としてマークされているかどうか、 共有オブジェクトではありません。)
Dart と Flutter の古いバージョンにはバグがありました
ELF ジェネレーターがgnustackでセグメント化します~X許可されていますが、これは現在修正されています。
本当の懸念を報告する
自動化された脆弱性スキャン ツールがレポートする間 上記の例のような誤検知、 現実的な問題がある可能性を排除することはできません もっと注目に値する。 問題があると思われる問題が見つかった場合は、 合法的なセキュリティ脆弱性がある場合、私たちは大いに喜んでいます ご報告いただければ幸いです:
- Flutter セキュリティ ポリシー
- Dartのセキュリティポリシー