Oracle Java SE 2016年4月 Critical Patch Update サーバーへの影響調査

security java

2016年4月 Oracle Java SE のクリティカルパッチアップデートのサーバーへの影響をRedHatの情報を元に調査をしてみた。

所感

JMXを外部にListenしていない限り、緊急性・影響は低い

  • JMXを外部にListenしている場合にはすぐ対策必要
  • 信頼出来ない相手からのXMLを処理しているとDoSられる可能性があるので対策必要

情報ソース

サーバーが対象になる物

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ディストリビューションでの影響を確認して見た

linux security openssl

OpenSSL の脆弱性 CVE-2015-1793 の主要Linuxディストリビューションでの影響を確認して見た https://www.openssl.org/news/secadv_20150709.txt

主要Linuxディストリビューションでの影響を確認して見た

リリース版で影響があるのはAmazon Linuxとfedoraくらい

CVE-2015-3331 Kernel: crypto: buffer overruns in RFC4106 implementation using AESNI メモ

linux security

JVNではギョッとするScoreなので簡単に調べて見た

     基本値: 9.3 (危険) [NVD値]

        攻撃元区分: ネットワーク
        攻撃条件の複雑さ: 中
        攻撃前の認証要否: 不要
        機密性への影響(C): 全面的
        完全性への影響(I): 全面的
        可用性への影響(A): 全面的

定番のRedHat CVEデーターベースを見てみると、、、 https://access.redhat.com/security/cve/CVE-2015-3331

ってことで、Intel AES-NI を使っていて、AES-GCM mode IPSec を使っている場合にのみ、影響がある

とりあえず問題なさそうだ

経産省の営業秘密管理指針(平成２７年１月全部改訂版）より秘密管理処置をまとめてみた

security 営業秘密 情報区分 不正競争防止法 legal

から、主に秘密管理性について簡単にまとめてみた。

※あっているかどうかは知らないよ

営業秘密管理指針ってなに？

不正競争防止法で保護を受けるために必要となる最低限の対策 ※法的拘束力を持つ物ではない ※漏洩対策としては全く不十分な物なので注意！！

営業秘密の定義（不正競争防止法）

以下の三要件を満たす物

  • 秘密管理性
  • 有用性
  • 非公知性

秘密管理性

  • 秘密管理処置によって秘密管理意思が明確に示され、秘密情報である、と認識出来る事が必要
  • ※秘密であると単に主観的に認識しているだけでは不十分
  • 具体的状況に応じた経済合理的な秘密管理処置によって明確に示され、容易に認識できる事が必要

秘密管理処置の考え方

原則

認識可能性が胆。認識可能性を秘密管理処置で実現する事が要件。アクセス制限は認識可能性の実現方法の1つと考える。（アクセス制限されていれば、秘密情報だと認識できるよね、という考え方）

要素

合理的区分と、営業秘密であることを明らかにする処置からなる

  • 合理的区分
    • 一般情報と営業秘密を区分する
    • 媒体一つ一つに表示を求める物ではない。紙であればファイル、電子媒体ならフォルダー単位などでも合理的区分になる
  • 営業秘密であることを明らかにする処置
    • 一般情報とは取り扱いが異なるべき、という規範意識が生じる程度の取り組み
    • 媒体の選択・表示・接触する物の制限・対象のリスト化など

形骸化

形骸化に注意！

  • 例えば、秘密表示をしているが、情報の内容の多くが当然に一般情報と認識出来る場合、など

秘密管理処置の具体例

紙媒体

  • 当該文章に「マル秘」などを表示
  • 当該文章を保管しているファイルに「マル秘」などを表示
  • 施錠可能なキャビネットや金庫等に保管

※どれか1つで良い

電子媒体

  • 記録媒体に「マル秘」などを付記。または記録媒体を保管するケース・箱に「マル秘」などを貼付
  • ファイル名・フォルダ名に「マル秘」などを付記
  • 電子ファイルを開いた場合に、画面に「マル秘」が表示されるように電子データー上に「マル秘」などを付記（ヘッダーなど）
  • 電子ファイルそのもの、またはフォルダーの閲覧に必要なパスワードを設定

※どれか1つで良い

物件そのものが営業秘密の場合

製造機械・金型・試作品など。物理的に「マル秘」などの表示や金庫等の保管に適さない物

  • 扉に「関係者以外立ち入り禁止」の貼り紙をする
  • 警備員や入館IDカードゲートなどで部外者の立ち入りを制限する
  • 写真撮影禁止の貼り紙
  • 物件をリスト化。リストを閲覧・共有化する

ProFTPd CVE-2015-3306 mod_copy脆弱性のメモ

security linux proftpd

ちょっと前に公開された、ProFTPD の mod_copy モジュールにおける任意のファイルを読み書きされる脆弱性を調べてみた

なんといっても「基本値: 10.0 (危険) [NVD値] 」なので気になる

概要

修正版

調査

結果

  • 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を見てみる

proftpd-1.3.5-5.el7.src.rpm

デフォルトの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 メモ

security ssl tls

今のところの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）の内容

security linux

cURL および libcurl のデフォルト設定における重要な情報を取得される脆弱性（CVE-2015-3153）

の内容を簡単に確認してみた

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ヘッダーで認証情報などを付与することはまずしないだろうから、実際に影響がある利用方法をしていることは少ないと思われる