| 導入 | Linuxカーネルはローカル権限昇格の欠陥を修正しましたが、Red Hat、Canonical、Debian ディストリビューションなどのいくつかの上流ディストリビューションはまだアップデートをリリースしていません。管理者は、Linux サーバーおよびワークステーション自体の脆弱性を軽減する計画を立て、計画されている更新リリースを監視する必要があります。 |
カーネルの欠陥は依然として存在します
Linux カーネル 4.10.1 (CVE-2017-2636) の n_hdlc ドライバー (drivers/tty/n_hdlc.c) の競合状態の欠陥により、n_hdlc.tbuf にアクセスするときに n_hdlc_release() で二重エラーが発生する可能性があります。これはロシアの欠陥です。技術研究者のアレクサンダー・ポポフ氏が報告した。権限のないローカル ユーザーがこの欠陥を悪用して、影響を受けるシステム上で追加の権限を取得したり、tty デバイス上で HDLC 回線ルールを設定してサービス拒否状態を引き起こしたりする可能性があります。
この脆弱性の基本スコアは、共通脆弱性スコアリング システム (CVSS) 3.0 に基づいて 7.8 です。ユーザーの操作によってトリガーされる必要はありません。攻撃の複雑さは低いと考えられます。この脆弱性を悪用するには、専用のハードウェアや周辺機器を攻撃する必要はありません。ターゲットシステム。この脆弱性は、CVSS では重大度が高いと考えられています。
このパッチは 2 月 28 日に Linux カーネルに送信され、カーネルの新しいバージョンは 3 月 7 日にリリースされました。Linux カーネルのすべてのバージョン (4.10.1 まで) には脆弱性があると考えられています。
この脆弱性は Linux サーバーとワークステーション、仮想マシンに影響しますが、ほとんどのコンテナは影響を受けません。オープンソースセキュリティ企業Black Duck SoftwareのPatrick Carey氏は、Dockerのioctl設定により、この問題はコンテナ内では実行されないと述べた。明らかに、コンテナー ホストにアクセスできる場合は、すべてが偶然に任せられます。
パッチを待っています
Red Hat はこの問題の重大度を「高」と評価し、将来のアップデートでバグを修正することを約束しています。この問題は、Red Hat Enterprise MRG 2 に付属のリアルタイム カーネル パッケージ、Red Hat Enterprise Linux 7 に付属の kernel-rt パッケージ、および Red Hat Enterprise Linux 5/6/7 に付属のカーネル パッケージに影響します。 Red Hat Enterprise Linux 5 に同梱されているカーネル パッケージ。 Linux カーネル パッケージ。
Canonical はまた、すべての Ubuntu バージョンが影響を受けるため、この問題の重大度を高と評価しており、同社は Ubuntu Linux 12.04 LTS、14.04 LTS、Ubuntu 16.04 LTS (Xenial Xerus)、および Ubuntu 16.10 (Yakket Yak) 用のパッチをリリースしました。Ubuntu Core 15.04 および Ubuntu Linux 17.04 (Zesty Zapus) のアップデートはまだ保留中です。Canonical は、linux-ti-omap4 パッケージ (12.04 LTS 用) や linux-gke (16.04 LTS) などの一部のカーネル パッケージを更新しましたが、linux-magro パッケージ (14.04 LTS 用) などの他のパッケージを更新する予定はありません。 ）。この修正は、14.04 LTS の linux-lts-vivid や 17.04 の linux-rapi2 などの他のパッケージに含める必要があります。管理者は、Canonical の完全なリストを参照して、カーネルと配布のステータスを確認する必要があります。
sparc、s/390、powerpc、mips、ia-64、ua-32、arm、amd64、Debian wheezy 3.2.78-1、jessie 3.16.39-1、.13-1 の Linux カーネル用のさまざまな Debian Linux 6.0 パッケージ比較的壊れやすいです。Debian jessie の最新バージョン 3.16.39-1 + deb8u2 および wheezy の最新バージョン 3.2.86-1 には、すでに修正されたカーネル モジュールが含まれています。
Linux 管理者は何をすべきでしょうか?
Linux 管理者は、更新されたカーネルが利用可能になるまでカーネルのロードを手動で防止することで、この脆弱性を軽減できます。then_hdlc カーネル モジュールは通常、アプリケーションがユーザー空間から HDLC ライン ルールを使用しようとすると自動的にロードされますが、システム全体の modprob ルールを使用してブロックできます。rootとして実行
#echo「n_hdlc / bin / true をインストール」>> /etc/modprobe.d/disable-n_hdlc.conf
モジュールの偶発的または意図的なロードを防ぎます。n_hdlc モジュールがロードされている場合は、システムを再起動する必要があります。Red Hat Product Security は、これがモジュールの誤ったロードを防ぐための信頼できる方法であると考えています。
カーネル構成に CONFIG_N_HDLC=m が設定されている Linux ディストリビューションは、脆弱なドライバーを使用しているため、影響を受ける可能性があります。Popov 氏は、教師なしLinux システム コールファジング ツール syzkaller を使用してカーネル クラッシュの疑いを調査しているときにこのバグを発見しました。この脆弱性は、n_hdlc がデータ バッファとして自家製の単一リンク リストを使用し、エラー後にバッファを再送信するために n_hdlc.tbuf ポインタを使用するという事実に関連しています。何らかの理由でデータバッファを送信できない場合、アドレスは n_hdlc.tbuf に保存され、次回 hdlc_send_frames() が呼び出されたときに初めてバッファが送信されます。flux_tx_queue() と hdlc_send_frames() はバッファを tx_free_buf_list に 2 回入れ、二重エラーを引き起こします。
この脆弱性は広く使用されているオープンソース コンポーネントに存在しますが、コミュニティや組織もセキュリティ問題の解決に積極的に取り組んでおり、Linux ユーザーは Linux カーネルの修復状況に細心の注意を払う必要があります。