今日、ほとんどすべてのデスクトップおよびほとんどのモバイルオペレーティングシステムとデバイスがOpenGLの一部のバージョンをサポートしています。私はそれのセキュリティへの影響について疑問に思っています:
では、ビデオのデータや、自分のものではないメインメモリのデータを読み取るシェーダープログラムを作成できないのは、だれか、何が原因でしょうか。
Linuxグラフィックシステムの現在の状況について プレゼンテーション を見つけました。これは、GPUへのコマンドがカーネルによって検証されるか、GPUで仮想メモリが使用されていることを示していますユーザー。
個別のアプリケーションが強力にサンドボックス化されているが、ほとんど無制限のOpenGLアクセスが可能な、Androidのような他の、特にモバイルのオペレーティングシステムについても同様です。 Tegra 2は、ドライバーのユーザーに潜在的に無制限のメモリアクセスを許可するためのプレゼンテーションで特に言及されています。
適切なセキュリティのために、グラフィックカードは、RAMにアクセスできる他のすべての種類のハードウェアと同様に扱う必要があります。それらは [〜#〜] mmu [〜#〜] およびカーネルの傘下にある必要があります-制御されたスケジューラ。同時に実行するタスクが互いに影響を与えることはなく、カーネルによって慎重に管理された通信チャネルを介してのみ相互作用する可能性があります。
お気づきのように、このような3Dグラフィックコントローラの分離と共有は最近の機能にすぎません。過去20年のほとんどの間、アクセラレートされた3Dグラフィックスは脆弱性への道を開いてきました...次の理由により、これが悪用されることは非常にまれです。
ほとんどのシステム(Windows、Linux ...)では、3Dカードへのアクセスは、マシンの前に座っているユーザーにのみ許可されます。これは、スムーズな3Dアニメーションがネットワーク上で切断されないためです。マシンに物理的にアクセスできる邪悪な人々は、GPUをいじるよりもシステムへのより効率的なエントリパスを持っています。
GPUの低レベルの詳細を扱うことは、特にそれらの多くが文書化されていないため、大変な作業です(これが、Linuxでプロプライエタリドライバーがまだ使用されている理由です)。攻撃者も人間なので、本質的に怠惰です。
スマートフォンのようなサンドボックス化プラットフォームは、3Dハードウェアにアクセスでき、しかも互いに敵対的であるホストアプリケーションを実行するため、状況を変える可能性があります。しかし、なぜ彼らは気にするのでしょうか?インストール時に広範なアクセス権を要求する方がはるかに簡単です(ユーザーはとにかく「はい」とだけ言ってください)。
LinuxとさまざまなGPUとドライバーでいくつかの実験を行いました。テクスチャマッピングの基本的なOpenGLチュートリアルを取り、glTexImage2Dの呼び出しでテクスチャデータへのポインターをnullポインターに置き換えました。
Nvidia GPUでnouveauドライバーを使用すると、結果はかなり興味深いものになりました。
キューブ上のテキストには、CompizによってGPUで合成されたターミナルウィンドウの以前のコンテンツが含まれているようです。
Intel GMAドライバーは黒い立方体しか表示しませんでした。 Android(AdrenoおよびNvidia Tegra 3 GPUでテスト済み)でも同じでした。
もちろん、これらのドライバー/システムのいずれかが安全であることを証明するものではありません。 OpenGL実装は、カーネルではなく、ドライバーのユーザースペースコンポーネントでのみメモリを初期化する場合もあります。