メモリ安全性の問題に起因するAndroidの脆弱性の割合は、2019年の76％から2024年にはわずか24％に低下しており、5年間で68％以上の大幅な減少を示している。
これは、以前Chromiumで見られた70％をはるかに下回るもので、Androidは、大規模プロジェクトが後方互換性を壊すことなく、安全な領域へと徐々に、そして計画的に移行できることを示す優れた例となっている。
グーグルは、新しいコードをRustのようなメモリ・セーフ言語で書くことを優先し、時間とともに新たな欠陥が生じるのを最小限に抑えることで、この結果を達成したと述べている。
同時に、古いコードは、相互運用性を損なうような大規模な書き換えを行うのではなく、重要なセキュリティ修正に焦点を当てた最小限の変更で維持された。
「私たちが学んだことに基づいて、私たちは既存のメモリ安全でないコードをすべて捨てたり書き直したりする必要はないことが明らかになりました」とグーグルの報告書は述べている。
「その代わりに、Androidはメモリ安全性の旅における主要な機能として、相互運用性を安全かつ便利にすることに注力しています」。
ソースはこちら：グーグル
この戦略により、古いコードは成熟し、時間の経過とともに安全になり、どの言語で書かれたかに関係なく、メモリ関連の脆弱性の数を減らすことができる。
アンドロイドの構築戦略におけるこれら2つの柱は、世界で最も広く使われているモバイルプラットフォームにおけるメモリ欠陥の劇的な減少に向けて、相乗効果をもたらした。
グーグルは、古いコードを基本的に変更せず、新しいコードはよりよくテストされ、レビューされることが期待されるが、一見直感に反するように見えるかもしれないが、逆のことが起きていると説明している。
なぜなら、最近のコード変更によってほとんどの欠陥が導入されたため、新しいコードにはほとんど常にセキュリティ上の問題が含まれているからだ。同時に、古いコードにあるバグは、開発者が大規模な変更を加えない限り、鉄のように取り除かれる。
出典：Google：グーグル
グーグルによれば、自社を含む業界は、メモリ安全性の欠陥に対処するために、主に以下の4つの段階を経てきたという：
- リアクティブ・パッチ：当初は、脆弱性が発見された後の修正に焦点が当てられていた。このアプローチでは、頻繁なアップデートが必要となり、その間もユーザーは脆弱性を抱えたままとなるため、継続的なコストが発生した。
- プロアクティブな緩和策：次のステップは、エクスプロイトを困難にする戦略（スタック・カナリア、コントロール・フロー・インテグリティなど）を実装することだった。しかし、これらの対策はしばしばパフォーマンスとトレードオフになり、攻撃者とのいたちごっこになってしまう。
- プロアクティブな脆弱性の発見：この世代では、ファジングやサニタイザーのようなツールを使って、プロアクティブに脆弱性を発見していた。有用ではあるが、この方法は症状に対処するだけであり、常に注意を払い、努力する必要があった。
- 高保証の予防（セーフ・コーディング）：最新のアプローチでは、Rustのようなメモリ・セーフ言語を使用することで、脆弱性をソースから防ぐことを重視している。この「セキュア・バイ・デザイン」方式は、スケーラブルかつ長期的な保証を提供し、事後的な修正とコストのかかる緩和策のサイクルを断ち切る。
Googleは、「業界全体の製品は、これらのアプローチによって大幅に強化されており、脆弱性への対応、緩和、積極的な探索に引き続き取り組んでいます」と説明している。
「とはいえ、こうしたアプローチは、メモリ安全性の領域で許容可能なリスクレベルに達するには不十分であるだけでなく、開発者、ユーザー、企業、製品に継続的かつ増大するコストをもたらすことがますます明らかになってきています。
「CISAを含む多くの政府機関がセキュア・バイ・デザインの報告書で強調しているように、「セキュア・バイ・デザインの実践を取り入れることによってのみ、絶えず修正プログラムを作成し、適用するという悪循環を断ち切ることができる」。
昨年6月、米サイバーセキュリティ・インフラ・セキュリティ局（CISA）は、最も広く利用されているオープンソースプロジェクトの52％がメモリ非安全言語を使用していると警告した。
メモリ・セーフ言語で書かれたプロジェクトでさえ、メモリ・アンセーフ言語で書かれたコンポーネントに依存していることが多いため、セキュリティ・リスクへの対応は複雑だ。
CISAは、ソフトウェア開発者が新しいコードをRust、Java、GOなどのメモリ・セーフ言語で記述し、既存のプロジェクト、特に重要なコンポーネントをそれらの言語に移行することを推奨した。
Comments