Posted on

【S2お茶会】セキュリティ勧告/CVEを読んでみる(6/26)

s2お茶会
なかなか天気が良くならず、気持ちも晴れません。一刻も早く梅雨が明けてほしいです。

今回は弊社の栗山が「セキュリティ勧告/CVEを読んでみる」という話をしました。

セキュリティ勧告/CVEを読んでみる


サーバー管理において「どのセキュリティアップデートは早急に適用しなければいけないのか」を判断するには、それぞれのセキュリティ勧告を読んだ上で影響を把握する必要があります。
勧告文書から、関連するCVEなどの情報のたどり方、それぞれの情報の読み方について説明します。

セキュリティ勧告


サーバーを管理する中でセキュリティ的な問題が発生すると、各ソフトウェアベンダーからセキュリティ勧告が発行されます。

セキュリティ勧告(Security Advisory)

ソフトウェアベンダーが発行するセキュリティ関連の書類のこと。
security notice や security bulletin と言ったりもする。


書かれている内容は、概要、問題の背景、影響範囲、簡易的な対処法、抜本的な解決方法などです。

OS やソフトウェアのユーザーは、基本的にはこれらを確認した上で、環境に影響がある場合はパッチを当てる、パッケージをアップグレードする、などの対処を行います。

しかし、かなりの数のパッケージについて脆弱性が日々報告されており、これらには些細なものもあれば、深刻なものもあります。
また、使い方によっては影響がない場合もあるので、それぞれ見極めながら対応していかなければなりません。

下に各ソフトウェアベンダーから発行されているセキュリティ勧告をまとめてみました。
アクセスした先で確認できるのでよかったら現物を見てみてください。
大体どこもフォーマットは同じです。
Microsoftのみ更新が2018年から止まっています…。

CVE (Common Vulnerabilities and Exposures)


昨今の OS には、共通の OSS(オープンセキュリティソース) が使われていることも多く、そこに脆弱性が発見された場合は、各 OS で似たようなセキュリティ勧告が発行されます。 そのような脆弱性に対して、一意な識別子として発行されるのが CVE です。
IPAには、共通脆弱性識別子と訳されています。

元々は米国国土安全保障省からの委託で MITRE 社が運用していたのですが、あまりにも脆弱性の規模が大きくなってきてしまったため、実際の採番はMITRE社に加えてコミュニティやベンダーからの担当者により行われているようです。

識別子は CVE-2014-7169 のような形式になります。
CVEは識別子としての役割が主なので、あまり情報量はありません。
中身は概要とリファレンス、日付などぐらいです。
修正方法などはそれぞれのセキュリティ勧告に委ねられています。

こちらがCVEのサンプルです。

脆弱性対応の流れ


色々なケースがありますが、一例としてあるユーザーが zsh の脆弱性を見つけた場合の話をすると、

  1. セキュリティ関連は非公開の報告手段があることが多いのでそこから見つけた人が報告
  2. 開発者が問題を確認
  3. それが対象なら CVE 番号を割り当ててもらう
  4. 修正方法の検討、実装、公開予定日を決める
  5. OSベンダーのセキュリティ担当者にも連絡。段取りを調整
  6. パッチを VCS にコミットして、セキュリティ勧告を発行、CVE 公開、アナウンス
  7. OSベンダーは事前準備しておいたパッケージを更新、それぞれのセキュリティ勧告を発行
  8. CVE 内の参照を随時更新

大体このような流れになります。

例 : docker の脆弱性


では実際どのようにセキュリティ勧告やCVEを読み解いているのでしょうか。
こちらから一つ選んで見てみましょう。

https://alas.aws.amazon.com/ALAS-2020-1376.html

リンクは Amazon Linux 1 の Docker の脆弱性に対するセキュリティ勧告(ALAS)です。

Amazon Linux

アマゾン ウェブ サービス(AWS)より提供されている Linux サーバーオペレーティングシステム。Linux ベースのアプリケーションを開発および実行する際に使用される。

Docker

Docker社が開発している、コンテナ仮想化を用いてアプリケーションを開発・配置・実行するためのオープンソースソフトウェアあるいはオープンプラットフォーム。


これを見ると、CVE が一つ書かれていますが、一つのセキュリティ勧告に複数のパッケージ、CVE が含まれていることもあります。一回のアップデートでそれらに対応するパッチが全て含まれたものとして適用されます。

重要なのは Severity で、ALAS では Important, Medium, Low として分類されます。
ここでは Important になっていますが、本当に重要かどうかは使われ方に依存するので注意が必要です。

Overviewを読むと、
 An attacker in a container, with the CAP_NET_RAW capability, can craft IPv6 router advertisements, and consequently spoof external IPv6 hosts, obtain sensitive information, or cause a denial of service.

https://alas.aws.amazon.com/ALAS-2020-1376.html

CAP_NET_RAW capability が付いたコンテナー(--privileged でも同様) 内の攻撃者が、 IPv6 ルーター広告を作ることができる。と書いてあります。

これがどういう影響を及ぼすかは他の知識が無いと難しいのですが、つまり、同一サブネット内で別のホスト向けのパケットを自ホストに誘導することが可能になり、その結果、偽装や邪魔ができる、という影響があります(多分)。
これに DNS への攻撃や SSL 証明書への攻撃を組み合わせると、より気づかれにくい騙しが可能になります。

このセキュリティ勧告には CVE へのリンクがありますが、実はこれは RedHat 社の CVE 解説ページへのリンクです。 Amazon Linux のベースが CentOS/Fedora で、RedHat Enterprise Linux も強く絡んでいるので、多くのパッチは RedHat と同じものとなっています。

こちらがそのページです。

RedHat はこれを Moderate Impact と診断していますね。
先ほどの Severity 部分に相当するのですが、RedHat では Critical, Important, Moderate, Low の4つに分類されます。
ここでは「そんなにシビアじゃないね」という判断です。

Mitigation は緩和策です。
訳すと「信用できないコンテナーには CAP_NET_RAW を着けるな」という真っ当なことが書いてあります。

続いて、Affected Packages and Issued Red Hat Security Errataを見ると、影響を受けるのは RHEL7 の Docker パッケージだけで、現状は修正されたパッケージは発行されていない、ということがわかります(お茶会時点)。

その下にある Common Vulnerability Scoring System (CVSS) Score Details というのはスコアリング指標です。

  • どこから攻撃可能であるか (AV: Attack Vector)
  • 攻撃に必要な条件の複雑さ (AC: Attack Complexity)
  • 攻撃に必要な特権レベル (PR: Privileges Required)
  • 攻撃に必要なユーザー関与レベル (UI: User Interaction)
という攻撃条件と、

  • スコープ (authorization scope)
  • 機密性への影響 (C: Confidentiality Impact, 情報漏えいの可能性)
  • 完全性への影響 (I: Integrity Impact, 情報改ざんの可能性)
  • 可用性への影響 (A: Availability Impact, 業務停止の可能性)

という影響範囲を元に、ベーススコアが算出されます。
表を見ると、Red Hat と NVDと2つあると思うのですが、NVDはアメリカ国立標準技術研究所が判断したベーススコアです。
これはRed Hatが自社のプロダクトの場合での影響を考慮に入れて、スコアデータを変更する場合があるので、参考として別の判断のスコアデータを表示するようにしているみたいです。

右上には追加情報があり、RHEL のバグ管理データベースである Bugzilla へのリンクと、その下の CWE は Common Weakness Enumeration という、脆弱性の種類に対して識別子を割り当て、どういうタイプの脆弱性なのかを分類したリンクがあります。

実際の運用


実際の運用では、勧告の影響を受けるものが出てくるとサーバーごとにアラートが上がるような仕組みにしています。
OS ごとに出てくるのでだいたい週に 2, 3 件のペース。

勧告の情報を元に、それぞれのサーバーやサービス、アプリケーションの特性を考慮して、すぐに対応を始めるのか、影響の少ないタイミングを待って適用するのか、はたまた実質的な影響はないという判断の元で次のメンテ時にまとめてやればよい、などの優先度を付けていきます。
そしてそれをそれぞれ Issue として整理します。

どのサービスがどういう OSS をどういう形で使っているのか、という情報と、勧告内の影響範囲・攻撃方法の情報から、この案件はこう、こっちはこう、と分類していくのは骨が折れる作業ではありますが、事件が起こってしまうと困るので慎重に、かつ迅速に対応していき、完了したら Issue クローズ、となります。

何も問題が起こらないことを維持するための仕事なのでどうしても地味になりますが、運用には欠かすことのできない部分です。



以上が、主にLinux関連でどういうふうにセキュリティ勧告が出されていて、それにどうやって対応しているのかという話でした。
昔に比べると様々な攻撃方法が増えてきているので、適宜モダンな環境にアップデートして、攻撃に対処できるようにしておきましょう。

今週のお茶菓子

Facebook Twitter Google
gai

About author

gai

Follow me:
View my other posts