セキュリティ アナリストは、コード内のメモリ関連の脆弱性を軽減するために、ソフトウェア開発者が C#、Go、Java、Ruby、Rust、Swift などの言語の採用を検討するようにという先週の米国国家安全保障局 (NSA) の勧告を歓迎しました。
NSA は、これらをコンピューター言語の一部としてメモリを自動的に管理する「メモリ セーフ」言語と表現しました。 NSA によると、メモリ セキュリティの実装をプログラマに依存せず、代わりにコンパイル時チェックと実行時チェックを組み合わせてメモリ エラーから保護します。
メモリーセーフ言語のケース
NSA の 10 月 XNUMX 日のやや変わった勧告は、C や C++ などの広く使用されている言語を次のように指摘しています。 プログラマーに頼りすぎ メモリ関連の間違いを犯さないことは、ソフトウェアのセキュリティ脆弱性の最大の原因であり続けています。 以前の研究 - XNUMXつずつ 2019年のマイクロソフト もう1つは 2020年のGoogle たとえば、どちらも脆弱性の 70% がメモリの安全性の問題であることが判明したと、NSA は述べています。
NSA は、「C や C++ などの一般的に使用される言語は、メモリ管理に多くの自由と柔軟性を提供しますが、メモリ参照で必要なチェックを実行するためにプログラマーに大きく依存しています」と述べています。 これは、多くの場合、バッファ オーバーフロー エラー、メモリ割り当ての問題、競合状態などの単純なミスに関連する悪用可能な脆弱性をもたらします。
C#、Go、Java、Ruby、Rust、Swift、およびその他のメモリセーフな言語は、これらの問題のリスクを完全に排除するわけではないと、NSA は勧告で述べています。 たとえば、それらのほとんどには、メモリセーフではないクラスまたは関数が少なくともいくつか含まれており、プログラマが安全ではない可能性のあるメモリ管理機能を実行できるようになっています。 メモリセーフ言語には、安全でない可能性のあるメモリ関数を含む言語で記述されたライブラリが含まれる場合もあります。
しかし、これらの警告があっても、メモリセーフな言語は ソフトウェアの脆弱性を軽減するのに役立ちます NSA は、貧弱で不注意なメモリ管理が原因であると述べています。
Synopsys Cybersecurity Research Center のプリンシパル セキュリティ ストラテジストである Tim Mackey は、NSA の勧告を歓迎します。 実際、メモリセーフ言語の使用は、ほとんどのアプリケーションのデフォルトであるべきだと彼は言います。 「実際には、クールな新機能をプログラミングする代わりに、開発者がメモリ管理の問題に専念するように頼ることは、イノベーションに負担をかけることになります」と彼は言います。 Mackey 氏によると、メモリセーフなプログラミング言語と関連するフレームワークでは、アプリケーション開発者ではなく、適切なメモリ管理を保証するのは言語の作成者です。
シフトは困難な場合があります
NSA は、成熟したソフトウェア開発環境をある言語から別の言語に移行するのは難しい場合があることを認めています。 プログラマーは新しい言語を学習する必要があり、その過程で初心者のミスや効率の低下が生じる可能性があります。 使用可能なメモリ セキュリティの範囲も、言語によって大きく異なります。 最小限のメモリ セキュリティのみを提供するものもあれば、メモリ アクセス、割り当て、および管理に関してかなりの保護を提供するものもあります。
さらに、組織は、セキュリティとパフォーマンスの間でどの程度のトレードオフを喜んで行うかを検討する必要があります。 「メモリの安全性は、パフォーマンスと柔軟性にコストがかかる可能性があります」と NSA は警告しています。 「極端なレベルの固有の保護を備えた言語の場合、チェックと保護のために、プログラムをコンパイルするだけでかなりの作業が必要になる場合があります。」
Vulcan Cyber のシニア テクニカル エンジニアである Mike Parkin 氏は、ある言語から別の言語にアプリケーションを移植しようとすると、無数の変数が作用します。 「最良のシナリオでは、移行は単純であり、組織は比較的簡単に移行できます」と Parkin 氏は言います。 「他の言語では、アプリケーションは元の言語では些細な機能に依存していますが、新しい言語で再現するには大規模で費用のかかる開発が必要です。」
また、メモリセーフな言語を使用しても、適切なソフトウェア テストの必要性がなくなるわけではありません、と Mackey は警告します。 プログラミング言語がメモリセーフであるからといって、その言語で開発された言語やアプリケーションにバグがないわけではありません。
あるプログラミング言語から別のプログラミング言語に移行することは、古い言語と新しい言語の両方を既に理解しているスタッフがいない限り、危険な提案です、と Mackey は言います。 「このような移行は、アプリケーションがメジャー バージョンの更新を行っているときに行うのが最適です。 そうしないと、移行作業の一環として不注意でバグが発生する可能性があります」と彼は指摘します。
Mackey は、組織が言語の移行に関してマイクロサービスの使用を検討することを提案しています。 「マイクロサービス アーキテクチャでは、アプリケーションはコンテナ化された一連のサービスに分解されます」と Mackey 氏は言います。 「プログラミング言語の観点からは、各マイクロサービスが同じアプリケーション内の他のサービスと同じプログラミング言語でプログラミングされることを本質的に必要とするものは何もありません。」
動きを作る
Statista の最近のデータによると、 多くの開発者がすでに使用しています メモリセーフと見なされる言語。 たとえば、ほぼ 65.6 分の 48.06 (28%) が JavaScript を使用し、ほぼ半分 (22.5%) が Python を使用し、19.25 分の XNUMX が Java を使用し、ほぼ XNUMX% が C# を使用しています。 同時に、かなりの割合が、C++ (XNUMX%) や C (XNUMX%) などの安全でない言語をまだ使用しています。
SANS Technology Institute の研究部長である Johannes Ullrich 氏は、次のように述べています。 「しかし、今後何年にもわたって維持しなければならないレガシーコードベースは依然として存在するでしょう。」
NSA の勧告は、この時点でその勧告を促した可能性があるものについてほとんど洞察を提供しませんでした. しかし、Netenrich の主要な脅威ハンターである John Bambanek は、組織がそれを無視しないようにアドバイスしています。 「メモリの脆弱性と攻撃は 1990 年代から蔓延しているため、一般的に、これは良いアドバイスです」と彼は言います。 「そうは言っても、これはNSAからのものであるため、このアドバイスはさらに緊急を要するものであり、彼らが持っていて私たちが持っていない知識に基づいていると思います。」
