OpenSSL脆弱性対応手順まとめ

おはこんばんにちは。

OpenSSLさんがまた脆弱性ですって(´・ε・`)?

JVNVU#92930223: OpenSSL に複数の脆弱性

私の中ではBINDさんの次に多い印象があります。

BINDの脆弱性対応手順をまとめたのにならって、今回はOpenSSLバージョンをまとめてみますね。

infragirl.hatenablog.jp

 1.OpenSSLの脆弱性の発表をキャッチする

本家が情報をわかりやすく出してくれてるようです。

脆弱性がアナウンスされた時https://twitter.com/ha4gu/status/750102197174607872の一次ソース「Security Advisory」はここですね。

ここのRSSが見つけられない…。

https://www.openssl.org/news/newslog.html

過去の脆弱性情報がまとまってるページもあるんですね。

/news/vulnerabilities.html

 

OpenSSLに限ったことではないですが、CVE,JPCERT/CC,JVNも要チェックですね!

私はNVDとかもたまに見るんですけど、JVNと微妙にCVSSスコアが違ってたりするので基本はJVNを信用してます( ´ω`)

 

あと、OpenSSLのBlogにけっこう書いてたりすることがあるようで・・・

www.openssl.org

脆弱性情報出た後にOpenSSL本家からアップデートが出なくて、

「これいつでるのかなぁ・・・」ってウジウジしてたら

「ブログに書いてあるよ」と教えていただいたことがあり、その時からBlogも見るようにしてます。

 一次ソースのチェックは大事ですね( +・`ω・)b

 

  2.自分の管轄内のOpenSSLのバージョンを調べる

バージョンを出すだけなら・・・

$ dpkg -l | grep openssl

yum list installed | grep openssl

最近知ったんですがCent OSだとアップデート可能なら黄色くなってくれるそうですね。便利(゚д゚)!

 

パッケージを使っていなくてもopensslコマンドで

バージョンを確認することができます。

$openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

 

でも・・・

それ本当に今使っているOpenSSLのバージョンなんでしょうか?

もしかしたら後からソースインストールしてるのかも!!!

ギャアァァァァ━━━━━━(|||゚Д゚)━━━━━━!!!!!!

 

lsofコマンド(どのプロセスがどのファイルを開いているのか

わかるコマンド)でopensslのライブラリを開いているプロセスを見つけましょう。

# lsof | grep ssl

・・・

fail2ban-  2565                root  mem       REG              253,4    449880    4680996/usr/lib64/libssl.so.1.0.1e

 

これで新しいほうを参照してたらOKです。

古いほうを参照してたらアップデートしてあげましょう。4へ続く。

 

ちなみに現在のstableバージョンは1.0.2系で、1.0.1系はセキュリティ上のバグ修正しかしていないんですって。

そんで、1.0.1系のサポートは2016/12/31までですって。

( ゚д゚)ナンデスト!

ソース:https://www.openssl.org/source/

   3.アップデートするかどうかを決める

BINDのときとほとんど同じことを言いますが・・・

これは、環境によって異なるのでなんとも言えない(´・ω・`)ショボーン

あとは以下の観点から判断しています。

・対象のサーバが外に出ているかどうか

→FWで守られているかどうか。外に出ているものであれば、一刻も早く対処しないといけないです。リモートで攻撃可能な脆弱性だといつ攻撃を受けるかわかりませんし。

脆弱性によって受ける影響が大きいかどうか

→これも環境によりけりですね。でも、SSLって大事な情報を守るために使われているものですし、本来守られているべきのものが情報漏えいの脆弱性あり!といわれたら

私なら最優先でアップデートかけちゃうと思います。サービス停止の脆弱性とかだとどうかな。でも、SSL使うようなサービスって大事なやり取りばかりですよね・・・。

 基本的には脆弱性にはすべて対応すべきだと思っています。ただし、実際に対応するかどうかは実際の環境や、対応にかかる工数とリスクを天秤にかけて、上司や客先と相談して判断しています。

  4 .OpenSSLをアップデートする

パッケージならアップデートしてあげればOKですね。

アップデート後は、OpenSSLのライブラリを参照しているプロセスが

本当に新しいライブラリを参照しているかlsofコマンドで確認してあげてください。

必要に応じてプロセスのサービスも再起動しましょう。

 

Σ(゚д゚) エッ!? OSがサポート切れ?パッケージが提供されない?

<丶´Д`>ゲッソリ しますね。

 

OpenSSLのサイトからソースをインストールしましょう。

そんで、opensslのライブラリを参照しているプロセスが、新しいバージョンのライブラリを参照するようにがんばりましょう。

(サービス再起動でそううまいこといってくれなくて、筆者はソースapacheのconfigureからやり直したことがあります。超めんどくさかった)

ソースからアップデートの方法については、参照するプロセスによって

大きく違いそうですし、筆者はapacheしかやったことないので割愛します。

 

ながくなりましたが私はこんな感じでOpenSSL脆弱性対応をしています。

間違いやこうしたらいいよ!という意見などありましたら@infragirl755までリプライいただけると幸いです。

 

2016/11/29 追記

このエントリを見た方が、この件についてより掘り下げたブログ記事を書いてくださいました。

 

OpenSSLに限らず、パッケージ管理についてどう付き合って行くべきかという視点で書かれており、とてもためになる記事でした( •̀ᄇ• ́)ﻭ✧

 

お兄様さん‪(@phase_d ‬)ありがとうございました!