CVEと二乗確率

約1年前の2019年7月、OpenVzのRHEL7ベースのカーネルに関する奇妙なバグレポートの受信を開始しました。一見したところ、バグは異なっていました。ノードはさまざまな場所で、さらにはさまざまなサブシステムでクラッシュしましたが、調査のたびに1つまたは別の「曲がった」オブジェクトが見つかりました。オブジェクトは異なり、ある種のゴミが見つかったり、解放されたメモリへの参照が見つかったり、オブジェクト自体が解放されたりしましたが、すべての場合、このオブジェクトのメモリはkmalloc-192キャッシュから割り当てられました。カットの下で-この物語についての詳細な物語。







このような場合の通常のトラブルシューティングは、影響を受けるオブジェクトのライフサイクルを注意深く調べることです。エラーパスに特に注意して、メモリがどのように割り当てられているか、どのように解放されているか、参照カウンターがどのように正しく取得および解放されているかを確認します。ただし、私たちの場合、さまざまなオブジェクトがキャプチャされ、それらのライフサイクルをチェックしてもバグは見つかりませんでした。



kmalloc-192キャッシュはカーネルで非常に人気があり、数十の異なるオブジェクトを組み合わせています。そのうちの1つのライフサイクルのバグが、この種のバグの最も可能性の高い理由です。そのようなオブジェクトをすべてリストするだけでも非常に問題があり、すべてをチェックすることに疑問の余地はありません。バグレポートは引き続き届きましたが、直接調査しても原因を特定することはできませんでした。ヒントが必要でした。



私たちの側から、これらのバグは、メモリアクセスエラーをキャッチするための素晴らしいテクノロジーであるKASANの開発者としてカーネル開発者の狭いサークルで広く知られているメモリ管理スペシャリストであるAndreyRyabininによって調査されました。 実際、私たちのバグの原因を発見するのに最も適したのはKASANでした。 KASANは元のRHEL7カーネルには含まれていませんでしたが、Andreyは必要なパッチをOpenVzに移植しました。カーネルの製品バージョンにはKASANは含まれていませんでしたが、カーネルのデバッグバージョンには含まれており、QAがバグを見つけるのに積極的に役立ちます。















KASANに加えて、デバッグカーネルには、RedHatから継承した他の多くのデバッグ機能が含まれています。デバッグの結果、カーネルはかなり遅いことが判明しました。 QAによると、デバッグカーネルでの同じテストには4倍の時間がかかります。私たちにとって、これは基本的なことではなく、そこでパフォーマンスを測定するのではなく、バグを探します。ただし、このような速度低下はお客様には受け入れられず、デバッグカーネルを本番環境に移行するという当社の要求は常に拒否されました。



KASANの代わりに、影響を受けるノードでslub_debugを有効にするようにクライアントに依頼しました..。このテクノロジーにより、メモリの破損を検出することもできます。各オブジェクトにレッドゾーンとメモリポイズニングを使用して、メモリアロケータは、メモリを割り当てて解放するたびに、すべてが正常であるかどうかを確認します。何か問題が発生した場合は、エラーメッセージを発行し、検出された損傷を可能であれば修正し、カーネルが動作を継続できるようにします。さらに、オブジェクトを最後に割り当てて解放した人に関する情報が保存されるため、メモリ破損の事後検出の場合、このオブジェクトが「過去の人生」にあった「誰」を理解することができます。 Slub_debugは、実稼働カーネルのカーネルコマンドラインで有効にできますが、これらのチェックはメモリとcpuリソースも消費します。開発およびQAデバッグの場合、これは問題ありませんが、実稼働クライアントはあまり熱心に使用しません。



半年が経ち、新年が近づいていました。 KASANを使用したデバッグカーネルでのローカルテストでは問題は検出されませんでした。slub_debugが有効になっているノードからバグレポートは受信されませんでした。原材料に何も見つからず、問題も見つかりませんでした。アンドレイは他のタスクを積んでいましたが、それどころか、ギャップがあり、次のバグレポートを分析するように指示されました。



クラッシュダンプを分析した後、問題のあるkmalloc-192オブジェクトをすぐに発見しました。そのメモリは、ある種のゴミ、別のタイプのオブジェクトに属する情報でいっぱいでした。解放後の使用の結果と非常に似ていましたが、原材料の損傷したオブジェクトのライフサイクルを注意深く調べたところ、疑わしいものは何も見つかりませんでした。



私は古いバグレポートを調べて、そこにいくつかの手がかりを見つけようとしましたが、役に立ちませんでした。



最終的に私は自分のバグに戻り、前のオブジェクトを見始めました。また、使用されていることが判明しましたが、その内容からは完全に理解できませんでした。定数、関数または他のオブジェクトへの参照はありませんでした。このオブジェクトへの数世代の参照を追跡した後、私は最終的にそれがより縮小されたビットマップであることに気付きました。このオブジェクトは、コンテナメモリを解放するための最適化手法の一部でした。このテクノロジーはもともと私たちのカーネルのために開発されましたが、後にその作者であるKirillTkhaiがそれをLinuxメインラインにコミットしました。



「結果は、パフォーマンスが少なくとも548倍に向上することを示しています。」



数千のそのようなパッチは、元の安定したRHEL7カーネルを補完し、Virtuozzoカーネルをホスティング業者にとって可能な限り便利にします。可能な限り、開発内容をメインラインに送信するようにしています。これにより、コードを良好な状態に維持しやすくなります。



リンクをたどると、ビットマップを説明する構造が見つかりました。記述子は、ビットマップのサイズは240バイトである必要があると考えていましたが、実際にはオブジェクトはkmalloc-192キャッシュから割り当てられていたため、これはまったく当てはまりませんでした。



ビンゴ！



ビットマップを操作する関数は、上限を超えてメモリにアクセスし、次のオブジェクトの内容を変更する可能性があることが判明しました。私の場合、オブジェクトの先頭にrefcountがあり、ビットマップがそれを無効にすると、その後のプットによってオブジェクトが突然解放されました。その後、メモリが新しいオブジェクトに新たに割り当てられ、その初期化は古いオブジェクトのコードによってガベージとして認識され、遅かれ早かれ必然的にノードのクラッシュにつながりました。





コードの作成者に相談できると便利です。



キリルとの彼のコードを見ると、検出された不一致の根本的な原因がすぐに見つかりました。コンテナの数が増えると、ビットマップも増えるはずですが、ケースの1つを省略したため、サイズ変更ビットマップをスキップすることがありました。ローカルテストでは、この状況は見つかりませんでした。Kirillがメインラインに送信したパッチのバージョンでは、コードが再設計され、バグはありませんでした。



4回の試行で、Kirillと私は協力してこのようなパッチを作成し、1か月間ローカルテストで実行し、2月末に固定カーネルのアップデートをリリースしました。私たちは他のクラッシュダンプを選択的にチェックし、近所で間違ったビットマップを見つけ、勝利を祝い、静かな場所で古いバグを書き留めました。



しかし、老婆はどんどん落ちていきました。これらの種類のバグレポートの細流は縮小しましたが、完全に枯渇していません。



一般的に、これは予想されていました。私たちのクライアントはホスティング業者です。再起動==ダウンタイム==お金を失ったので、彼らはノードの再起動を強く嫌います。また、カーネルを頻繁にリリースすることも好きではありません。アップデートの公式リリースはかなり面倒な手順であり、さまざまなテストを実行する必要があります。したがって、新しい安定したカーネルは約四半期ごとにリリースされます。



クライアントの生産ノードにバグ修正を迅速に配信するために、ReadyKernelライブパッチを使用しています。私の意見では、私たち以外の誰もこれをしません。 Virtuozzo 7は、ライブパッチを使用するために通常とは異なる戦略を使用しています。



通常、lifepatchはセキュリティのみです。私たちの国では、修正の3/4はバグ修正です。お客様がすでに遭遇した、または将来簡単に遭遇する可能性のあるバグの修正。事実上、そのようなことは配布キットに対してのみ行うことができます。ユーザーからのフィードバックがなければ、ユーザーにとって何が重要で何が重要でないかを理解することは不可能です。



ライブパッチは確かに万能薬ではありません。一般に、すべてを連続してパッチすることは不可能です。このテクノロジーでは許可されていません。新しい機能もこの方法で追加されません。ただし、バグの大部分は、ライフパッチに最適な最も単純な1行のパッチで修正されています。より複雑なケースでは、元のパッチを「ファイルで作成的に変更」する必要があり、ライブパッチの仕組みにバグがある場合もありますが、ライフパッチウィザードのZhenyaShatokhinは彼の仕事を完全に知っています。最近、例えば、彼は発掘しましたkpatchの魅惑的なバグ。これについては、正当な理由から、通常は別のオペラを書く価値があります。



適切なバグ修正が蓄積されると、通常は1〜2週間に1回、Zhenyaは別の一連のReadyKernelライブパッチを起動します。リリース後、彼らは即座にクライアントノードに飛んで、私たちがすでに知っているレーキへの攻撃を防ぎます。そして、クライアントノードを再起動せずにこれらすべて。そして、不必要にカーネルを頻繁にリリースします。継続的なメリット。



ただし、ライブパッチがクライアントに到着するのが遅すぎることがよくあります。クローズする問題はすでに発生していますが、それでもノードはまだクラッシュしていません。



そのため、すでに修正した問題を含む新しいバグレポートの出現は、私たちにとって予想外ではありませんでした。それらを何度も解析すると、おなじみの症状が現れました。古いカーネル、kmalloc-192のガベージ、その前の「間違った」ビットマップ、および修正されたアンロードまたは遅延ロードされたライブパッチです。



そのようなケースの1つは、FastVPSのOVZ-7188で、2月末に私たちに届きました。 「バグレポートをありがとうございました。お悔やみ申し上げます。既知の問題とすぐに非常に似ています。 OpenVZにライブパッチがないのは残念です。安定したカーネルのリリースを待つか、Virtuozzoに切り替えるか、バグ修正のある不安定なカーネルを使用してください。」



バグレポートは、OpenVZが提供する最も価値のあるものの1つです。それらを調査することで、太ったクライアントが介入する前に深刻な問題を見つける機会が得られます。したがって、既知の問題にもかかわらず、クラッシュダンプを入力するように依頼しました。



それらの最初のものを解析することは私を幾分落胆させました：「曲がった」kmalloc-192オブジェクトの前の「間違った」ビットマップは見つかりませんでした。



少し後、問題は新しいカーネルで再現されました。そして、別の、別の、そして別の。

おっと！

どうして？未修正？原材料を再確認しました。すべて問題なく、パッチが適用され、何も失われていません。



再び腐敗？同じ場所で？



私はそれをもう一度理解しなければなりませんでした。





（これは何ですか？ここを参照してください）



新しいクラッシュダンプのそれぞれで、調査は再びkmalloc-192オブジェクトに遭遇しました。一般に、そのようなオブジェクトは非常に正常に見えましたが、オブジェクトの最初に、毎回間違ったアドレスが見つかりました。オブジェクトの関係を追跡すると、アドレスの2つの内部バイトが無効になっていることがわかりました。

in all cases corrupted pointer contains nulls in 2 middle bytes: (mask 0xffffffff0000ffff)
0xffff9e2400003d80
0xffff969b00005b40
0xffff919100007000
0xffff90f30000ccc0

リストされた最初のケ​​ースでは、「間違った」アドレス0xffff9e2400003d80の代わりに、「正しい」アドレス0xffff9e24740a3d80が必要でした。他の場合にも同様の状況が見られました。



いくつかの無関係なコードが2バイトでオブジェクトを無効にしたことが判明しました。最も可能性の高いシナリオは、解放後の使用です。オブジェクトが解放された後、最初のバイトの一部のフィールドがゼロになります。最も頻繁に使用されるオブジェクトを確認しましたが、疑わしいものは見つかりませんでした。再び行き止まり。



FastVPS私たちの要求で、KASANを使用してデバッグカーネルを1週間実行しましたが、それは役に立ちませんでした。問題は再現されませんでした。 slub_debugの登録を依頼しましたが、再起動が必要で、処理に時間がかかりました。 3月から4月に、ノードはさらに数回クラッシュしましたが、slub_debugがオフになっており、これによって新しい情報が得られませんでした。



そして、落ち着きがあり、問題の再現が止まりました。 4月が終わり、5月が過ぎました-新しい滝はありませんでした。



待機は6月7日に終了しました。最終的に、slub_debugを有効にして問題がコアに発生しました。 slub_debugオブジェクトを解放するときにレッドゾーンをチェックしているときに、上限を超えた2つのゼロバイトが見つかりました。言い換えれば、それは解放後の使用ではなく、前のオブジェクトが再び原因であることが判明しました。通常の外観の構造体nf_ct_extがありました。この構造は、ファイアウォールが使用するネットワーク接続の説明である接続追跡を参照します。



しかし、なぜこれが起こったのかはまだ明らかではありませんでした。



私はconntrackを覗き始めました：誰かが開いているポート1720でipv6を使用してコンテナの1つをノックしました。ポートとプロトコルで、対応するnf_conntrack_helperを見つけました。

static struct nf_conntrack_helper nf_conntrack_helper_q931[] __read_mostly = {
        {
                .name                   = "Q.931",
                .me                     = THIS_MODULE,
                .data_len               = sizeof(struct nf_ct_h323_master),
                .tuple.src.l3num        = AF_INET, <<<<<<<< IPv4
                .tuple.src.u.tcp.port   = cpu_to_be16(Q931_PORT),
                .tuple.dst.protonum     = IPPROTO_TCP,
                .help                   = q931_help,
                .expect_policy          = &q931_exp_policy,
        },
        {
                .name                   = "Q.931",
                .me                     = THIS_MODULE,
                .tuple.src.l3num        = AF_INET6, <<<<<<<< IPv6
                .tuple.src.u.tcp.port   = cpu_to_be16(Q931_PORT),
                .tuple.dst.protonum     = IPPROTO_TCP,
                .help                   = q931_help,
                .expect_policy          = &q931_exp_policy,
        },
};

構造を比較すると、ipv6ヘルパーが.data_lenを定義していないことに気付きました。私はそれがどこから来たのかを理解するためにgitに入り、2012年のパッチを発見しました。



commit 1afc56794e03229fa53cfa3c5012704d226e1dec

作成者：Pablo Neira Ayuso <pablo@netfilter.org>

日付：Thu Jun 7 12:11:50 2012 +0200



netfilter：nf_ct_helper：可変長ヘルパープライベートデータの実装



このパッチは、新しい可変長conntrack拡張機能を使用します。



すべての

ヘルパープライベートデータ情報を含むユニオンnf_conntrack_helpを使用する代わりに

、プライベートヘルパーデータを格納するために可変長領域を割り当てます。



このパッチには、既存のすべてのヘルパーの変更が含まれています。

また、コンパイルを回避するために、いくつかのincludeヘッダーが含まれています

警告。



パッチにより、ヘルパーに新しい.data_lenフィールドが追加されました。これは、対応するネットワーク接続ハンドラーに必要なメモリ量を示しています。パッチは、その時点で利用可能なすべてのnf_conntrack_helpersに対して.data_lenを定義することになっていたが、私が見つけた構造を見逃していた。



その結果、ipv6を介したオープンポート1720への接続がq931_help（）関数を起動し、誰もメモリを割り当てていない構造に書き込んだことが判明しました。単純なポートスキャンで数バイトが無効になり、通常のプロトコルメッセージの送信により構造がより意味のある情報でいっぱいになりましたが、いずれにせよ、他の誰かのメモリが擦り切れ、遅かれ早かれこれがノードのクラッシュにつながりました。



Florian Westphalは、2017年にコードを再設計しました.data_lenを削除すると、私が発見した問題は見過ごされました。



現在のLinuxカーネルのメインラインでバグが検出されなくなったにもかかわらず、問題は、現在のRHEL7 / CentOS7、SLES 11および12、Oracle Unbreakable Enterprise Kernel 3および4、Debian 8および9、およびを含む多数のLinuxディストリビューションのカーネルに継承されました。 Ubuntu14.04および16.04LTS。



バグは、カーネルと元のRHEL7の両方のテストノードで簡単に再現されました。明示的なセキュリティ：リモート管理されたメモリの破損。 1720 ipv6ポートが開いている場所-事実上、死のping。



6月9日、あいまいな説明を含む1行のパッチを作成し、メインラインに送信しました。詳細な説明をRedHat Bugzillaに送信し、Red HatSecurityに個別に書き込みました。



私の参加なしにさらなるイベントが展開されました。

6月15日、ZhenyaShatokhinは古いカーネル用のReadyKernelライブパッチをリリースしました。

https://readykernel.com/patch/Virtuozzo-7/readykernel-patch-131.10-108.0-1.vl7/



6月18日に、VirtuozzoとOpenVzで新しい安定したカーネルをリリースしました。

https://virtuozzosupport.force.com/s/article/VZA-2020-043



6月24日、Red HatSecurityはCVEIDをバグに割り当てました

https://access.redhat.com/security/cve/CVE-2020-14305



問題異常に高いCVSSv3スコア8.1で中程度の影響を受け、次の数日間で他の

SUSEディストリビューションがパブリックハットバグhttps://bugzilla.suse.com/show_bug.cgi?id=CVE-2020-14305

Debian https：/ /security-tracker.debian.org/tracker/CVE-2020-14305

Ubuntuhttps://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-14305.html



7月6日、KernelCareは影響を受けるディストリビューションのライブパッチをリリースしました。

https://blog.kernelcare.com/new-kernel-vulnerability-found-by-virtuozzo-live-patched-by-kernelcare



7月9日に、この問題は安定したLinuxカーネル4.9.230および4.4.230で修正されました。

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.9.y&id=396ba2fc4f27ef6c44bbc0098bfddf4da76dc4c9



ただし、ディストリビューションはまだ穴を塞いでいません..。



「ほら、コスティア」と私はパートナーのコスティア・コレンコに言います。「私たちの殻は同じ火口に2回当たった！前回nepoymiに会ったとき、私と1人のオブジェクトの終わりを超えたアクセスがあり、ここで2回続けて訪問しました。教えてください、それは二乗確率のようなものですか？または正方形ではありませんか？

-確率は二乗です、はい。しかし、ここであなたは見なければなりません-どのようなイベントが確率ですか？異常なバグが2回続けて発生したイベントの二乗確率。並んでいます。



さて、コスティアは賢いです、彼はよく知っています。