バグレポート| 2022年1月

オミクロンはギリシャのアルファベットでは15番目の文字です。ドナルド・クヌースがBig-O notationを示すのに使い、プトレマイオスの書「アルマゲスト」ではゼロを表し、isopsephy（アイソセフィー）では70という値を持っていました。しかし、ほとんどの人にとっては、単なる「ひたすら、いつまでたっても、おわらない」パンデミックを意味するだけでしょう。2022年1月に最も多く使われたこの単語について、哲学的なことを話したくあはりませんか。脆弱性の情報収集のため記事を訪れたのですね。わかりました、内容の濃い1月のバグレポートをお届けしましょう。

• CVE-2022-0185:なぜなら、inputのバリデーションを忘れるのはJava開発者だけではないからです
• CVE-2021-42392: Log4shellが終わると本気で思ってました?
• CVE-2022-21907: 小さいwarmも忘れてはいけません
• CVE-2021-4034: PwnKit。Sudoを不十分だと判断したらどうなるでしょう

CVE-2022-21907: HTTP.sysのワーム化するバグ

豆知識：PoC は こちらの GitHub を参照してください

豆知識をもう一つ：すでに悪用され始めています！脅威について最新の情報を知りたければ、McAfee Insightsは必見です。

IISだけがHTTP.sysを使用しているように見えるかもしれませんが、実際のところ、このケースではそうではありません。HTTP.sys は、core HTTP を処理するコードを提供しているカーネル ドライバーです。他のサブシステムで次のコードを使用します：

• ADFS
• WinRM
• インテル® ドライバー & サポート・アシスタント

これにより、現在システムで実行されているリクエストキューとそれに関連する URLが一覧表示されます。

幸いなことに、Server 2019やWindows 10 1809のアップデートを気にかけていなかった人は、レジストリでトレーラーサポートを有効にしない限り問題ないでしょう。

• Windows 10 2004 以降 (both ARM、 x64)
• Windows Server 20H2 以降

対処法：

とにかくパッチです。Microsoftは公表と同時に脆弱性に対するパッチをリリースしました。パッチが適用できない場合は、インターネットに接続できないようにすることが望ましいです。残念ながら、現在のWindowsのバージョンでは、適用可能なホストベースの緩和策はありません。

Windows Server 1909 または Windows 10 1809 を実行している場合、デフォルトでは脆弱性はありません。脆弱性のステータス確認をする場合は、以下のとおり実行してください。

返された値が0でない場合、あなたのシステムは脆弱です。これを緩和するには、次のとおり実行してください。

もしくは、単純にレジストリキーを削除してください。

模範的な対応：

適用可能なパッチが用意されているのは良いニュースです。ぜひとも適用してください！もし仮に、パッチを適用できないなんらかの事情があるとしても悩まないでください。Trellixはこの脆弱性に対するNSP (ネットワークセキュリティプラットフォーム)のシグネチャを提供しています。ともかく、署名データベースを更新しているかということは、最低限、確認しましょう！

CVE-2021-42392: Log4Shellを狙うH2

対処法：

H2データベースのバージョン 1.1.100 から 2.0.204が影響を受けます。2022年1月5日以降のバージョン2.0.206では、脆弱性を修正済です。少なくともバージョン2.0.206へのアップデートが理想的です。

データベースエンジンを変更することもできますが、これはかなり極端な解決方法だと思われます。宿主を殺して病気を治すというやり方は、医学の世界と同様、ITの世界でも推奨されない行為です。

Javaの利用をやめますか？上記と似ているように思えますが、こちらは正解です。現実問題として、明らかにこれが最善策です。Javaはサーバーの中にあるべきではなく、コーヒーカップの中にあるべきです。

• ENS (Endpoint Security)のエキスパートルールにより、メモリ内の危険なパターンをピックアップすることができます。こちらのブログで紹介しています。
• ENS (Endpoint Security)、VSE (VirusScan Enterprise)、MWG (McAfee Web Gateway) は Potentially Unwanted Softwareの検出でExploit-CVE-2021-44228.C というタイルで汎用検出を提供できます。また、この脆弱性を悪用しているキャンペーンに関連したハッシュのサンプルのリストによって、検出を補強します。
• NSP (Network Security Platform) でも、ユーザー定義シグネチャにより、この攻撃を検出可能です。 (既出のナレッジベースの記事のリンク先にて提供) 
• EDR (MVISION Endpoint Detection and Response), MAR (McAfee Active Response) も、RTS (リアルタイム検索) クエリで脆弱なシステムの検知に使われています。
• McAfee SIEMにアップデート（Exploit Content Pack version 4.1.0）され、潜在的なエクスプロイトの試みに対しても警告するようになりました。

CVE-2022-0185: Linux kernel namespace のアンダーフロ......

過去を振り返りすぎると、それは進歩を遅らせることになります。この世のあらゆる素晴らしいものからゆっくりと精気を奪います。つまり、たいていの場合、後方互換性のせいで素敵なものと巡り合えなくなってしまうのです。

対象：

コンテナを動かしている人なら誰でも、潜在的に対象となりうるでしょう。そして、ユーザーにコンテナの実行を許可している管理者も同様です。更には、お持ち帰りのテイクアウトでコンテナを使う人さえも対象になる可能性があります。少し過剰反応してしまいましたが、少なくとも、共有サーバー上でコンテナを実行している人は、しっかりとこのことを留意する必要があります。基盤のカーネルがアップデートされたとわかるまでは、サーバーからミッションクリティカルなものが削除される可能性があります。この脆弱性に関する詳細なブログ記事でPoC codeを公開しています。この時点では、悪意あるアクターがこの脆弱性を武器化するのは時間の問題です。私たちは皆、注意しなくてはなりません。

対処法：

もしあなたがホストをコントロールしているならば、カーネルをアップデートする必要があります。それが不可能な場合 (所有者が拒否している場合など) は、次のように実行してください。

 CAP_SYS_ADMIN 権限を持つコンテナのみに、この脆弱性を制限します。または、コンテナからこの権限を削除することで、この脆弱性は緩和できます（デフォルトではオフになっています）。

Redhatは、コンテナを実行しないシステムに対して、単純にnamespaceを完全に無効化することを推奨しています：

これで、そのホストはコンテナを実行できない状態になります。これは、コンテナを使わないのであれば、おそらく、とりあえずは良いアイデアだと思います。

模範的な対応：

この時点では、パッチを当てるか、緩和策を適用するのが最善の方法です。コンテナは分離メカニズムで使用されるため、外部プロセスが実行中のコンテナを可視化することはまずありません。パッチを適用したホストで実行するか、k8s で seccomp フィルタを有効にしてください。

CVE-2021-4034: PwnKit

CVE-2021-4034、通称PwnKitは、PolKit（かつては、PolicyKitとして知られていました）のロジックバグを利用します。PolKitは、システム全体のポリシー管理キットで、特権プロセスへ特権のないプロセスを安全に（少なくとも安全だと信じられていた）アクセスできるようにします。特にこのバグはpkexecというツールに存在します（何らかの理由でsudoでは不十分であり、sudoと全く同じことをする、別のsetuidプログラムの必要性を感じたため） – 仮説ではargc変数が少なくとも1です。典型的なプログラム呼び出しでは、当然明白なことです。ほぼ間違いなく情報漏洩の兆候なので、ランタイムによって拒否されるべきなのですが、逃れる方法があるのです…

これは、この6か月間で2つ目のpolkitの脆弱性です。CVE-2021-3560も、polkitの呼び出しにdbusメカニズムを使用してクレデンシャルチェックを回避します。どちらも同じルートの欠陥が利用されているようです。ついでにお話すると、2013年に最初の報告されましたが、この作者は直接的なパスを見いだせず悪用されませんでした。そのため、この哀れなパッチはに見放されたまま、輝く日を待っていたのです。9年という長い歳月を経てスイートパッチで輝きましょう! 日の目を見せてあげませんか。

対象：

これは、昨年の最大級のローカル権限昇格バグと呼んでもよさそうですね？この脆弱性は、古いpolkitバイナリを実行しているほとんどの主要なLinuxディストリビューションで動作するので、1月25日以降にパッチを適用していないLinuxを実行している人すべてが、脆弱な状態にさらされています。Debian は独自のフォークを保守しているため、polkit のバージョン番号は少し複雑です。

もし、

• 0.105-26ubuntu1.2 on Ubuntu 20.04 (LTS)以前,
• 0.105-31ubuntu0.1 on Ubuntu 21.10以前,
• 0.105-31+deb11u1 on Debian bullseye以前, もしくは
• polkit-0.115-11.el8_4.2 on RedHat Enterprise Linux (RHEL) 8.4 EUS以前

であるならば、脆弱な状態にあります。繰り返しになりますが、1月25日以降にパッチを適用していない場合は脆弱性が存在します。また、PoC codeが公開されているので、これが積極的に悪用される日も近いでしょう。

全てのユーザーを信頼しているのですか？それなら心配することはありませんね。今にも、アカウントを侵害できる状態にしているのですね。ユーザーを信用しているにしても、フィッシングかクラッキングか何による侵害かにかかわらず、どこかの侵害されたアカウントと認証情報を共有しているユーザーのアカウントまで信用して良いという話にはならないはずですが。

このバグはLinuxで発見されましたが、BSDを含む他のUNIXディストリビューションでもpolkitが使用されています。少なくとも OpenBSD では、argc が 0 のプログラムの実行を拒否するなど、常にこのバグに対する緩和策を講じています。 Solaris も polkit を使用していますが、Oracle は Solarisに関して秘密主義であり、セキュリティ情報さえも有料です。顧客を手放さないためには良い方法ですけどね！

対処法：

アップデートです。パッチは主要なLinuxベンダーから提供されています。すぐに適用する必要があります。再起動は必要ありません。もしパッチを当てないという選択をするのであれば、pkexecのsetuidビットを削除しましょう。

残念ながら、これでpkexecは本来設計された機能は失いますが、情報漏洩よりはマシだと思いませんか？

RedHatのsecurity bulletinは、RHEL に特化した緩和策を掲載しています。

模範的な対応：

すべてのLinuxディストリビューションが調整してリリースしたものなので、本当にただ適用すれば良いだけです。変則的なログインの起点は記録し、フラグを立て、他にも認証がない場合はできる限りブロックするよう、指摘しておきます。多要素認証を使用していますよね？MFAは外部から脅威がシステムにアクセスできないよう、悪用を阻止します。内部からのインサイダー脅威に関しては、そうですね、読者への課題としておきます。