web-dev-qa-db-ja.com

新しいバージョンがapt-getで利用できない場合、Ubuntu zlibパッケージのCVEを修正/修正するにはどうすればよいですか？

Ubuntu 14.04.2を実行している複数のクラウドスタックがあり、zlibライブラリ（具体的にはzlib1gおよびzlib1g-devで公開されているCVEを修正する必要があります。これらのシステムをUbuntuのより新しいバージョンに移行しますが、ブロッカーをアップグレードに解決するまで、既存のCVEを軽減する必要があります。

  • システムパッケージをアップグレードするためのベストプラクティスは何ですか？
  • 機能の退行をテストする方法を壊す/どのように心配する必要がありますか？

私が現在テストしているのは、Ubuntuのより新しいバージョンのソースを追加することです（例：artful）：

Sudo cp /etc/apt/sources.list /etc/apt/sources.list.d/artful.list
Sudo vim /etc/apt/sources.list.d/artful.list  # replace "trusty" with "zesty"
Sudo apt-get update

すべてのパッケージをtrustyに固定します：

$ cat /etc/apt/preferences

Package: *
Pin: release n=trusty
Pin-Priority: 900

Package: *
Pin: release o=Ubuntu
Pin-Priority: -10

次に、特定のパッケージを次のものでアップグレードします。

apt-get install --only-upgrade <package> -t zesty

アップグレードする必要があるパッケージ：zlib1g/zlib1g-dev

システムパッケージをアップグレードしても、CVEが解決されたバージョンのzlib1gを取得できません。バージョンが必要です> = 1:1.2.8.dfsg-4最も近いのは、おそらくzestyからの1:1.2.11.dfsg-0ubuntu1です。見る：

$ dpkg -s zlib1g | grep Version:
Version: 1:1.2.8.dfsg-1ubuntu1

$ Sudo apt-get update && apt-get upgrade

$ dpkg -s zlib1g | grep Version:
Version: 1:1.2.8.dfsg-1ubuntu1

/etc/apt/sources.listのコンテンツ：

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.

deb http://archive.ubuntu.com/ubuntu/ trusty main restricted
deb-src http://archive.ubuntu.com/ubuntu/ trusty main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb-src http://archive.ubuntu.com/ubuntu/ trusty-updates main restricted

## Uncomment the following two lines to add software from the 'universe'
## repository.
## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://archive.ubuntu.com/ubuntu/ trusty universe
deb-src http://archive.ubuntu.com/ubuntu/ trusty universe
deb http://archive.ubuntu.com/ubuntu/ trusty-updates universe
deb-src http://archive.ubuntu.com/ubuntu/ trusty-updates universe

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
# deb http://archive.ubuntu.com/ubuntu/ trusty-backports main restricted
# deb-src http://archive.ubuntu.com/ubuntu/ trusty-backports main restricted

deb http://archive.ubuntu.com/ubuntu/ trusty-security main restricted
deb-src http://archive.ubuntu.com/ubuntu/ trusty-security main restricted
deb http://archive.ubuntu.com/ubuntu/ trusty-security universe
deb-src http://archive.ubuntu.com/ubuntu/ trusty-security universe
# deb http://archive.ubuntu.com/ubuntu/ trusty-security multiverse
# deb-src http://archive.ubuntu.com/ubuntu/ trusty-security multiverse
securityapt
7
Ryan Fisher

パッチを適用したいものや、特定のリリースでそのソフトウェアがUbuntuリポジトリのどのポケットに入っているかについての詳細がなければ、十分に狭い完全な答えを出すことは不可能です。

しかし、Ubuntuパッケージのセキュリティ問題を「パッチ」する方法の概要を説明します。

Mainのソフトウェアパッケージ、および$RELEASE-security repositories経由のUniverseのコミュニティ提供のパッチ

ユニバースパッケージのセキュリティチームが検討するためにユーザーがパッケージで送信したセキュリティパッチ、およびUbuntuメインパッケージのセキュリティチームがセキュリティパッチを送信した場合、リリース後は$RELEASE-securityリポジトリから入手できます（たとえば、xenial-security）および$RELEASE-updatesリポジトリ。この方法では、Sudo apt-get update && Sudo apt-get dist-upgradeを実行するだけで、すべてのパッチを取得できます。

CVE Tracker で個々のCVEを追跡すると、CVEのUbuntuでの修正がまだリリースされているかどうか、およびCVEの優先度レベルとそれがどの程度迅速に対処する必要があるかをSEcurityチームが判断できます（CVEの重大度に関係なく、デフォルトは「中」です）。

リポジトリで更新されていないパッケージ

ここには2つの問題があります。第一に、ユニバースパッケージは、セキュリティチームが調査およびレビューするためにコミュニティから提供された場合にのみパッチを取得します。第二に、結果として多数のパッケージが更新されません。

これらの問題に対する2つの解決策があります。パッチを使用してパッケージを自分で再構築するか、リポジトリにアップデートが到着するのを待つ（またはセキュリティチームに誰かがパッチを提出する）。

最初の解決策では、ステップ1からステップ3.9までの パッケージングガイド を実行し、リポジトリ用にサブミットし、パッチを適用したパッケージをビルドする場合はセクション6で詳細に説明するステップに従う必要があります。システム上でローカルにインストールします。

このための実際のプロセスは、パッケージによって非常に非常に複雑なので、ここで答えることはできません。

カスタムコンパイルされたソフトウェア

ここでの唯一の希望は、ソフトウェアにパッチを適用し、再コンパイルしてインストールすることです。これは、ソフトウェアがリポジトリに含まれていない場合、または最初にコンパイルしたものがインストールされている場合に使用します。そのプロセスは無限に多様であるため、ここで答えることはできません。

3
Thomas Ward

修正する必要のあるCVEがあり、使用しているリリースの公式リポジトリで修正されていない場合、何をすべきかnot doは、任意の将来のリリースからパッケージをダウンロードしてインストールします。そのようなパッケージmayは問題なくインストールできますが、既存の他の既存のソフトウェアがそれらと相互運用できるという保証はありません。 ABIまたはAPIが変更された可能性があります。微妙な変更で、デバッグが困難なバグが発生する可能性があります。 （ライブラリが期待どおりにロードされない場合、コマンドのファイルが明らかに存在していても、コマンドラインアプリはfile-not-foundエラーをスローする可能性があります！）

私が提案するのは：

  1. 使用しているバージョンのパッチが、他の場所のCVEレポートで、またはアップストリームから入手できるかどうかを確認します。
  2. ある場合は、関連するパッケージのソースパッケージをダウンロードして変更します。 apt-getでインストールしたパッケージのソースコードを取得および変更するにはどうすればよいですか？
    • quiltを使用してパッチを適用します（ Debian wiki 、または this Debian hwoto を参照）。
    • バージョン番号の最も重要でない部分（最後の-の後の部分）のみをバンプすることをお勧めします-エポック番号である最初の:の前の部分をバンプしないでください。
  3. ビルドされたパッケージをインストールします。

これにより、OSの他のコンポーネントとの互換性が維持される可能性が高くなり（修正自体が問題を引き起こさない限り）、アップデートがリリースのリポジトリにヒットした場合でもアップグレードできます。このようにして、修正したい特定のCVEが特定できる限り修正されることを保証できます。これは、将来の任意のリリースのパッケージには当てはまらない可能性があります。

1
muru

これが私の最初のスタートアップでのやり方です。

  1. カスタムのベースDockerイメージを使用して、アプリケーションをマイクロサービスにパッケージ化しました。マイクロサービスはすべてNode.jsに基づいていたため、それが基盤でした
  2. Kubernetes/Docker Composeを使用してこれらのサービスをstage/prod環境にデプロイしました
  3. これらのDockerイメージをcloud.docker.comに保存しました。これには、イメージ内を見て関連するCVEを見つけるNice Dockerイメージスキャナーがあります。

これが、関連するCVEに到達した方法です。それから

  1. CVEを読んで、どれが適用されているかを確認します。これらの4つのCVEは次のようになります。
    • zlib 1.2.8のinftrees.cでは、不適切なポインター演算を利用して、コンテキスト依存の攻撃者が不特定の影響を与える可能性があります。
    • zlib 1.2.8のinffast.cでは、不適切なポインター演算を利用して、コンテキスト依存の攻撃者が不特定の影響を与える可能性があります。
    • Zlib 1.2.8のinflate.cのinflateMark関数により、コンテキスト依存の攻撃者が負の整数の左シフトを含むベクトルを介して不特定の影響を与える可能性があります。
    • Zlib 1.2.8のcrc32.cのcrc32_big関数により、コンテキスト依存の攻撃者がビッグエンディアンCRC計算を含むベクトルを介して不特定の影響を与える可能性があります。

私にとって「不特定」および「コンテキスト依存」とは、これがかなり理論的な攻撃であることを意味します。これは、多くのお金を持っている悪者が、誰かを破ろうとしている通常の悪人とは対照的に、yoに侵入したいことを意味します。あなただけがあなたのリソースを置くのに最適な場所を知っています。

私の場合、ユースケースに当てはまらないChrome CVE（ChromeはNode.jsのベースです）があったため、アップストリームの修正を待つことを無視しました。すぐに修正が必要なことがあったので、次のようにしました。

  1. Dockerイメージを更新しました。すべてのマイクロサービスがカスタムのベースDockerイメージで開始されたため、NodeおよびOSの更新を比較的迅速にプッシュできました。
  2. ステージにデプロイし、ステージでテストをスモークし、本番にデプロイします。

私はここで他の答えを支持しました-あなたが探しているものを手に入れることができれば幸いです。

1
Michael Cole