分析「9月25日火曜日の午後、当社のエンジニアリングチームは、約5000万のアカウントに影響を与えるセキュリティ問題を発見しました」と、Facebookのガイ・ローゼン氏は9月のセキュリティアップデートで述べた。
問題は深刻でした。盗まれたのはパスワードではなく、アクセストークンでした。アクセストークンとは、ユーザーを識別し、アプリがユーザーに代わってFacebookにアクセスするために使用するソフトウェアインターフェースであるAPIへのアクセスを許可する、不透明な文字列です。
トークンを入手した攻撃者は、他のユーザーになりすましてログインすることができました。さらに悪いことに、Facebook認証を使って他のサイトにログインすることもできましたが、実際にそれが行われたかどうか、また誰が攻撃を仕掛けたのかは不明です。
このセキュリティ災害の原因はプログラミング上のミス、あるいはエンジニアリング担当副社長のペドロ・カナワティ氏によると「3つのバグの組み合わせ」だった。1つ目は、本来は読み取り専用APIであるはずのバグで、動画の投稿を可能にしていた。2つ目は、動画アップロードAPIのバグで、広範な権限（Facebookモバイルアプリの権限）を持つアクセストークンを生成していた。3つ目は、おそらく最も深刻なバグで、アクセストークンが現在のユーザーではなく、プロフィールを閲覧していた別のユーザーのものだった。
このインシデントは、リソースが豊富であってもソフトウェアプロジェクトにはバグが存在すること、そして機能に直接影響を与えないバグは発見が難しいことを示しています。テストは今日のソフトウェア開発と展開に不可欠ですが、あらゆる入力の組み合わせをテストしたり、あらゆる障害を考慮に入れたりできるテストは存在しません。
この事例は、特定のコードの大量使用によって、今日のソフトウェアバグの影響がいかに拡大するかを示しています。今回のケースでは、5,000万件のアカウントが、数え切れないほど多くのサードパーティサイトへのアクセスを許す可能性があります。
最近のもう一つの例を挙げると、マイクロソフトは2018年10月にWindows 10の機能アップデートを十分なテストを実施せずにリリースしましたが、その際にバグが発生し、場合によってはユーザーデータが削除される可能性がありました。このバグは数千人のユーザーに展開された後、削除されました。評判の低下、サポート、そして修復にかかるコストは甚大です。
OpenSSL の Heartbleed を詳しく分析: わずか 4 バイトで恐ろしいバグが発生
続きを読む
2014 年に発見された Heartbleed バグの核心は、OpenSSL 暗号化ライブラリの次の 1 行のコードでした。
memcpy(bp, pl, ペイロード);
このコードは、データの実際のサイズがコピーされるデータ量と一致するかどうかを確認していません。攻撃者はサイズを偽装することで、メモリ内に偶然存在する他のデータ（ユーザー名やパスワードなど）のコピーを取得する可能性があります。このバグは、世界でアクティブなインターネットサイトの3分の2が使用しているApacheおよびNginxウェブサーバー、そしてOpenSSL経由で利用されている無数のネットワークアプリケーションに影響を与えました。
1行進んで2行戻る
ベンチャーキャピタリストのマーク・アンドリーセンは2011年、ソフトウェアが世界を席巻していると予測し、大きな話題を呼んだ。しかし、その20年前、プログラマーで作家のスティーブ・マッコーネルは、業界平均で1,000行のコードあたり15～50個のバグがあると予測し、1995年のスタンディッシュ報告書ではソフトウェアプロジェクトの3分の1がキャンセルされ、年間810億ドルの損失につながっていると指摘していた。マッコーネルとスタンディッシュはソフトウェアデリバリーの現場に姿を現さず、品質の低さという評判をさらに固めてしまった。ソフトウェアプロジェクトは遅延し、バグがつきものだと当然のように思われていた。納期通りに予算内で納品され、意図したとおりに動作すれば、それは驚きだった。
それは 1990 年代のことで、それ以来ソフトウェア ツールや開発手法、文化は大きく変化しました。
肯定的な変化の顕著な例としては、テスト駆動開発や、1990年代のエクストリームプログラミング手法から生まれたコードカバレッジ（テスト中に実行されるコードの量）の概念が挙げられます。静的コード解析もまた、コーディング規約を強制し、明らかなバグを検出するツールを備えています。コーディング規約自体も進化しており、コードユニットを短くするなど、コードの信頼性を高める方法に関する知識が取り入れられています。
より安全なプログラミング言語の登場も貢献しています。1996年に初めてリリースされたJavaのように、自動メモリ管理機能を備え、ポインタを直接使用しない高水準言語は、開発者が一部のエラーを回避しやすくしました。最近では、GitHubなどのクラウドホスト型ツールのおかげで、あらゆる規模のチーム向けのソフトウェアライフサイクル管理ツールが簡単に導入できるようになりました。
その結果、開発者はコードをクリーンな状態に保てているでしょうか?
ソフトウェアがより普及するにつれ、答えは「イエス」となるはずです。ソフトウェアはもはや職場（Windows PCやサーバー）だけのものではなく、また、あまり知られていない産業用制御システム向けに開発されたものでもなくなりました。一方、ソフトウェアのバグは、企業の人事サーバーだけでなく、他のサーバーにも影響を及ぼす危険性があります。
2017年のMitre Common Weakness Enumeration（CWE）リストをざっと見てみると、特に明るい材料は見当たりません。リストの上位にはSQLインジェクションを含むインジェクション攻撃が並んでおり、これは巧妙に細工されたユーザー入力によって不正なコマンドが実行される攻撃です。これは長年にわたりよく知られた脆弱性ですが、依然として問題を引き起こしています。
CWEリストで言及されているもう一つの領域は、「既知の脆弱性を持つコンポーネントの使用」です。ソフトウェア開発者は常にライブラリに依存しており、あらゆるプロジェクトのコードの大部分は他者によって書かれています。しかし、Heartbleedが示したように、ライブラリやコンポーネントもバグから逃れられるわけではありません。ライブラリやコンポーネントにバグが発見された場合、修正されます。
しかし、バグのあるバージョンを使用していたすべてのアプリケーションにパッチを適用するのは容易ではありません。影響を受けるアプリケーションの多くは、今後積極的に開発されなくなるでしょう。中には、パッチが適用されないネットワーク機器のファームウェアに潜んでいるものもあるかもしれません。自動パッチ適用と、デバイスベンダーによる綿密なパッチ管理がなければ、モノのインターネットは「バグのインターネット」と化してしまうでしょう。
バグは大きな代償を払う可能性があり、致命的となることもあります。カーネギーメロン大学のフィル・クープマン教授は、自動運転車やその他の車載ソフトウェアといった安全性が極めて重要な分野を含む組み込みソフトウェアの品質を専門としています。致命的な可能性のある車載ソフトウェアの欠陥に関する最近の投稿で、クープマン教授は、意図しない加速、解除されないクルーズコントロール、パワーステアリングによるドライバーの車両制御の妨げなど、50件以上の懸念すべき欠陥の報告を挙げています。
