しかし、これを気にする開発者はほとんどいません。
1つのバグはiPhoneに影響を及ぼし、もう1つはWindowsに、もう1つはLinuxで実行されているサーバーに影響します。 これらのバグは、Android、iOS、macOS、Windows、Linuxなどの異なるプラットフォームに関連しているため、一見したところ共通点はありません。 ただし、実際にはすべてが異なります。Mozillaのソフトウェアセキュリティエンジニアで、以前USDS（United States Digital Service）で働いていたAlex Gaynor氏によると。
[1]
Motherboard Viceが主催する毎年恒例のイベントである3番目のWeakest Linkでは、
将来のコンピューターハッキングとサイバーセキュリティのトピックに関して、Alex Gaynorは深刻な問題を提起しました。彼の意見では、インターネットを脅かす可能性がありますが、逆説的に、開発者は完全に無関心です。
Gaynorは、前述の3つのエラーが存在することを説明しました。異なるプラットフォームに影響を与えるソフトウェアは、「メモリの安全性」などのエラーを引き起こし、未割り当てのメモリ領域へのアクセスを許可するプログラミング言語を使用して作成されたためです。
[3]
ほとんどの場合、5つの要素で構成される配列の6番目の要素を参照することは許可されますが、「安全」な他のプログラミング言語では、少なくともエラーメッセージが表示されます。
このカテゴリのエラーは、メモリへのアクセス中にバグやセキュリティの脆弱性を引き起こす可能性があります。
「メモリの安全性」などのエラーが発生することを許可することにより、CやC ++などのプログラミング言語は、何年にもわたって重大なセキュリティ脆弱性のほぼ無限のストリームを広めることができます。 これらの脆弱性の例は次のとおりです。
- タイプの不一致
- バッファオーバーフロー
- 整数変数のオーバーフロー
- 解放後の脆弱性を使用する
コードの一部が渡されたオブジェクトのタイプをチェックせず、盲目的に使用すると、タイプの不一致が発生する可能性があります。 この状況は危険です。 さらに、型の不一致とともに、不正な関数ポインターまたは不正なデータがコードの誤った部分に関連付けられ、場合によっては実行につながる可能性があります。
バッファオーバーフロー（または英語の「バッファオーバーフロー」）は、サイズが不十分な文字の配列に含まれる文字列をユーザーが入力したときに発生する重大なセキュリティ上の脆弱性です。 これにより、配列に割り当てられたメモリの外部にデータが書き込まれます。 たとえば、インターネット上のセキュリティで保護されたサーバーの17％に影響を与えたHeartBleedは、パスワードやその他のユーザーデータを含め、リストの最後から60 KBを読み取ることができるバッファオーバーフローの脆弱性でした。
整数オーバーフローは、数値が特定の値を超えることができないという事実を悪用する脆弱性を検出するのが困難です。特定の値は、数値の表現に使用されるビット数とエンコード方法によって異なります。
「use after free」の脆弱性は、通常、メモリ内のポインタまたはデータを使用する場合、ポインタ（またはメモリブロック）がすでに解放されている場合に発生します。
合わせて、これらの脆弱性は、Firefox、Chrome、Windows、Android、iOSなどの一般的なソフトウェアで最もよく見られるエクスプロイトです。 ゲイナーはすでに少なくとも400を数え、「これらのプロジェクトのセキュリティを1年以上監視しています。これらの製品のほとんどすべてのバージョンでは、脆弱性の半分以上がメモリの安全性に欠けています。 さらに深刻なのは、深刻で重大な脆弱性[...]がほぼ常にこのタイプであるということです。
サポートするソフトウェアのセキュリティに関連する重大なリスクにもかかわらず、開発者はCやC ++などのメモリの安全性にやさしいプログラミング言語を引き続き使用していますが、RustやSwiftなどの実証済みの代替手段も検討できます。言語として「メモリセーフ」はまれです。
これは、新しいプロジェクトでは、開発者は原則として、チームが知っている言語、パフォーマンス、およびこの選択から流れることができるライブラリシステムに基づいてプログラミング言語を選択するという事実による可能性があります。 ゲイナー氏によると、意思決定において、これに関連する安全性要素はほとんど考慮されないか、少なくとも十分に考慮されていません。
さらに、ほとんどのソフトウェアプロジェクトは、インターネットセキュリティにとって最も重要なプロジェクトであっても、新しいものではありません。 10年前に発売されました。 たとえば、Linux、OpenSSL、およびApache Webサーバーは20年以上前のものです。 これらのような大規模プロジェクトの場合、すべてのコードを新しい言語で書き直すことは選択肢ではありません。 これらは徐々に変換する必要があります。つまり、プロジェクトは1つの言語ではなく2つの異なる言語で記述および保存する必要があります。 また、大規模なチームを編成する必要があることを意味します。これには多くの時間がかかり、より多くのお金が必要です。
最後に、最大の問題は、多くの開発者が一般に問題が存在すると信じていないことです。 彼らは、問題はCやC ++などの言語が脆弱性に寄与することではなく、エラーのあるコードを書く他のプログラマーだと考えています。 彼らは、これらの「メモリに安全でない」と思われる言語には問題がないと信じています。なぜなら、完璧なコードはなく、人々はそれらの使い方を知らないからです。
これについてどう思いますか？
翻訳に対する健全な批判も歓迎します。
ご清聴ありがとうございました！