2017-08-11 8 views
3

ユーザーのOpenJDKのバージョンが特定のセキュリティ上の脆弱性の影響を受けやすいかどうかを判断する必要があります。例として、April 2016 Critical Patch Updateで明らかにされているように、OpenJDK 8u77でCVE-2016-0695が発見されました。理想的には、ユーザーのOpenJDKバージョンが脆弱かどうかを検出するのは、<= 8u77> 8u77のいずれかであるかどうかをチェックして脆弱であるかどうかをチェックするだけです(以前のすべてのバージョンも脆弱で、次のバージョンで修正が適用されると仮定します)。しかし、画像は手作業のパッチによって混乱する。OpenJDKのパッチを適用したバージョンを検出する

私が正しく理解している場合、2016年4月のパッチは次のバージョンのOpenJDK8(この場合は8u91)に自動的にバンドルされますが、手動でも使用できます。後者は、セキュリティホールにパッチを当てながら、Javaバージョンをそのまま維持したい、リスクを嫌うユーザーにとっては魅力的な選択肢になるでしょう。ユーザーが8u77のインストールに手動でパッチを適用すると、それを検出する方法はありますか?たとえば、java -versionによって報告されたバージョン番号は変更されますか?または、パッチが適用されたというインジケータはありませんか?

+0

パッチを適用してバージョン文字列をテストしましたか? – hardillb

+0

私は持っていますが、それらにアクセスするにはOracleサポート契約が必要です(他の場所で利用できる場合を除きます)。 – sevko

+0

@ alex-poole、私はセキュリティパッチがOracleによってリリース/管理されているように見えるので、[tag:oracle]タグを含んでいて、 'opatch'ユーティリティによって適用されています。 ? – sevko

答えて

3

OpenJDKのビルドがベンダーのものである場合、ベンダーはセキュリティ情報を公開する可能性があります。たとえば、CVE-2016-0695 security information from Debianがあります。この情報には、ベンダー固有のバージョニングスキームに基づいた最初の固定パッケージバージョンが含まれています。

しかし、一般的には、OpenJDKビルドのソースを入手し、修正する必要がある場合はそのビルドを確認する必要があります。

特定のCVE ID(たとえばCVE-2016-0695)に対応するパッチを見つけるには、ほとんどの場合、最も簡単な方法はRed Hat Bugzillaトラッカー(the flaw bug for CVE-2016-0695)にアクセスし、内部のOracleバグ番号この場合、8138593が表示されます。

hg clone http://hg.openjdk.java.net/jdk8u/jdk8u/jdk 

し、適切なために歴史の中で見ては、Oracleのバグ番号(8138593)に基づいて、コミット:

その後、 jdkコンポーネントのために、この場合には、適切なOpenJDKのサブツリーをチェックアウトする必要があります
changeset: 11581:594e8dca337c 
user:  igerasim 
date:  Thu Dec 24 08:42:10 2015 +0300 
summary:  8138593: Make DSA more fair 

コミット自体にはCVE IDが含まれていません(これは修正プログラムが書かれているとしばしば利用できないため、これは分かります)ので、Red Hatのバグトラッカーによる迂回が必要です。 (私は、OracleからCVE-ID・ツー・バグ番号のマッピングを見ていない。)

をあなたが別のMercurialのコマンドを使用してパッチを表示することができます。

hg export 594e8dca337c 

パッチを持っていたら、それはAですそれが適用されているかどうかを確認するためのソースコードをレビューすること。なんらかの理由でソースコードを入手できない場合は、jdkの変更のために、javap -cを使用して関連するクラスを逆アセンブルするだけで十分な場合があります。ネイティブコードの場合は、別の逆アセンブラが必要です(objdump -drなど)。

+2

さらにこれを追加します。パッチを適用してもビルド番号は自動的に変更されません。ビルド番号は、OpenJDKビルドプロセスの成果物で、コンフィグレーションステージで設定できるフラグがいくつかあります。 –

1

OpenJDK JDK 8アップデートプロジェクトは、ビルドやバイナリのパッチではなく、ソースコードを提供します。このプロジェクトのソースコードのための

セキュリティフィックスは、彼らは、Oracle

から製品の をリリースしているのと同じ頃にJDK 8の更新プロジェクトに 使用できるようになります http://openjdk.java.net/projects/jdk8u/qanda.htmlのQ & Aパー

プロジェクトのMercurialフォレストに統合するために用意されています。このようなソースコードのパッチは別途提供されるではなくであり、他のリリースではユーザーによって手動で適用されます。

通常、サードパーティのビルドで特定の変更が適用されているかどうかを理解する必要がある場合、アップストリームとサードパーティのビルドおよび/またはコミット履歴からソースコードを取得して比較する必要があります。ソースコード、コミット履歴、パッチ適用ポリシー、パッチのバージョニングおよびパッチタイミングを取得するメカニズムは、第三者とは異なる場合があります。

ダリバートピック主製品マネージャーJavaプラットフォームグループ@ Oracle

+0

私は、Oracleがopatchユーティリティのようなもので適用できるバイナリパッチを提供しているという印象を受けました。それは間違っていますか?もしそうならば、パッチはソースコード形式でしか存在しないとの結論になるので、JDKのメンテナレベル(エンドユーザレベルではなく、自分のJDKをソース)、そうですか? – sevko

+0

OpenJDKコミュニティを介して個々のOpenJDK 8アップデート用の実行可能バイナリを提供しないため、実際のバイナリは存在しません。 Daliborトピック主プロダクト・マネージャJava Platform Group @ Oracle –

関連する問題