Object Injection

信頼できないデータのデシリアライズが任意の Ruby オブジェクトの挿入を許し、これが原因となり、プログラムが攻撃者に利用されて悪意のあるコマンドを実行する場合があります。

オブジェクト挿入の脆弱性は、信頼できないデータが YAML.load() のようなデータをデシリアライズする関数に渡される前に適切にサニタイズされないときに発生します。攻撃者は特別製のシリアライズされた文字列を脆弱な YAML.load() コールに渡すことができます。その結果、デシリアライズの際にクラスがアプリケーションに読み込まれるのであれば、任意の Ruby オブジェクトをプログラムに挿入できます。これはさまざまな攻撃の機会を与える可能性があります。たとえば、Cross-Site Scripting の脆弱性を検出する検証ロジックをバイパスしたり、ハードコーディングされているように見える値で SQL Injectionを許したり、あるいは完全なコード実行を許すこともあります。

例 1: 次のコードは SQL クエリを作成する Ruby クラスです。ここで使用される属性はデータベースに照会されます。ここに、ユーザー指定データを使用した YAML.load() に対する安全でないコールもあります。

...
class Transaction
  attr_accessor :id
  def initialize(num=nil)
    @id = num.is_a?(Numeric) ? num : nil
  end

  def print_details
    unless @id.nil?
      print $conn.query("SELECT * FROM transactions WHERE id=#{@id}")
    end
  end
end

...
user = YAML.load(params[:user]);
user.print_details
...

Example 1 では、アプリケーションはシリアライズされた User オブジェクトを要求する可能性があり、print_details という名前の関数も与えられます。しかしながら、攻撃者は実際にはシリアライズされたバージョンの Transaction オブジェクトとその @id 属性の事前定義された値を与えることができます。そのため、次のような要求は、@id が数値であることを確認する検証チェックのバイパスを許可します。

GET REQUEST:  http://server/page?user=!ruby%2Fobject%3ATransaction%0Aid%3A4%20or%205%3D5%0A

これのデコードされたバージョンがあれば、user パラメーターに !ruby/object:Transaction\nid:4 or 5=5\n が割り当てられることがわかります。
ユーザー パラメーターをデシリアライズすると、Transaction 型のオブジェクトが作成され、@id が "4 or 5=5" に設定されます。開発者は User#print_details() をコールしているつもりでも、Transaction#print_details() がコールされており、Ruby の文字列補間の結果、SQL クエリは SELECT * FROM transactions WHERE id=4 or 5=5 をクエリとして実行するように変更されます。句が追加されたことで、このクエリは true として評価され、開発者が意図した単一行ではなく、transactions テーブルにあるすべての行が返されます。

攻撃者は、脆弱な YAML.load() が、BlackHat 2010 会議で Stefan Esser により紹介された、「Property Oriented Programming」として知られている技術を使用して呼び出されたときに、宣言された異なるクラスを繋げることができます。この技術により攻撃者は既存のコードを再利用してそのコード自身のペイロードを作成することができます。