Oracle Java SE 2016年4月 Critical Patch Update サーバーへの影響調査
2016年4月 Oracle Java SE のクリティカルパッチアップデートのサーバーへの影響をRedHatの情報を元に調査をしてみた。
所感
JMXを外部にListenしていない限り、緊急性・影響は低い
情報ソース
サーバーが対象になる物
http://www.oracle.com/technetwork/security-advisory/cpuapr2016v3-2985753.html#AppendixJAVA で、Notesの2,3なので以下の3つ
- CVE-2016-3427 JMX BaseScore 9.0 (CVSS v3)
- CVE-2016-0695 JSSE BaseScore 5.9 (CVSS v3)
- CVE-2016-3425 JAXP BaseScore 5.3 (CVSS v3)
CVE-2016-3427
https://access.redhat.com/security/cve/CVE-2016-3427
- critical
- 6.8
- AV:N/AC:M/Au:N/C:P/I:P/A:P
It was discovered that the RMI server implementation in the JMX component in OpenJDK did not restrict which classes can be deserialized when deserializing authentication credentials. A remote, unauthenticated attacker able to connect to a JMX port could possibly use this flaw to trigger deserialization flaws.
JMX port にアクセスされると認証無しで色々と悪さをされる
https://bugzilla.redhat.com/show_bug.cgi?id=1328210
unrestricted deserialization of authentication credentials (JMX, 8144430)
JMX のポートを公開していなければ大丈夫だろう
CVE-2016-0695
https://access.redhat.com/security/cve/CVE-2016-0695
- low
- 2.6
- AV:N/AC:H/Au:N/C:P/I:N/A:N
説明無し
https://bugzilla.redhat.com/show_bug.cgi?id=1328022
OpenJDK: insufficient DSA key parameters checks
It was discovered that the Security component of OpenJDK failed to properly check DSA (Digital Signature Algorithm) parameters. The use of keys with incorrect parameters could lead to disclosure of sensitive data.
Related note in Oracle JDK release notes: DSA signature generation is now subject to a key strength check For signature generation, if the security strength of the digest algorithm is weaker than the security strength of the key used to sign the signature (e.g. using (2048, 256)-bit DSA keys with SHA1withDSA signature), the operation will fail with the error message: "The security strength of SHA1 digest algorithm is not sufficient for this key size." JDK-8138593 (not public)
DSA署名作る際に弱いハッシュアルゴリズムを選択してもエラーでない
CVE-2016-3425
https://access.redhat.com/security/cve/CVE-2016-3425
- moderate
- 4.3
- AV:N/AC:M/Au:N/C:P/I:N/A:N
It was discovered that the JAXP component in OpenJDK failed to properly handle Unicode surrogate pairs used as part of the XML attribute values. Specially crafted XML input could cause a Java application to use an excessive amount of memory when parsed.
悪意のあるXMLを処理させると膨大なメモリを消費する→DoSられる 信頼出来ない相手からのXMLを処理しているとDoSられる可能性がある
OpenSSL の脆弱性 CVE-2015-1793 の主要Linuxディストリビューションでの影響を確認して見た
OpenSSL の脆弱性 CVE-2015-1793 の主要Linuxディストリビューションでの影響を確認して見た https://www.openssl.org/news/secadv_20150709.txt
主要Linuxディストリビューションでの影響を確認して見た
リリース版で影響があるのはAmazon Linuxとfedoraくらい
- RedHat/CentOS
- Amazon Linux
- https://alas.aws.amazon.com/ALAS-2015-564.html
- 影響あり : openssl-1.0.1k-10.86.amzn1
- fedora
- Debian
- https://security-tracker.debian.org/tracker/CVE-2015-1793
- 影響なし(開発版 stretch は影響あり)
- Ubuntu
CVE-2015-3331 Kernel: crypto: buffer overruns in RFC4106 implementation using AESNI メモ
- JVNDB-2015-002838
JVNではギョッとするScoreなので簡単に調べて見た
基本値: 9.3 (危険) [NVD値] 攻撃元区分: ネットワーク 攻撃条件の複雑さ: 中 攻撃前の認証要否: 不要 機密性への影響(C): 全面的 完全性への影響(I): 全面的 可用性への影響(A): 全面的
定番のRedHat CVEデーターベースを見てみると、、、 https://access.redhat.com/security/cve/CVE-2015-3331
- Intel AES-NI 最適化された RFC4106 GCM mode 復号関数にバッファーフローが脆弱性がある。
- RFC4106 は、https://tools.ietf.org/html/rfc4106 IPSecの一部でAES-GCM modを規定
ってことで、Intel AES-NI を使っていて、AES-GCM mode IPSec を使っている場合にのみ、影響がある
とりあえず問題なさそうだ
経産省の営業秘密管理指針(平成27年1月全部改訂版)より秘密管理処置をまとめてみた
- 営業秘密管理指針(平成27年1月全部改訂版)
- (不正競争防止法 営業秘密 ~営業秘密を守り活用する~ http://www.meti.go.jp/policy/economy/chizai/chiteki/trade-secret.html より)
から、主に秘密管理性について簡単にまとめてみた。
※あっているかどうかは知らないよ
営業秘密管理指針ってなに?
不正競争防止法で保護を受けるために必要となる最低限の対策 ※法的拘束力を持つ物ではない ※漏洩対策としては全く不十分な物なので注意!!
営業秘密の定義(不正競争防止法)
以下の三要件を満たす物
- 秘密管理性
- 有用性
- 非公知性
秘密管理性
- 秘密管理処置によって秘密管理意思が明確に示され、秘密情報である、と認識出来る事が必要
- ※秘密であると単に主観的に認識しているだけでは不十分
- 具体的状況に応じた経済合理的な秘密管理処置によって明確に示され、容易に認識できる事が必要
秘密管理処置の考え方
原則
認識可能性が胆。認識可能性を秘密管理処置で実現する事が要件。アクセス制限は認識可能性の実現方法の1つと考える。(アクセス制限されていれば、秘密情報だと認識できるよね、という考え方)
要素
合理的区分と、営業秘密であることを明らかにする処置からなる
- 合理的区分
- 一般情報と営業秘密を区分する
- 媒体一つ一つに表示を求める物ではない。紙であればファイル、電子媒体ならフォルダー単位などでも合理的区分になる
- 営業秘密であることを明らかにする処置
- 一般情報とは取り扱いが異なるべき、という規範意識が生じる程度の取り組み
- 媒体の選択・表示・接触する物の制限・対象のリスト化など
形骸化
形骸化に注意!
- 例えば、秘密表示をしているが、情報の内容の多くが当然に一般情報と認識出来る場合、など
秘密管理処置の具体例
紙媒体
- 当該文章に「マル秘」などを表示
- 当該文章を保管しているファイルに「マル秘」などを表示
- 施錠可能なキャビネットや金庫等に保管
※どれか1つで良い
電子媒体
- 記録媒体に「マル秘」などを付記。または記録媒体を保管するケース・箱に「マル秘」などを貼付
- ファイル名・フォルダ名に「マル秘」などを付記
- 電子ファイルを開いた場合に、画面に「マル秘」が表示されるように電子データー上に「マル秘」などを付記(ヘッダーなど)
- 電子ファイルそのもの、またはフォルダーの閲覧に必要なパスワードを設定
※どれか1つで良い
物件そのものが営業秘密の場合
製造機械・金型・試作品など。物理的に「マル秘」などの表示や金庫等の保管に適さない物
- 扉に「関係者以外立ち入り禁止」の貼り紙をする
- 警備員や入館IDカードゲートなどで部外者の立ち入りを制限する
- 写真撮影禁止の貼り紙
- 物件をリスト化。リストを閲覧・共有化する
ProFTPd CVE-2015-3306 mod_copy脆弱性のメモ
ちょっと前に公開された、ProFTPD の mod_copy モジュールにおける任意のファイルを読み書きされる脆弱性を調べてみた
なんといっても「基本値: 10.0 (危険) [NVD値] 」なので気になる
概要
-
- http://jvndb.jvn.jp/ja/contents/2015/JVNDB-2015-002727.html
- ProFTPD の mod_copy モジュールにおける任意のファイルを読み書きされる脆弱性
- 基本値: 10.0 (危険) [NVD値]
SBTの調査:とても詳しい。何がおきるかはとにかくここ見ればよい!!!
元情報
mod_copy moduleの説明は
修正版
配布元では、修正版はまだリリースされていない
- http://bugs.proftpd.org/show_bug.cgi?id=4169
- ※暫定patchはgithubで公開されている
ディストリビューションでは修正版出てきている
- debian : https://www.debian.org/security/2015/dsa-3263
- ubuntu : まだ(2015/05/22) http://www.ubuntu.com/usn/
- fedora, EPEL : https://bugzilla.redhat.com/show_bug.cgi?id=1212386 : fedora, epel 共にUpdate済RHEL : 元からない(EPELを利用)
調査
結果
- RedHat系 (ferora, EPEL) ではデフォルトの設定だと、mod_copy は無効になっている(loadしていない)
- SITE CPFR, SITE CPTO なんてまず使わないので、わざわざ有効にする事もまずなさそう
- ※EPEL6 (CentOS6, RHEL6)だと、mod_copy自体が入っていない
公式最新版で試してみる
http://www.proftpd.org/docs/ 1.3.5
ソースからのmakeの場合、デフォルトのconfigure ではmod_copyは入らない
CentOS 6 (EPEL6)だと
epel6 のProFTPdでも mod_copy は有効になっていない ※インストール自体されていない
/usr/libexec/proftpd% ls mod_ban.so mod_ifsession.so mod_quotatab_sql.so mod_sftp_pam.so mod_sql_passwd.so mod_wrap2_sql.so mod_ctrls_admin.so mod_load.so mod_radius.so mod_sftp_sql.so mod_tls_shmcache.so mod_exec.so mod_quotatab.so mod_ratio.so mod_shaper.so mod_wrap.so mod_facl.so mod_quotatab_file.so mod_rewrite.so mod_site_misc.so mod_wrap2.so mod_geoip.so mod_quotatab_radius.so mod_sftp.so mod_sql.so mod_wrap2_file.so /usr/libexec/proftpd% ls | grep copy
って、EPEL6は1.3.4だから入っていないのか(mod_copyが入ったのは1.3.4から)
fedora でupdateがでているのは、、、、 https://admin.fedoraproject.org/updates/ より fc20,21,22,el7
EPEL 7 (RHEL7, CentOS7) のSRPMを見てみる
デフォルトのconfだとloadしていない
proftpd.confから抜粋
# SITE CPFR and SITE CPTO commands (analogous to RNFR and RNTO), which can be # used to copy files/directories from one place to another on the server # without having to transfer the data to the client and back # (http://www.castaglia.org/proftpd/modules/mod_copy.html) # LoadModule mod_copy.c
実際に使えない
$ telnet localhost 21 Trying ::1... Connected to localhost. Escape character is '^]'. 220 FTP Server ready. site cpfr /etc/passwd 500 'SITE CPFR' not understood quit 221 Goodbye. Connection closed by foreign host.
Logjam メモ
今のところのLogjamのメモ
元情報
https://weakdh.org/
ニュースサイト
http://www.itmedia.co.jp/enterprise/articles/1505/21/news055.html
http://japan.zdnet.com/article/35064803/
サーバーの確認は
https://weakdh.org/sysadmin.html
でできる
TLSプロトコルの仕様でDiffie-Hellman key exchangeに対してDowngrade攻撃できる
DHE_EXPORT (512bit) にされると即死。
DHE_EXPORTは無効であることが必須
768bitだと学術機関
1024bitでも国家機関
だと解読出来る可能性あり。
通常は1024bitになっている
なので2040bitがお勧め
あと Forward Secrecy もね
最低限必要なのは、DHE_EXPORT を無効にすること
Foward Secrecy は OpenSSL 1.0.0以下だとできないか
FREAK対策でEXPORTが無い事は全て確認済なので問題ないはず
ELBは公式で
https://forums.aws.amazon.com/ann.jspa?annID=3061
最新のポリシーではDHEそのものを無効にしている!
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-security-policy-table.html
これでどれくらいクライアントに影響あるんだろう
どこかで最新のポリシーでの SSL Test結果が見てみたいね
サーバーがクライアントになるパターンは、、、どうやって対応する?
OpenSSLで無効にならないと対応辛い。
OpenSSL自体がDHE_EXPORTなどEXPORTグレードのcipherをサポートしているかどうかの確認
openssl ciphers -s EXP -v
OpenSSLのBlog
https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/
今後のバージョンでデフォルト設定を安全にしていく
使いたくない暗号化方式を落として openssl をビルドする方法
http://qiita.com/docokano/items/b3e4e61eeb9b53cca167
cURL および libcurl のデフォルト設定における重要な情報を取得される脆弱性(CVE-2015-3153)の内容
cURL および libcurl のデフォルト設定における重要な情報を取得される脆弱性(CVE-2015-3153)
- CVE-2015-3153
- JVNDB-2015-002535 http://jvndb.jvn.jp/ja/contents/2015/JVNDB-2015-002535.html
- http://curl.haxx.se/docs/adv_20150429.html
の内容を簡単に確認してみた
Security Advisory : sensitive HTTP server headers also sent to proxies http://curl.haxx.se/docs/adv_20150429.html を読むと、、、
CURLOPT_HTTPHEADERや、コマンドラインの --header でカスタムHTTPヘッダーをつけられるけど、デフォルト設定だとProxyにも送ってしまう。
HTTPS CONNECT Proxyでも同様なので、付与したカスタムHTTPヘッダーに秘匿すべき情報(認証情報など)が入っているとProxyの管理者にもそれが見えてしまう。 ※
今回の修正7.42.1で、デフォルト設定でProxyにはカスタムHTTPヘッダーを送らないようになる。
問題となるのは、カスタムHTTPヘッダーに秘匿すべき情報(認証情報など)を入れている場合。
なお CURLOPT_COOKIE (または '--cookie' オプション) 又は HTTP auth オプションは元からこの問題はない(Proxyには送らない)ので、CURLOPT_HTTPHEADER(または '--header' オプション)を使っている場合のみ、問題となる
わざわざカスタムHTTPヘッダーで認証情報などを付与することはまずしないだろうから、実際に影響がある利用方法をしていることは少ないと思われる