Hatena::ブログ(Diary)
ブログトップ 記事一覧 ログイン 無料ブログ開設

pc4beginnerの日記 RSSフィード

2013-02-05

JavaVM1.7 update13関連情報

| 15:41 | JavaVM1.7 update13関連情報 - pc4beginnerの日記 を含むブックマーク

JavaVMの7の脆弱性、2/1付リリースのUPDATE13で2つ目の穴が塞がれたみたいですね。

ついでに1.6も最終版と噂されるupdate39がリリースされています。

ちょいと情報採取した履歴をまとめておきました。

Java最新版に新たな脆弱性情報(2013年01月21日 07時40分 更新)

Oracle脆弱性を修正したばかりの「Java 7 Update 11」に、新たな2件の脆弱性が報告された。

http://www.itmedia.co.jp/news/articles/1301/21/news022.html

  ↓

Java更新版「Java 7 Update 13」、前倒しでリリース 攻撃の発生受け(2013年02月04日 07時48分 更新)

Oracleは、脆弱性を突く攻撃が発生したことから定例パッチを前倒しで公開。AppleMac OS X v10.6.8向けのJavaアップデートを公開した。

http://www.itmedia.co.jp/enterprise/articles/1302/04/news019.html

OracleJava更新版を緊急リリース、「攻撃が観測されているため前倒し」 (2013/02/04)

http://itpro.nikkeibp.co.jp/article/NEWS/20130204/454062/

>Update 13は、これまでに見つかった複数のセキュリティ脆弱性に対処するための修正プログラムを含んでいる。前回のJavaアップデート(Update 11)では、それより前から存在した脆弱性(コード番号CVE-2013-0422)への対応が不十分という指摘があり、Java自体の無効化を推奨する動きもあった(関連記事)。Oracleの説明によると、Update 13には、この脆弱性に関する修正も含まれている。

※以下のリンク先は全部英文。

リリースノート(1.6Update 39)

http://www.oracle.com/technetwork/java/javase/6u39-relnotes-1902886.html

リリースノート(1.7Update 13)

http://www.oracle.com/technetwork/java/javase/7u-relnotes-515228.html

脆弱性への対応について

Oracle Java SE Critical Patch Update Advisory - February 2013

http://www.oracle.com/technetwork/topics/security/javacpufeb2013-1841061.html

ダウンロード

Java SE 7 Downloads

http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase7-521261.html

Java SE Downloads

http://www.oracle.com/technetwork/java/javase/downloads/index.html

CVE-2013-0422についてのリスク

Text Form of Oracle Security Alert - CVE-2013-0422 Risk Matrices

http://www.oracle.com/technetwork/topics/security/alert-cve-2013-0422-verbose-1896885.html

取り急ぎそんな感じで。

バッチ作成者、日本語情報作成者に感謝。

2011-12-14

JRE6 Update 30リリースノートと、29の問題の解消。

| 16:39 | JRE6 Update 30リリースノートと、29の問題の解消。 - pc4beginnerの日記 を含むブックマーク

JRE6 Update 29で発生していたセキュリティ接続に冠するバグですが、一昨日リリースされた最新のバージョンJRE6 Update 30で解消されたようです。少なくとも私の遭遇していた問題は解消されていました。やれやれ。

というわけで、リリースノートを懲りずに翻訳しておきます。相変わらず英検3級レベルの知識でgoogle翻訳を意訳していますので、訳の微妙さはご了承下さい。

http://www.oracle.com/technetwork/java/javase/6u30-relnotes-1394870.html


Update Release Notes


JavaSE 6 Update 30

The full internal version number for this update release is 1.6.0_30-b12 (where "b" means "build"). The external version number is 6u30.


Update Release Notes


JavaSE 6 Update 30

このアップデートリリースの正式な内部バージョン番号は1.6.0_30- B12("b"は"build"を表します)です。外部バージョン番号は6u30です。


Highlights

This update release contains enhancements for Java applications:


 ・Improved performance and stability

 ・Support for Red Hat Enterprise 6

Olson Data 2011l

Java SE 6u30 contains Olson time zone data version 2011l. For more information, refer to Timezone Data Versions in the JRE Software .


ハイライト

このアップデートリリースは、Javaアプリケーション用の拡張機能が含まれています。


 ·パフォーマンスの向上と安定性

 ·Red Hat Enterprise6のサポート


Olson Data 2011l

JavaのSE6u30は、Olsonのタイムゾーンデータのバージョンの2011lが含まれています。詳細については、JREソフトウェアの時間帯のデータのバージョンを参照してください。


Security Baselines

The security baselines for the Java SE platform at the time of the release of Java SE 6u30 are specified in the following table:


セキュリティベースライン

Java SE6u30のリリース時にJava SEプラットフォームセキュリティのベースラインは、次の表に示されています:

(中略)




On October 30, 2008, Java SE 1.4.2 reached its end of service life with the release of 1.4.2_19. Java SE 5.0 reached its end of service life on November 3, 2009, with the release of 5.0u22. Future revisions of Java SE 1.4.2 (1.4.2_20 and above) and Java SE 5.0 (5.0u23 and above) are available to Java for Business subscribers.


平成20年10月30日には、Java SE1.4.2_19のリリースに伴い1.4.2はサービス期間の終了を迎えました。Java SE 5.0は5.0u22のリリースで、2009年11月3日にサービス期間の終了を迎えました。Java SE1.4.2(1.4.2_20以降)およびJava SE 5.0(5.0u23と上記)の将来のリビジョンは、ビジネスサブスクライバ用のものが用意されています。


For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer .


セキュリティベースラインの詳細については、Internet Explorer用のJava Plug-inからJREのバージョン群のJavaアプレットデプロイを参照してください。


Additional Certified System Configurations

For Java SE 6u30, the following system configuration has been certified:

 ・Red Hat Enterprise Linux 6

Refer to the Oracle Certified System Configurations page for more information.


追加の認定システム構成

Java SE6u30では、以下のシステム構成が認定されています:


 ・Red Hat Enterprise Linux 6

詳細については、Oracle認定のシステム構成のページを参照してください。


Java VisualVM 1.3.2

Java VisualVM based on VisualVM 1.3.2 is included in Java SE 6u30. This release introduces the following features and enhancements:


 ・Issue 428: Show CompositeType field descriptions in tooltips

 ・Tracking (hash)map resize events by Tracer-Collections plugin


For more information, see the VisualVM 1.3.2 release notes.


Java VisualVM 1.3.2


VisualVM1.3.2に基づいて、Java VisualVMはJava SEの6u30に含まれています。このリリースでは、以下の機能と拡張機能が導入されています:


 ・問題428:tooltipsで表示するCompositeTypeフィールドの説明

 ・Tracer-Collectionsプラグインによるトラッキングハッシュ)マップのサイズ変更イベント


詳細については、VisualVMの1.3.2のリリースノートを参照してください。


Bug Fixes

The following is a notable bug fix for Java SE 6u30:


Area: JSSE: Runtime

Synopsis: REGRESSION - 6u29 breaks ssl connectivity using TLS_DH_anon_WITH_AES_128_CBC_SHA


バグ修正

以下は、Java SE6u30のための注目すべきバグの修正です。


エリア:JSSE:ランタイム

概要:回帰 -6u29でやめた TLS_DH_anon_WITH_AES_128_CBC_SHAを使用したSSL ※ここ自信ないです。


It is strongly encouraged that applications using JSSE (SSL/TLS) be upgraded to this release to have access to the latest changes that address this recent vulnerability: Under certain circumstances, Java SE 6u29 will incorrectly throw an IndexOutOfBoundsException or send an extra SSL/TLS packet. See 7103725.


JSSE(SSL/ TLS)を利用するアプリケーションは、以下の最近の脆弱性への対処の最新の変更が適用されるので、このリリースにアップグレードする事を強く推奨します。

:特定の状況下では、Java SE6u29は、誤ってIndexOutOfBoundsExceptionをスローや余分なSSL/ TLSパケットが送信されます。 詳細は7103725を参照してください。


For other bug fixes, see Java SE 6u30 Bug Fixes.


他のバグ修正については、Java SE6u30のバグ修正を参照してください。


というわけで、この件のエントリはおしまい。

2011-10-28

JRE1.6.0_29を使うと、リモートスクリプトの処理が動かない

| 19:53 | JRE1.6.0_29を使うと、リモートスクリプトの処理が動かない - pc4beginnerの日記 を含むブックマーク

JavaVMの該当バージョンを使うと、リモートスクリプトの処理が動かなくなって困ってます。


で、やっとJavaのユーザーフォーラムでそれっぽい情報が上がってきたので翻訳をしておきます。

https://forums.oracle.com/forums/thread.jspa?threadID=2300917&tstart=0

※2011/10/27 9:50 の投稿を参照

なお、英検三級(数十年前)、Javaは門外漢の人間が翻訳してるので突っ込みどころがあればコメントいただければ直ぐに直します。


ざっくりまとめると、Javaが同一生成元ポリシー(SOP)というweb標準の考え方に即してないところがあって(どうやらこれがセキュリティホールだったみたい)、そいつの修正を実施したらバグが出てしまった、と。

ただし挙動としてはSOPに準拠したものなので、その考え方ではバグじゃないよと最期の一文で言い訳してます。

このバグは1.7にも含まれると書いてあります。

ちなみにこのセキュリティホールについてはUSで一般公開されている脆弱性情報データベース(CVEhttp://ja.wikipedia.org/wiki/%E8%84%86%E5%BC%B1%E6%80%A7%E6%83%85%E5%A0%B1%E3%83%87%E3%83%BC%E3%82%BF%E3%83%99%E3%83%BC%E3%82%B9)で取り挙げられているもので(CVE-2011-3555で検索して下さい。英文しか出てこないけど)、SSL認証に関わるものなのでJavaだけでなく、SSL通信を利用するアプリは全て緊急の対策を行っているみたいです。


では翻訳開始。

In JDK 6u29 a change was made to bring Java into closer alignment with the web Same Origin Policy.

JDK6u29の変更は、Javaにwebの同一生成元ポリシー(http://keicode.com/script/jsonp-same-origin-policy.php)と整合をもたらすために行われました。

In some cases this has caused existing applications to break.

The problem manifests when secure cookies are expected to be sent over an insecure connection.

場合によっては、これは既存のアプリケーションが中断する原因となっています。

問題は、セキュリティで保護されたcookieが安全性が保証されない接続を介して送信することが予想される場合に現れます。

If you application depends on this behavior you will need to sign the application.

In addition, if the request originates via a LiveConnect (javascript) call then it will need to be wrapped in a doPriviliged() block as javascript calls are treated as untrusted and do not carry the same protection domain.

もしアプリケーションがこの動作に依存している場合は、アプリケーションに署名する必要があります。

加えて、LiveConnect(javascript)を介してリクエストが発信する場合、同じ保護ドメインを持っていないjavascriptの呼出の処理と同じようにdoPriviliged() blockでラップする必要があります。

I realize that if your application uses just the Microsoft RSProxy class for remote scripting this isn't a likely solution for you.

We're still looking at this.

私はアプリケーションがremote scriptingにマイクロソフトのRSProxyクラスを使用する場合、この方法は解決策にはならない可能性が高いと認識している。

これについては我々はまだ調査中だ。

=== and ===

I wanted to let everyone know that the latest builds of the JRE (to be released in December) have the fix for this problem incorporated.

The latest build of 6u30 is at http://jdk6.java.net/6uNea.html.

そして。

私は皆さんにJREの最新ビルドが(12月にリリース予定)にこの問題の修正プログラムが組み込まれていることを知ってもらいたい。

6u30の最新のビルドはhttp://jdk6.java.net/6uNea.htmlにあります。

The background on this is:

  • We made a change in 6u29 to improve security in regards to the same origin policy (SOP), bringing Java into better alignment with the web standard (while trying not to break existing applications).
  • There is a bug where calls from Javascript (via "LiveConnect") to applets did not carry the same protection domain as the applet. This is what has been corrected in the latest early access builds of JRE 6 and 7. Sorry about that!
  • If (your application is unsigned OR you call a method via Javascript that attempts to access a secure cookie) we now check that the application is served from the same domain via httpS. If not you will still get this error, and that is the expected behavior because it's clearly a violation of the SOP.

当件の背景::

  • 我々は(既存のアプリケーションを破壊しないよう検討しているとき)JavaをWeb標準により則するように、同一生成元ポリシー(SOP)に配慮して、セキュリティを向上させるために6u29の変更を行いました。
  • アプレットへの(LiveConnect経由の)Javascriptからの呼び出しが、アプレットと同じ保護ドメインを持っていないバグがありました。これは、最新のJRE 6と7のビルドで修正されたものです。ごめんね!
  • アプリケーションが認証の無い状態、もしくはJavascriptを経由してセキュリティで保護されたcookieにアクセスしようとするメソッドを呼び出す)場合、Javaは、現在アプリケーションがHTTPS経由で同じドメインから提供されていることを確認します。そうでない場合でも、このエラーが表示されます、そしてそれは明らかにSOPの違反だからそれは正常な動作です。

Hope that helps.

私のこの助言が役に立つことを祈る


だ、そうです。

ごめんね!って。。。


今日はそんな感じで。

(2011/11/01追記)

バグデータベースにも情報がありました。

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7102914

これの翻訳は又今度。。。。

(2011/12/14追記)

12/12リリースのupdate30でこの問題が解消されました。リリースノートの翻訳はこちら。→http://d.hatena.ne.jp/pc4beginner/20111214