脆弱なバイナリインターフェースの問題

脆弱バイナリ インターフェイス問題( FBI ) は、特定のオブジェクト指向プログラミング言語コンパイラの欠点であり、基礎となるクラス ライブラリの内部変更によって、派生ライブラリまたはプログラムが動作しなくなる可能性があります。これは、ソフトウェアの脆弱性の一例です。

この問題は、脆弱な基本クラス問題またはFBCと呼ばれることが多いですが、この用語にはより広い意味があります。

この問題は、多くの一般的なオブジェクト指向 (OO) 言語のコンパイラで使用される「ショートカット」が原因で発生します。これは、CやPascalなどの以前の非 OO構造化プログラミング言語から OO 言語が進化したときに維持された設計機能です。

これらの言語には、現代的な意味でのオブジェクトはありませんでしたが、レコード(C では「構造体」) と呼ばれる類似の構造があり、さまざまな関連情報を 1 つのメモリに保持していました。特定のレコード内の各部分にアクセスするには、レコードの開始位置を追跡し、その開始位置から該当部分までのオフセットthisPerson.middleInitialを把握していました。たとえば、「人」レコードには、ファーストネーム、ラストネーム、ミドルネームのイニシャルがあり、プログラマーが記述したイニシャルにアクセスすると、コンパイラーが のような形式に変換しますa = location(thisPerson) + offset(middleInitial)。現代の CPU には通常、この一般的な種類のアクセスのための命令が含まれています。

オブジェクト指向言語コンパイラが最初に開発されたとき、既存のコンパイラ テクノロジの多くが使用され、オブジェクトはレコード概念に基づいて構築されました。これらの言語では、オブジェクトは開始点によって参照され、「フィールド」と呼ばれるパブリック データには既知のオフセットを介してアクセスされました。実際の変更点は、レコードに別のフィールドを追加しただけで、このフィールドは各クラスの不変の仮想メソッド テーブルを指すように設定され、レコードにはデータとメソッド (関数) の両方が記述されます。コンパイルされると、オフセットはデータとコードの両方にアクセスするために使用されます (仮想メソッド テーブル経由)。

これは、ライブラリから構築された大規模なプログラムで問題を引き起こします。ライブラリの作成者がオブジェクト内のパブリック フィールドのサイズまたはレイアウトを変更すると、オフセットが無効になり、プログラムが動作しなくなります。これが FBI 問題です。

実装の変更によって問題が発生することは予想できますが、FBI の厄介な点は、実際には何も変更されておらず、コンパイルされたライブラリに隠されているオブジェクトのレイアウトのみが変更されていることです。 を変更すると問題が発生する可能性があると予想されるかもしれませdoSomethingんdoSomethingElseが、この場合は を変更しなくても問題が発生する可能性doSomethingがあります。これは、わかりやすくするためにソース コードの行を移動するのと同じくらい簡単に発生する可能性があります。さらに悪いことに、プログラマーはコンパイラによって生成された結果のレイアウトをほとんどまたはまったく制御できないため、この問題はほぼ完全に見えなくなります。

複雑なオブジェクト指向プログラムやライブラリでは、最上位のクラスが数十のクラスを継承している場合があります。これらの基本クラスのそれぞれが、他の数百のクラスによって継承されている可能性があります。これらの基本クラスは、1 つの小さな変更が、直接または他のクラスから継承するすべてのクラスに問題を引き起こす可能性があるため、脆弱です。基本クラスへの 1 つの変更によって多くのクラスが破損するため、ライブラリがトランプの家のように崩壊する可能性があります。継承ツリーが複雑な場合は、変更が記述されているときに問題に気付かない可能性があります。実際、基本クラスを変更する開発者は、他の人が開発したどのクラスがそれを使用しているかを認識していないのが一般的です。

脆弱なバイナリ インターフェースの問題に対する 1 つの解決策は、問題の存在を認識し、そもそも問題が起こらないようにする言語を書くことです。以前の言語から進化したものとは対照的に、カスタム記述されたほとんどの OO 言語は、ロード時にすべてのオフセット テーブルを構築します。ライブラリのレイアウトの変更は、その時点で「認識」されます。Selfなどの他の OO 言語は、ライブラリにあるオブジェクトをコピーして変更することで実行時にすべてを構築するため、実際には脆弱になり得る基本クラスはありません。Javaなどの一部の言語には、FBI 問題を引き起こさずに安全に実行できる変更に関する詳細なドキュメントがあります。

もう 1 つの解決策は、コンパイル段階からオフセットやその他の情報をリストした中間ファイル (メタデータと呼ばれる) を書き出すことです。リンカーは、ライブラリがアプリケーションにロードされるときにこの情報を使用して自分自身を修正します。.NETなどのプラットフォームはこれを実行します。

しかし、市場では、C++などの「位置依存」のプログラミング言語が選ばれており、そのため FBI が見られます。このような場合でも、問題に対する解決策はいくつかあります。1 つは、将来的に機能を追加する必要がある場合に備えて、ライブラリ作成者にいくつかの「プレースホルダー」オブジェクトを挿入させることで、ライブラリ作成者に負担をかけることです (これは、DirectXライブラリで使用される構造体で確認できます)。この解決策は、これらのダミーがなくなるまではうまく機能しますが、メモリを消費するため、あまり多く追加することは望ましくありません。

Objective-C 2.0 は、インスタンス変数アクセスのための追加の間接レベルを備えることで、 脆弱でないインスタンス変数を提供します。

もう 1 つの部分的な解決策は、ブリッジ パターンを使用することです。これは、「Pimpl」(「実装へのポインター」)とも呼ばれます。Qtフレームワークは、このような実装の例です。各クラスは、実装データを保持する構造体へのポインターであるデータ メンバーを 1 つだけ定義します。ポインター自体のサイズは (特定のプラットフォームでは) 変更される可能性は低いため、実装データを変更しても、パブリック構造体のサイズには影響しません。ただし、仮想メソッドをクラスに導入したり、継承グラフを変更したりするなど、他の重大な変更は回避できません。

別の解決策としては、よりスマートなリンカーが必要です。Objective -Cのオリジナル バージョンでは、ライブラリ フォーマットによって 1 つのライブラリの複数のバージョンが許可され、呼び出されたときに適切なライブラリを選択する機能がいくつか含まれていました。ただし、オフセットはフィールドにのみ必要であり、メソッドのオフセットは実行時に収集されるため FBI を引き起こすことはないため、これは必ずしも必要ではありませんでした。メソッドはフィールドよりも頻繁に変更される傾向があるため、ObjC ではそもそも FBI の問題はほとんどなく、発生した問題もバージョン管理システムで修正できます。Objective-C 2.0 では「最新のランタイム」が追加され、フィールドの FBI 問題も解決されました。さらに、TOM 言語では実行時に収集されたオフセットがすべてに使用されるため、FBI は不可能です。

可能な場合は、動的ライブラリの代わりに静的ライブラリを使用するのも別の解決策です。静的ライブラリを使用すると、アプリケーションを再コンパイルして使用するオフセットを更新しない限り、ライブラリを変更できなくなります。ただし、静的ライブラリには、バイナリが大きくなったり、ライブラリの新しいバージョンが導入されても「自動的に」使用できないなど、独自の深刻な問題があります。

これらの言語では、単一継承を強制することで（継承ツリーの複雑さが軽減されるため）、また、インターフェイス自体にはコードが含まれず、インターフェイスが宣言する各メソッド シグネチャがインターフェイスを実装するすべてのオブジェクトによってサポートされるという保証のみが含まれるため、仮想関数を持つ基本クラスの代わりにインターフェイスを使用することで、問題が軽減されます。

ライブラリのソース コードが利用可能であれば、問題はすべて解消されます。その場合、単純な再コンパイルで解決できます。

• 脆弱な基本クラス

• BeOS の問題とその解決策に関する論文