アナリストは、開発者がメモリセーフな言語を採用するための NSA のアドバイスを歓迎します

セキュリティ アナリストは、ソフトウェア開発者がコード内のメモリ関連の脆弱性を軽減する C#、Go、Java、Ruby、Rust、Swift などの言語の採用を検討するように、先週米国国家安全保障局 (NSA) から推奨されたことを歓迎しました。

NSA は、これらをコンピューター言語の一部としてメモリを自動的に管理する「メモリ セーフ」言語と表現しました。 NSA によると、メモリ セキュリティの実装をプログラマに依存せず、代わりにコンパイル時チェックと実行時チェックを組み合わせてメモリ エラーから保護します。

メモリーセーフ言語のケース

11 月 10 日の NSA のやや変わった勧告では、C や C++ などの広く使用されている言語は、メモリ関連の間違いを犯さないようにプログラマーに過度に依存していると指摘し、ソフトウェアのセキュリティ脆弱性の最大の原因であり続けていると指摘しました。 以前の調査 — 2019 年に Microsoft が 1 件、2020 年に Google が Chrome ブラウザに関連して別の調査を行った。 — NSA によると、脆弱性の 70% がメモリの安全性の問題であることがわかりました。

NSA は、「C や C++ などの一般的に使用される言語は、メモリ管理に多くの自由と柔軟性を提供しますが、メモリ参照で必要なチェックを実行するためにプログラマに大きく依存しています」と述べています。 これは、多くの場合、バッファ オーバーフロー エラー、メモリ割り当ての問題、競合状態などの単純なミスに関連する悪用可能な脆弱性をもたらします。

C#、Go、Java、Ruby、Rust、Swift、およびその他のメモリセーフな言語は、これらの問題のリスクを完全に排除するわけではないと、NSA は勧告で述べています。 たとえば、それらのほとんどには、メモリセーフではないクラスまたは関数が少なくともいくつか含まれており、プログラマが安全ではない可能性のあるメモリ管理機能を実行できるようになっています。 メモリセーフ言語には、潜在的に安全でないメモリ関数を含む言語で書かれたライブラリが含まれることもあります。

しかし、これらの注意事項があっても、メモリーセーフ言語は、貧弱で不注意なメモリー管理に起因するソフトウェアの脆弱性を軽減するのに役立つ可能性がある、と NSA は述べています。

Synopsys Cyber​​security Research Center のプリンシパル セキュリティ ストラテジストである Tim Mackey は、NSA の勧告を歓迎します。 実際、メモリーセーフな言語の使用は、ほとんどのアプリケーションのデフォルトであるべきだと彼は言います。

「実用的な目的では、クールな新機能をプログラミングするのではなく、開発者がメモリ管理の問題に集中することに依存することは、イノベーションへの負担となります」と彼は言います。

メモリセーフなプログラミング言語と関連するフレームワークでは、適切なメモリ管理を保証するのは言語の作成者であり、アプリケーション開発者ではない、と Mackey は言います。

シフトは困難な場合があります

NSA は、成熟したソフトウェア開発環境をある言語から別の言語に移行するのは難しい場合があることを認めています。 プログラマーは新しい言語を学習する必要があり、その過程で初心者のミスや効率の低下が生じる可能性があります。 使用可能なメモリ セキュリティの範囲も、言語によって大きく異なります。 最小限のメモリ セキュリティのみを提供するものもあれば、メモリ アクセス、割り当て、および管理に関してかなりの保護を提供するものもあります。

さらに、組織は、セキュリティとパフォーマンスの間でどの程度のトレードオフを喜んで行うかを検討する必要があります。 「メモリの安全性は、パフォーマンスと柔軟性にコストがかかる可能性があります」と NSA は警告しています。 「極端なレベルの固有の保護を備えた言語の場合、チェックと保護のために、プログラムをコンパイルするだけでかなりの作業が必要になる場合があります。」

Vulcan Cyber​​ のシニア テクニカル エンジニアである Mike Parkin 氏は、ある言語から別の言語にアプリケーションを移植しようとすると、無数の変数が作用します。

「最良のシナリオでは、移行は単純であり、組織は比較的苦労せずにそれを達成できます」と Parkin 氏は言います。 「他の言語では、アプリケーションは元の言語では些細な機能に依存していますが、新しい言語で再作成するには大規模で費用のかかる開発が必要です。」

また、メモリセーフな言語を使用しても、適切なソフトウェア テストの必要性がなくなるわけではありません、と Mackey は警告します。 プログラミング言語がメモリセーフであるからといって、その言語で開発された言語やアプリケーションにバグがないわけではありません。

あるプログラミング言語から別のプログラミング言語に移行することは、古い言語と新しい言語の両方を既に理解しているスタッフがいない限り、危険な提案です、と Mackey は言います。

「このような移行は、アプリケーションがメジャー バージョンの更新を行っているときに行うのが最適です。」と彼は指摘します。 「そうしないと、移行作業の一環として不注意でバグが発生する可能性があります。」

Mackey は、組織が言語の移行に関してマイクロサービスの使用を検討することを提案しています。

「マイクロサービス アーキテクチャでは、アプリケーションはコンテナ化された一連のサービスに分解されます」と Mackey 氏は言います。 「プログラミング言語の観点からは、各マイクロサービスが同じアプリケーション内の他のサービスと同じプログラミング言語でプログラミングされることを本質的に必要とするものは何もありません。」

行動を起こす

Statista の最近のデータによると、多くの開発者が既にメモリセーフと見なされる言語を使用しています。 たとえば、n初期の 3 分の 2 (65.6%) が JavaScript を使用し、半分近く (48.06%) が Python を使用し、3 分の 1 が Java を使用し、28% 近くが C# を使用しています。 同時に、かなりの割合が、C++ (22.5%) や C (19.25%) などの安全でない言語をまだ使用しています。

SANS Technology Institute の研究部長である Johannes Ullrich 氏は、次のように述べています。 「しかし、今後何年にもわたって維持しなければならないレガシーコードベースはまだ存在するでしょう。」

NSA の勧告は、この時点でその勧告を促した可能性があるものについてほとんど洞察を提供しませんでした. しかし、Netenrich の主要な脅威ハンターである John Bambanek は、組織にそれを無視しないようにアドバイスしています。

「メモリの脆弱性と攻撃は 1990 年代から蔓延しているため、一般的に、これは良いアドバイスです」と彼は言います。 「そうは言っても、これはNSAからのものであるため、このアドバイスはさらに緊急性が必要であり、彼らが持っていて私たちが持っていない知識に基づいていると思います。」

Leave a Comment

Your email address will not be published. Required fields are marked *