Rustは5年連続で最も愛されているプログラミング言語です。これは私たちの新しいセキュリティの救世主となるのでしょうか？

For the past few years, it seems that software engineers all over the world just can't get enough of Rust for programming. This relatively new systems programming language, produced by Mozilla, has captured the hearts of the Stack Overflow community - and, as a cohort very unlikely to suffer fools, when they vote something the "most loved programming language" five years in a row, it's time we all sat up and took notice.

Rustは、広く使われている言語の機能的要素を取り入れつつ、複雑さを排除し、パフォーマンスと安全性を両立させるという独自の哲学に基づいています。学習曲線は存在し、多くの開発者がまだ十分に触れる機会を得られていないのが現状です（Stack Overflowの調査では、日常的に使用しているのはわずか5.1%でした）。しかし、それを差し引いても、Rustが刺激的な言語であることは否定できません。CやC++といった先行言語よりもはるかに強力なセキュリティを備えています。普及には行動面と技術面の両方で変化が必要ですが、現時点でも理論的な レベルで開発者の注目を集め続けています。

しかし、もう一つ重要な点に触れておく必要があります。Rustはメモリ安全性と、一般的なメモリ管理の問題に起因するセキュリティバグの根絶を優先するプログラミング言語であるということです。これらは非常に大きな問題であり、AppSecチームを悩ませる種であることは間違いありませんが、私たちが直面しているセキュアコーディングの課題はそれだけではありません。

Rustは具体的に何を防ぐのでしょうか？そして、セキュリティの観点から見て、私たちはまだどのようなリスクにさらされているのでしょうか？この最新の「プログラミングのユニコーン」について紐解いていきましょう。

モダンでメモリ安全なシステムプログラミングの新たなフロンティア

Mozillaの研究開発チームはこれまで数々の素晴らしいプロジェクトを手がけてきましたが、オープンソースの先駆者としてRustプログラミングに投資したこともその一つです。彼らの紹介ビデオからはその理念がうかがえます。そこでは「現在のソフトウェアセキュリティへのアプローチには欠陥があり、Rustはその問題の多くを解決するために設計されている」という重要なテーマが明確に示されています。

It seems too simplistic, especially since we face enormous data breaches every other day - just like the recent horrific blunder reported by EasyJet. Millions of data records are compromised frequently, almost always the work of a web application vulnerability, security misconfiguration, or phishing attack, and languages like C++ have existed for decades. However, this has not been enough time for developers to master them to the point of implementing secure coding best practices. Why should Rust be any different? New languages have come out before, and it's not like they've found a way to eradicate common vulnerabilities, or ensure any code written is magically perfect when compiled.

概念はシンプルかもしれませんが、複雑な問いに対してはシンプルな答えこそが解決策となることがあります。Rustは、あらゆる意味でメモリ安全なシステムプログラミングにおける革命であり、その約束を多くの面で果たしています。また、検出されれば大きな問題につながるようなエラーを犯しやすい開発者にとって、まさに救世主となる存在です。Java、C、C++、そしてKotlinやGolangのような比較的新しい言語でさえ、セキュリティ意識の低い開発者に対してはかなり容赦がありません。それらの言語には組み込みの警告がなく、コンパイルしたばかりの素晴らしい機能の裏側にセキュリティ上の欠陥が潜んでいても、それを知らせる兆候は特にないのです。

それでは、さらに深く掘り下げてみましょう。

Rustがこれほどまでに安全な理由とは？

通常、開発者の主な目標は、機能的で使いやすい機能を構築することであり、履歴書に載せて自慢できるような成果を出すことかもしれません。開発者が素晴らしいソフトウェアを作成し、リリースして次の大きなプロジェクトに移ることはごく一般的です。その段階でセキュリティチームが脆弱性をチェックし、もし見つかれば「完成した」はずのアプリケーションが修正のためにチームへ差し戻されることになります。その問題は単純なものかもしれませんし、開発者が修正するには手に負えないほど複雑なものかもしれません。

問題は、表面上はセキュリティバグが全く見当たらないことです。スキャンやテスト、手動のコードレビューで見逃されてしまえば、攻撃者はそのわずかな隙を突いてバグを悪用する可能性があります。

Rustは、多くの脆弱性がコードに混入するのを未然に防ぐことを目指しています。構文エラーや、SDLC全体を通じて本番環境での問題を引き起こすようなメモリ安全性のバグがある場合、そもそもコンパイルが通りません。これは設計段階からメモリ安全性を考慮したプログラミングであり、ソフトウェアがどのように実行されても無効なメモリへのアクセスが発生しないことを保証します。そして、セキュリティバグの70%がメモリ管理に関連する問題であることを考えると、これは素晴らしい成果です。

Rustは以下の問題を検知し、防ぎます：

• バッファオーバーフロー
• Use-after-free（解放後使用）
• ダブルフリー
• Nullポインタ参照
• 初期化されていないメモリの使用

RustのコードスニペットとC++を比較すれば、どちらがデフォルトで安全であるかは一目瞭然です。バッファオーバーフローのバグの例を見てみましょう。

#include <iostream></iostream>
#include <string.h></string.h>
int main( void ) {
char a[3] = "12";
char b[4]= "123";
strcpy(a, b); // bの長さがaより大きいためバッファオーバーフローが発生
std::cout << a << "; " << b << std::endl;
}

対

pub fn main() {
let mut a: [char; 2] = [1, 2];
let b: [char; 3] = [1, 2, 3];
a.copy_from_slice(&b);
}

Rustはセキュリティ警告を出し、実行時にcopy_from_slice関数に到達するとバッファオーバーフローを防ぐためにパニックを起こしますが、コンパイル時には検知されません。

その意味で、Rustは非常に「左から始める（start left）」言語と言えます。エラーを強調し、メモリ関連のセキュリティバグを混入させないための正しいコードの書き方を開発者に強制的に教え込むため、納期を守れるかどうかは、コーダーが注意を払い、修正を行い、デリバリーの道筋を忠実に守れるかにかかっています。

この言語のアプローチはシンプルに見えますが、これほど強力なロジックを実現するのは並大抵のことではありません。Rustはセキュリティの観点から見て大きな飛躍を遂げています。もっと多くの人が使っていればの話ですが。Dropboxのような企業が大規模な企業レベルで導入を先導しているのは素晴らしいことです。しかし、導入さえ進めばより安全な未来が訪れると結論付ける前に、考慮すべき点がまだあります。

Rustの真価を問う

いくつか小さな（いや、大きな）問題があります。それは、Rustでのプログラミングには、見かけ以上にバグを混入させる余地があるということです。Rustは、侵害や遅延、そして安全でないコーディング手法の蔓延を引き起こし続けている、極めて重要な「OWASP Top 10」の脆弱性をすべて修正してくれるわけではありません。また、天使と悪魔のような力学、あるいはより一般的に知られている次のような側面もあります：Safe RustとUnsafe Rust。
‍

公式ドキュメントで説明されているように、公式ドキュメントSafe RustはRustの「真の」姿であり、Unsafe Rustには「安全とは言い切れない」と見なされる関数が含まれています。これらは、他の言語との統合が必要な場合など、時には必要となります。しかし、Unsafe Rustであっても、追加機能のリストは限定的です。Unsafe Rustでは、unsafeブロック内で以下のことが可能です：

• 生ポインタの逆参照
• unsafe関数の呼び出し（C関数、コンパイラの組み込み関数、生アロケータを含む）
• unsafeトレイトの実装
• static変数の変更
• 共用体（union）のフィールドへのアクセス

いわゆる「unsafe」モードであっても、Rustプログラミングの強力な武器である「借用チェッカー」は機能し続けます。これは一般的に、静的コード解析を通じてメモリ問題や並列計算時の競合、その他多くのバグを防ぎます。この解析はunsafeブロック内でもチェックを行うため、コンパイラのガイダンスなしでunsafeな構造を記述するには、より多くの労力が必要となります。

これは経験豊富な開発者にとっては大きな問題ではないように思えるかもしれません。私たちはアプリケーションから最大限の性能を引き出し、より高度な機能を開拓するために工夫を凝らすものだからです。しかし、これは深刻な設定ミスやセキュリティ脆弱性につながるブラックホール、すなわち「未定義の動作」を招く可能性があります。Rustでのプログラミングは（unsafeな使用時であっても）、CやC++と比較して脆弱性の可能性をかなり抑え込めますが、未定義の動作を呼び出すことはリスクとなり得ます。

これは、開発者主導のセキュアコーディングへの依存が終わることを意味するのでしょうか？

先ほど、Rustには有名な言語の要素が含まれていると言ったのを覚えていますか？Rustの主なセキュリティ脆弱性の一つは、まさにC言語の要素を含んでいるという点です。

Rustは依然として「安全なプログラミング言語」ですが、やはりユーザーが介在するところで問題が生じます。開発者はエラーをフラグ立てせずに実行するように調整できてしまうため（これはより多くの機能を使えるようになるため魅力的な提案です）、本質的には安全な状態であっても、開発者は好きなだけ「安全でない」コードを書くことができます。なぜなら、事態が深刻化する前にガイダンスと保護の層が存在するからです。

上記のどちらのシナリオも、深く掘り下げるほど危険になります。Rustの結果はスキャンツールと似ているからです。あらゆる脆弱性、攻撃ベクトル、問題をスキャンできる万能なSAST/DAST/RAST/IASTツールが存在しないのと同様に、Rustも万能ではありません。Rustであっても、いくつかの脆弱性は依然として非常に簡単に混入する可能性があります。

Unsafe Rustを実行する際の未定義動作のリスクは、整数オーバーフローの問題を引き起こす可能性があります。また、一般的に安全な設定であっても、セキュリティ設定ミスやビジネスロジックの欠陥、既知の脆弱性を持つコンポーネントの使用といった人的ミスを防ぐことはできません。これらの問題はパッチを当てなければ非常に現実的な脅威となります。Rustのような「安全と見なされる」環境では、主要な問題はすべて自動的に解決されるとコーダーが信じ込むことで、かえって油断が生じる可能性さえあります。

Rustはプログラミングのメンターのような存在だと感じています。経験の浅いコーダーに寄り添い、作業をレビューし、潜在的なバグを指摘し、効率化を教え、時には正しくなるまでコンパイルさせないようにするシニアエンジニアのようなものです。しかし、Rustプログラマーは理論を学び、ベストプラクティスを自ら実践する方がはるかに良いでしょう。メンターがいつまでも助けてくれるとは限らず、一人で立ち往生したくはないはずですから。

今すぐRustの一般的な脆弱性を見つけて修正する準備はできましたか？チャレンジに挑戦しましょう。