JPCERT コーディネーションセンター

ENV00-J. 特権の必要ない動作のみを行うコードを署名しない

Javaでは、コードに特権を与える場合、コード署名が行われていることを要求している。セキュリティポリシーの多くは、署名されたコードが特権を持って動作することを許可する。たとえば、署名されたJavaアプレットは、サンドボックスが通常課す制限を受けずに動作することができる。ユーザは明示的に、特定のコードベースもしくはある署名者が署名したすべてのコードに対し、パーミッションを与えることができる。この手法は、セキュリティの管理をユーザの手に委ねることになる。ユーザはプログラムをすべての権限を付与して実行するか、制限された権限で実行するかを選択することができる。

しかし、コード署名には固有の問題が存在する。Schneier は次のように述べている[Schneier 2000]。

まず、利用者はある署名者を信用していいかどうかまったくわからない。2番目に、コンポーネントに署名があるからといって、それが安全だということにはならない。3番目に、コンポーネント2つにそれぞれサインがあっても、それをいっしょに使って安全かどうかはわからない。各種の偶然の有害な相互作用が悪用されかねない。4番目に、「安全」というのは白黒はっきりしたものじゃない。安全にも程度がある。5番目に、攻撃の証拠(コードの署名)が、攻撃されているコンピュータに保存されているのでほとんど意味がない。攻撃者は、攻撃の最中に署名を削除・改変するか、署名の入ったドライブにフォーマットをかけるだけだ。

コード署名は、コードの完全性を検証するとともにコードの作成者が本物であることを証明するために設計されている。コード署名は認証機関(CA)に基づいて署名者本人の同一性を確認する。技術に明るくないユーザが証明書や公開鍵基盤(PKI)を理解しているなどと思ってはならない。

一般にユーザは、電子署名されたコードは実行しても安全であり、コードを信頼しても害はないと考えがちである。しかし、署名されたコードに脆弱性が発見された場合、問題が発生する。多くのシステムは、署名をする特定の組織(signing organization)を永久に信頼するように設定されているため、そのようなシステムは、信頼された組織によって署名されたコードをユーザがダウンロードする際、たとえコードに脆弱性が含まれていても、それをユーザに通知することができない。攻撃者は、ユーザに対して、正規に署名された脆弱なコードを、攻撃する意図を持って提供することができるであろう。

署名されたJavaアプレットを例に考えてみよう。広く利用されているプラットフォーム上では、証明書が確認された場合、ユーザに、「この発行元が提供するコードを常に信頼する」というオプションが選択された状態のセキュリティダイアログが提示される。このダイアログはそもそも、署名されたコードを実行してもよいかどうかを確認するためのものである。しかし、このオプションが選択されたダイアログを承認すると、「…を常に信頼する」の設定が、以降の警告ダイアログ表示を抑制してしまう。攻撃者はこの仕組みを悪用し、信頼された組織によって署名された脆弱なコードを攻撃することができる。この場合、コードはユーザが暗黙的に与えたパーミッションの元で実行され、自由に攻撃されてしまうであろう。

自ら開発したコードを署名する場合、第三者から取得したコードを注意深く監査することなく署名すべきではない。特権で動作するコードを署名する場合、署名されたすべてのコードを単一のJARファイルに収めること(詳しくは「ENV01-J. セキュリティ上重要なコードは署名付きの1つの JAR にまとめてシールする」を参照)。また、特権を持つコードから実行されるコードも、そのJARファイルに含めておかなければならない。特権を必要としないコードは署名せず、サンドボックス内で実行させること。たとえば、署名されていないアプレットや Java Network Launching Protocol (JNLP) アプリケーションは最小限の権限を付与されており、サンドボックスの制約を受ける。最後に、理解できないコードや監査済みでないコードも絶対に署名すべきでない。

例外

ENV00-EX1: 自組織内にPKIを持ち、内部の開発活動(たとえば、コードのチェックインや開発者の活動の追跡など)のためにコード署名を用いている場合、特権を持たないコードを署名してもよい。ただし、このような内部的な署名がなされたままのコードを実運用環境に持ち込んではならない。組織内での署名のために用いられる鍵は、外部に公開するコードの署名に用いる鍵と別にすること。

リスク評価

特権を持たないコードを署名すると最小権限の原則に違反する。なぜなら、JavaアプレットやJNLPアプリケーションなどのセキュリティーポリシーが定義する制約を無効にするかもしれないからである。

ルール 深刻度 可能性 修正コスト 優先度 レベル
ENV00-J P12 L1
自動検出

特権を持つあるいはセンシティブなコードを検出するには、プログラマの情報提供が必要である。特権を持つコードがどれであるかが分かれば、そこから呼び出されるコード全体を識別し、署名されたコードがそのなかに入っているか、また、署名されていないコードは入っていないかを判別することは可能であろう。

関連ガイドライン
ISO/IEC TR 24772:2010 Adherence to least privilege [XYN]
参考文献
[Dormann 2008]  
[McGraw 1999] Appendix C, Sign Only Privileged Code
[Schneier 2000]  
翻訳元

これは以下のページを翻訳したものです。

ENV00-J. Do not sign code that performs only unprivileged operations (revision 90)

Top へ

Topへ
最新情報(RSSメーリングリストTwitter