SIDfm head title

「些細なこともセキュリティの専門家に気軽に相談できる安心」
ヘルプデスクサービス

 解決方法は判っているが専門家の意見を聞きたい、他の解決方法が無いことを確認したい、特定セキュリティホールへの専門家の意見を聞きたい、など不安を解消するためのちょっとした質問・疑問に答えてもらいたい。

インシデント制ではありません

 SIDfm のヘルプデスクサービスは、インシデント制やチケット制ではありません。最近の製品テクニカルサポートやサポートセンターへの問い合わせは、1つの事象とその解決までを1つの単位としたインシデント制が一般的になっています。しかし、インシデント制では、質問の内容に関係なく1つの事象で1インシデントを消費します。自分が全く解決方法を見つけられない問題であれば、1インシデントを消費することは惜しくありません。しかしながら、解決方法は判っているが専門家の意見を聞きたい、他の解決方法が無いことを確認したい、特定セキュリティホールへの専門家の意見を聞きたい、など不安を解消するためのちょっとした質問に1インシデントを消費することは躊躇します。
SIDfm のヘルプデスクサービスは、そんな不安を解消するために利用できます。

セキュリティコンサルタントが回答します

 SIDfm のヘルプデスクサービスは、セキュリティホールコンテンツを作成しているセキュリティコンサルタントが回答します。セキュリティコンサルタントが、SIDfm のセキュリティホールコンテンツを作成する際、すべて自社内において、情報収集、分析、コンテンツ作成までを行なっています。特にセキュリティホールの分析を行うに当たっては、ネットワーク関連知識、システムのハードウェア関連知識、OS、ミドルウェア、アプリケーション関連知識、プログラム言語やプログラミング関連知識に加え、セキュリティに関する世間一般の動向なども常に最新の情報を吸収しています。
SIDfm のヘルプデスクサービスは、セキュリティコンサルタントが、お客様からのご質問にお客様環境と一般動向を加味したより身近な回答をします。

セキュリティに関するお悩みもお受けします

 SIDfm のヘルプデスクサービスは、コンテンツに付随したセキュリティに関するご質問もお受けします。SIDfm のヘルプデスクサービスのご質問は、基本的にはコンテンツに関するご質問とさせて頂いております。しかしながら、セキュリティに関する悩みは、コンテンツに収まらないことも多く、また先にも述べた通りちょっとした相談をしたいことも多々あります。加えて、セキュリティに関する悩みの1つとして、相談できる人が身近にいないことをよく耳にします。
ですので、SIDfm のヘルプデスクサービスは、コンテツから派生したお客様のセキュリティに関するお悩みもお受けし、できる限り回答します。
(*)すべてのご質問への回答を保証するものではございません。

ご質問回答例

▶ (例1) Apache のセキュリティホールに対する修正方法の確認

[ご質問]

[SIDfm ID13116] Apache の HTTP Range ヘッダの処理に DoS 攻撃を受ける問題

 上記セキュリティホールに対して、コンテツ記載の暫定対策を実施予定です。
作業対象サーバでは現在mod_headersを利用していないため、設定を行う事ができません。
apacheデフォルトではRange ヘッダが有効になっているため、無効にするにはmod_headersをインストールしてRangeまたはRequest-Rangeをunsetする必要があるという認識であっていますでしょうか。
mod_headers がない場合、セキュリティホールの影響を受けない、という意味ではないですよね?

[回答]

対策方法は、お客様ご認識の通りでございます。
本セキュリティホールは、Range ヘッダまたは Request-Range ヘッダの処理が適切でないために発生し、影響を回避するために mod_headers を用いるものでございます。mod_headers のセキュリティホールではございません。

▶ (例2) セキュリティ監査で指摘された Apache のセキュリティホールへの対処方法の確認

[ご質問]

[SIDfm ID13874] Apache のエラーレスポンスの処理に情報漏洩の問題

 上記セキュリティホールの回避策として、セキュリティホール診断を受けた際、ベンダーよりカスタムエラーページの設定を行うことが有効である旨回答をいただきましたが、この点について御社はどのように考えられますか。
有効な回避策になりうるとした場合に、一般的な手順等何か有効な情報ををお持ちであればご教示いただけますと幸甚です。

[回答]

本セキュリティホールの回避策は、以下の2通りとなります。

  1. Apache 2.2.22 以上にバージョンアップする
  2. カスタムエラーページを設定する

従いまして、お問合せの「本セキュリティホールに対して、回避策としてカスタムエラーページの設定が有効か」の件につきましては、有効であると考えております。
Apache でカスタムエラーページを使用するには、設定ファイル httpd.conf において ErrorDocument ディレクティブの設定を行います。本セキュリティホールは、ステータスコード 400 の問題で、以下はその設定例ですが、実際に設定を行う場合には起こりうる全てのエラーコードに対してカスタムエラーページの設定を行うようご注意下さい。

○ ErrorDocument ディレクティブによるカスタムエラーページ設定(設定例)

ErrorDocument 400 /error.html

詳細については、以下のページをご参照下さい。

○ ErrorDocumentディレクティブ
http://httpd.apache.org/docs/2.0/mod/core.html#errordocument

○ HTTPステータスコード
http://ja.wikipedia.org/wiki/HTTP%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89

▶ (例3) BIND のセキュリティホールに対する EOL バージョンへの影響確認

[ご質問]

[SIDfm ID14892] ISC BIND の DNSSEC の処理にサービスを妨害される問題

本セキュリティホールの影響を受ける製品としてISC BIND9.4系~9.9系が記載されておりますが、9.2系や9.3系は影響を受けないとの認識でよろしいでしょうか。

[回答]

まず、結論から申し上げますと、BIND 9.2系や9.3系は本セキュリティホールの影響を受けません。本セキュリティホールの影響を受ける環境は、「BIND 9.4.3 以上を利用している」且つ「DNSSECを設定している」環境です。
なお、弊社は、サポート終了製品については掲載致しません。
これは、サポート終了製品については利用すべきではない製品であることは申し上げるまでもございませんが、ベンダーもサポート終了製品に対する情報提供および修正プログラム提供を行わないため、弊社が影響を受けるもしくは受けないの判断をできないためでございます。

ご参考までに、今回弊社が影響を受ける環境として「BIND 9.4.3 以上」とした根拠を以下に示します。

○ Ubuntu 10.04.4 LTS (Lucid Lynx) のパッチで修正箇所が確認できます。
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/bind9/lucid-security/revision/26

○ Red Hat Bugzilla の添付ファイルでも修正箇所が確認できます。
https://bugzilla.redhat.com/attachment.cgi?id=600171&action=diff

○ Ubuntu のアドバイザリで Ubuntu 8.04 LTS (Hardy Heron) が影響を受けないことが確認できます。
http://people.canonical.com/~ubuntu-security/cve/2012/CVE-2012-3817.html
(ソースリポジトリでも該当箇所がないことが分かります。)

○ BIND 9.2.0, 9.3.0, 9.4.2 の lib/dns/resolver.c には、影響を受ける関数dns_resolver_addbadcache が存在しません。

▶ (例4) JRE のセキュリティホールの詳細確認とバージョンアップ以外の対処方法の有無の確認

[ご質問]

上記セキュリティホールは、「Oracle Java Runtime Environment (JRE)」に関するセキュリティホールですが、何れも『攻撃者にこのセキュリティホールを利用された場合、信頼されない Java アプレットや Java WebStart アプリケーションを実行することによって、情報漏洩・情報改竄・サービス停止の影響を受ける可能性があります。』といった抽象的な内容でしたので、JREをバージョンアップするか否かの判断をする上でもう少し詳細な情報はないものかを確認させてください。
また、上記の内容次第ですが、現場からはJREバージョンアップ以外に回避策はないか?とも聞かれており、その点についても情報頂ければ助かります。(JREなので、バージョンアップ以外での回避は難しい気もしていますが)

[回答]

まず、初めにクライアント環境においては、Webページヘのアクセスなどを通じて、ブラウザのプラグインで攻撃者に提供されるコードを実行してしまう可能性がございます。Webページを利用しないとの選択肢はないと思われますので、JREのバージョンアップは必須と考えます。
次に、サーバ利用の場合は、それぞれの問題において判断が必要となる要素がございます。以降に、お問合せの問題に対しての新たな調査結果をお知らせ致します。貴社環境と合わせてご判断頂ければ幸いです。

■ #1 SIDfm ID:10801

JavaVM の Hotspot に関連するセキュリティホールです。JavaVM のセキュリティホールであり、ユーザ(攻撃者)から提供された Java のコードを JavaVM で実行させるようなことがなければ、任意のコード実行に悪用される可能性は低いと思われます。また本件は、JavaVM が、-Xcomp オプション有りで動作していない場合は、影響を受けないものと思われます。

但し、このセキュリティホール(不具合)は、特別に攻撃を受けなくても JavaVM がクラッシュを起こす原因になり得ます。

□ 参照
○ [SECURITY] IcedTea6 1.7.2 Released!
http://blog.fuseyism.com/index.php/2010/03/31/icedtea6-172-security-updates-released/
(CVE-2010-0845): No ClassCastException for HashAttributeSet constructors if run with -Xcomp (6894807)

○ IcedTea Repository
http://icedtea.classpath.org/hg/release/icedtea6-1.7/rev/786e03271cb9

○ OpenJDK Repository
http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/ae4032fb0a5b

修正しているファイル
* src/share/vm/opto/cfgnode.cpp
* src/share/vm/opto/type.cpp

■ #2 SIDfm ID:11622 / #3 SIDfm ID:11623

シリアライズとデシリアライズの処理に関連するセキュリティホールです。Java のクラスライブラリ中に存在する処理ですので、自身でのパッチ修正で回避できる可能性はございます。修正箇所については、Repository をご参照ください。

それぞれ検証コードもあるようです。(OpenJDKのリポジトリ参照)

□ 参照
○ [SECURITY] IcedTea6 1.7.5, 1.8.2 and 1.9.1 Released!
http://blog.fuseyism.com/index.php/2010/10/
S6559775, CVE-2010-3568: OpenJDK Deserialization Race condition
S6966692, CVE-2010-3569: OpenJDK Serialization

○ IcedTea Repository
http://icedtea.classpath.org/hg/release/icedtea6-1.7/rev/b5086c3910b3

○ OpenJDK Repository
http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/57681551c11e
http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/6b2459c08142

修正しているファイル
CVE-2010-3568
* src/share/classes/java/io/ObjectInputStream.java
* src/share/classes/java/io/ObjectOutputStream.java
* src/share/classes/java/io/SerialCallbackContext.java

CVE-2010-3569
* src/share/classes/java/io/ObjectStreamClass.java

■ #4 SIDfm ID:12210

JavaVM のセキュリティホールであり、ユーザ(攻撃者)から提供された Java のコードを JavaVM で実行させるようなことがなければ、任意のコード実行に悪用される可能性は低いと思われます。
但し、このセキュリティホール(不具合)は、特別に攻撃を受けなくても JavaVM がクラッシュを起こす原因になり得ます。

□ 参照
○ [SECURITY] IcedTea6 1.7.10, 1.8.7 and 1.9.7 Released!
http://blog.fuseyism.com/index.php/2011/02/15/security-icedtea6-1710-187-and-197-released/
S6878713, CVE-2010-4469: Hotspot backward jsr heap corruption

○ IcedTea Repository
http://icedtea.classpath.org/hg/release/icedtea6-1.7/rev/d063b76189d8

○ OpenJDK Repository
http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/a6f5011d46a9

修正しているファイル
src/share/vm/memory/allocation.cpp
src/share/vm/memory/allocation.hpp
src/share/vm/utilities/globalDefinitions_gcc.hpp
src/share/vm/utilities/globalDefinitions_sparcWorks.hpp
src/share/vm/utilities/globalDefinitions_visCPP.hpp

▶ (例5) ActivePerl のサポート期間とリリース情報について

[ご質問]

ActiveState社が提供しているActivePerlについて調べています。以下について教えていただけないでしょうか?

1.ActivePerl 5.6.xのサポート期間について
サポートが終了していると考えています、明確な記事が見つかりません。ご存知でしたら、記事およびURLも含めて教えていただけないでしょうか?また、元の perl と同じ考え方(2世代のみサポート)ではないかとも思っておりますが、いかがでしょうか?

2.ActivePerlのリリース情報について
ActivePerlのリリース情報が掲載されるホームページを教えてください。

[回答]

1. ActivePerl 5.6.xのサポート期間について
ActivePerl の Community Edition は Perl と同様に最新2つの安定リリースをサポートする方針のようですので、5.6.x のサポートは終了しています。

情報のソースは以下になります。

○ActivePerl のリリースノート
ActivePerl Community Edition Support Policy
http://docs.activestate.com/activeperl/5.14/release.html#activeperl_community_edition_support_policy

以下の文章で Perl と同様のサポートであることが分かります。
"The two most recent stable releases are available for free download.This corresponds to the Perl community's own version support policy."

○ActivePerl 5.8, 5.10 のサポート終了アナウンス
ANNOUNCE: ActivePerl 5.8 and 5.10 Community Edition - end of support
http://code.activestate.com/lists/activeperl/21649/

ActivePerl 5.8 と 5.10 のサポート終了のアナウンスから考えて、さらに古い 5.6.x もサポート終了していると考えて良いと思います。


2. ActivePerlのリリース情報について

リリース情報ではありませんが ActivePerl のダウンロードページには、最新のバージョンが掲載されています。

http://www.activestate.com/activeperl/downloads

また ActivePerl のメーリングリストのアーカイブページには、リリースアナウンスが掲載されると思います。(他のメーリングリストのやりとりに埋没しやすいです。)
http://code.activestate.com/lists/activeperl/

検索フォームから過去分を検索すれば、アナウンスが流れているのが確認できると思います。

▶ (例6) Linux Kernel のセキュリティホールに対する攻撃発生時の現象の確認

[ご質問]

[SIDfm ID13197] Linux Kernel のシーケンス番号生成処理にセキュリティホール

本セキュリティホールを狙った攻撃の手法としてブルートフォース攻撃を使用していることから、実際に攻撃を受けた際にはDoS攻撃のように、影響のあるKernelバージョンのサーバに対して大量のセッションが発生するとの認識でよろしいでしょうか?
対象のサーバの前段にはFWやIPS装置があるため、大量のセッションが発生するのであれば、それらの機器で本セキュリティホールを狙った攻撃を防御できるのではないかと考え、確認させていただいております。

[回答]

本セキュリティホールに対して攻撃を仕掛ける場合、ブルートフォース攻撃が必須ではないため、必ず大量のセッションが発生するとは限りません。
攻撃を成功させるためには、シーケンス番号がわかればいいので、ブルートフォース攻撃でなくても構いません。但し、本セキュリティホールの問題が十分なランダム度の無いシーケンス番号の生成にあることから、現実としては、攻撃する手法として簡単な方法は、シーケンス番号を順番にずらしていくタイプの一種のブルートフォース攻撃となります。

▶ (例7) Tomcat のセキュリティホールに対する他所掲載の緩和策の効果確認

[ご質問]

[SIDfm ID13810] Tomcat のハッシュテーブルの処理に DoS 攻撃を受ける問題

上記問題に対して、SIDfmでは「回避方法」は「なし」となっています。しかし、同じセキュリティホールを示す以下の情報では、「セキュリティホールの影響を緩和する回避策」として、以下の3項目が掲載されています。

  • リクエストごとの処理時間を制限する
  • POST リクエストのサイズを制限する
  • リクエストごとのパラメータ数を制限する

これらは「影響を緩和する」一定の効果があると考えられるのでしょうか?効果があるとした場合、具体的にどの設定をどのように変更すればよいのか、何か情報をお持ちではないでしょうか?

[回答]

上記回避策は、本セキュリティホールに一定の効果があります。但し、内容は一般事項を示しており、設定方法はアプリケーション毎に異なります。

ご質問の Tomcat は、修正プログラムを適用することにより、maxParameterCount が導入されます。
maxParameterCount は、リクエストに含まれるパラメータ数の上限を設定できます。デフォルト値は、10,000 です。この値を大きめに変更することにより、本セキュリティホールの影響を緩和することが可能です。適正な値は、サイトにより異なりますのでご調整ください。

上記内容は、コンテンツ内の対処方法上部に記載してございます。
https://sid.softek.jp/content/show/13810

ご参考までに、PHP の場合は、以下のコンテンツに記載してございます方法で設定ください。
https://sid.softek.jp/content/show/13780

▶ (例8) BIND のセキュリティホールに対する EOL バージョンへの影響の確認

[ご質問]

[SIDfm ID13576] ISC BIND のキャッシュサーバの処理に DoS 攻撃を受ける問題

本セキュリティホールの影響を受ける製品としてISC BIND9.4系,9.6系,9.7系,9.8系が記載されておりますが、9.5系や9.3系は影響を受けないとの認識でよろしいでしょうか。
サポートが終了している為に影響を受ける製品の一覧に記載が無いということはございませんでしょうか。該当する場合、お手数ではございますが、影響を受ける製品を併せてお教えいただけますでしょうか。

[回答]

はい、その通りでございます。
BIND 9.5系、BIND 9.3系およびそれ以下のバージョンは、サポートを終了しているために、セキュリティホールに対する影響の評価は行われていません。

BINDのバージョンごとの現ステータスおよびEOLは以下の表にまとめられております。
https://www.isc.org/software/bind/versions

9.5系および9.3系はそれぞれ以下の通りサポートを終了しております。

バージョン EOL
-----------------------
9.5.2-P4Sep 2010
9.3.6-P1Jan 2009

サポート終了となっています9.5系および9.3系を弊社にて、9.5系および9.3系の最終バージョンのソースプログラムで確認した結果をお知らせいたします。

9.5.2-P4 : 影響あります。
9.3.6-P1 : 影響は不明でございます。

影響ありは、以下のロジックがソースプログラム内に存在しているかで判断しております。

if (result == DNS_R_NCACHENXRRSET) {
dns_rdataset_disassociate(rdataset);
/*
* Negative cache entries don't have sigrdatasets.
*/
INSIST(! dns_rdataset_isassociated(sigrdataset));
}

なお、弊社は、サポート終了製品については掲載致しません。
これは、サポート終了製品については利用すべきではない製品であることは申し上げるまでもございませんが、ベンダーもサポート終了製品に対する情報提供および修正プログラム提供を行わないため、弊社が影響を受けるもしくは受けないの判断をできないためでございます。

▶ (例9) squid のセキュリティホールに対する EOL バージョンへの影響確認

[ご質問]

[SIDfm ID7370] Squid のキャッシュ更新の処理に DoS 攻撃を受ける問題

上記セキュリティホールについて、コンテンツに記載の無いSquid2.5系も該当するのでしょうか。

[回答]

弊社で確認した以下の情報より、2.5 系のバージョンにも影響すると判断いたします。

  • 2.5 系 のソースプログラムにも同様の処理があり、修正パッチに該当する処理が存在しない。
  • Squid の Advisory に Affected versions としてSquid 2.X (2.0 ->2.6.STABLE16) と記述されている。

参照 URL
Squid 2.5 STABLE 14 ( httpHeaderUpdate 関数 )
http://www.squid-cache.org/cgi-bin/cvsweb.cgi/squid/src/HttpHeader.c?rev=1.74.2.32&content-type=text/x-cvsweb-markup&only_with_tag=SQUID_2_5_STABLE14

Squid Proxy Cache Security Update Advisory SQUID-2007:2
http://www.squid-cache.org/Advisories/SQUID-2007_2.txt

なお、弊社は、サポート終了製品については掲載致しません。
これは、サポート終了製品については利用すべきではない製品であることは申し上げるまでもございませんが、ベンダーもサポート終了製品に対する情報提供および修正プログラム提供を行わないため、弊社が影響を受けるもしくは受けないの判断をできないためでございます。

▶ (例10) Apache のセキュリティホールに対する EOL バージョンへの影響確認

[ご質問]

[SIDfm ID5421] Apache の mod_rewrite に任意のコードを実行される問題

上記セキュリティホールの影響を受ける範囲として、下記のように記載がありました。Apache1.3.27以前のバージョンは該当しないのでしょうか。

Apache
2.2.0 - 2.2.2
2.0.46 - 2.0.55, 2.0.58
1.3.28, 1.3.29, 1.3.31 - 1.3.34

[回答]

結論から申しますと Apache の 1.3.27 以下のバージョンにつきましては、今回のセキュリティホールの影響を受けません。
セキュリティホールのあった箇所が Apache 1.3.27 のソースプログラムに存在しないことを、弊社にて確認しました。Apache 1.3.27 以下すべてのバージョンを確認した訳ではありませんが、他のバージョンも同様と思われます。
なお、弊社は、サポート終了製品については掲載致しません。
これは、サポート終了製品については利用すべきではない製品であることは申し上げるまでもございませんが、ベンダーもサポート終了製品に対する情報提供および修正プログラム提供を行わないため、弊社が影響を受けるもしくは受けないの判断をできないためでございます。