私はXenサーバーでDebian jessieを使用していますが、この問題が心配ですCVE-2016-10229:
Linux カーネル 4.5 より前のバージョンの udp.c では、リモートの攻撃者が UDP トラフィックを介して任意のコードを実行し、MSG_PEEK フラグを指定した recv システム コールの実行中に安全でない 2 番目のチェックサム計算をトリガーする可能性があります。
サーバーとVMで問題が解決されたかどうかを確認したい
Dom0の場合:
$ uname -a
Linux xen-eclabs 4.5.0-1-amd64 #1 SMP Debian 4.5.1-1 (2016-04-14) x86_64 GNU/Linux
$ dpkg -l |grep linux-
ii linux-base 3.5 all Linux image base package
ii linux-image-3.16.0-4-amd64 3.16.39-1+deb8u2 amd64 Linux 3.16 for 64-bit PCs
ii linux-image-4.3.0-1-amd64 4.3.3-7 amd64 Linux 4.3 for 64-bit PCs
ii linux-image-4.5.0-1-amd64 4.5.1-1 amd64 Linux 4.5 for 64-bit PCs
ii linux-image-amd64 3.16+63 amd64 Linux for 64-bit PCs (meta-package)
ii xen-linux-system-4.3.0-1-amd64 4.3.3-7 amd64 Xen system with Linux 4.3 on 64-bit PCs (meta-package)
ii xen-linux-system-4.5.0-1-amd64 4.5.1-1 amd64 Xen system with Linux 4.5 on 64-bit PCs (meta-package)
ii xen-linux-system-amd64 4.5+72 amd64 Xen system with Linux for 64-bit PCs (meta-package)
サイトによると、これは jessie 3.16.39-1 の「linux」というパッケージで修正されているとのことです。
しかし、この「linux」というパッケージはどれですか? 単に「linux」と呼ばれるパッケージはインストールされていません。
このつながりをどう理解すればいいのでしょうか?
答え1
2 つの XEN Linux 対応カーネル バージョン (正確には 4.3.3-7 と 4.5.1-1) と、通常の非 XEN 製品カーネル 3.16.0-4、4.3.3-7、4.5.1-1 がインストールされています。
amd64 (64 ビット PC) 用の通常のカーネル パッケージは でlinux-image*-amd64
、XEN 対応のものは ですxen-linux-system*-amd64
。
リストに記載されている対応する XEN パッケージは次のとおりです。
xen-linux-system-4.3.0-1-amd64, 4.3.3-7
xen-linux-system-4.5.0-1-amd64, 4.5.1-1
の出力から判断するとuname
、バージョン 4.5 がアクティブであることがわかります。つまり、脆弱性はありません。
それでも、カーネル ログでは v4.5-rc1 で修正されたと記載されているのに、Debian ログでは 3.16.39-1 のみが脆弱であると記載されている場合、これは、以前行われていたように、修正が古いバージョンのソース コードにバックポートされたことを意味します。
ただし、次のコマンドを使用して、古いカーネル バージョンをいつでもアンインストールできます。
sudo dpkg --purge xen-linux-system-4.3.0-1-amd64
答え2
uname -r
インストールされているカーネルのバージョンは表示されず、「カーネルリリース」
uname -v
インストールされたバージョン
(これは の長い文字列のさらに右側にありますuname -a
)
XEN VM内のカーネルを更新する
VM の構成ファイルで、Dom0 の新しいカーネルと一致するようにパラメータを/etc/xen/*.cfg
編集する必要があります。kernel
ramdisk
それから:
1.そのうちの 1 つは Pygrub とともにインストールされます。
uname -v
#1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07)
そうすれば、通常のapt-get upgrade
Pygrub のない VM では、VM をシャットダウンして、ブート ファイルを/boot/
VM 内のフォルダーにコピーする必要がありました。
xl shutdown vmtest
mount /dev/vg0/vmtest-disk /mnt/
cp /boot/*4.5* /mnt/boot/
xen create /etc/xen/vmtest.cfg
3.
一部のVMにはブートファイルがありませんでした/boot/
が、何もせずVMを再作成しただけです。