Ghostの脆弱性 - C / C ++プログラムを再コンパイルしますか？

Linuxアプリケーションは、ほぼ常にCライブラリへのダイナミックリンクを使用します。つまり、Cライブラリにコンパイルされず、ランタイムにリンクされます。これは、すでにCライブラリをアップグレードしている場合は、他の操作を実行する必要がないことを意味します。

しかし、これはまれですが、静的にリンクされたglibcを使用して何かを作成することは不可能ではありません。最良の方法は、関連アプリケーションのドキュメントを確認することです。これが慣例であれば、ほぼ確実に明らかです。

check実行可能ファイルを使用できますfile。出力に「動的接続」とマークする必要があります。私考えるこれらのバイナリが静的glibcを統合することは依然として可能ですが、これは非常にあいまいです。再確認する方法は次のとおりです。

ldd whatever | grep libc.so

whatever確認したいバイナリファイルはどこにありますか？ある程度出力を得る必要があります。そうでない場合は、ここにコメントを残してください。そうすれば、私は足りなく食べることができるでしょう。なぜなら、私は誰もこのようなものを作ると信じていないからです。

実際の静的バイナリを見つけたとしても、必ずしもglibcを使用しているわけではありません。ソースツリー、ドキュメント、または開発者に連絡してそれらを確認する必要があります。

一部の人はアプリケーションのセグフォルトのために更新を元に戻す必要があるという話を読んでいました。

私も2番目、3番目に見たことがあります。しかし、私は実際にこの状況の具体的な説明を見たことがありません。正直なところ、そうは思えません。

まず、Red Hat Enterprise Linux はパッケージベースを保存し、できるだけ長く厳しいバイナリ互換性を維持します。 2.12-1.7.el6.x86_64と2.12-1.149.el6_6.5のバージョンを分析した場合glibc（ここで.x86_64が欠落していると仮定）、両方ともアップストリームバージョン2.12であり、ローカル（RHEL）バージョンは1.7とRHELバージョンです。あります。 1.149（つまり、約142のパッチセット）の1つはel6（例：RHEL 6）用、もう1つはel6_6.5（例：RHEL 6「新しいバージョン」にバンドルされている5番目の更新ラウンド）用です。ユーザーが目立つ違いはなく、非常に似ている必要があります（当然のバグ修正を除く）。

ほとんどのプログラムはライブラリに動的にリンクされています（ディスクとメモリにはライブラリのコピーが1つだけあり、誰もが共通のシンボルを使用できるため、パフォーマンスが向上します）。ライブラリの更新後にプログラムを開始します。まれに、プログラム自体を再コンパイルする必要があります（たとえば、ヘッダーのインライン関数またはマクロが破壊的な方法で間違っていることが判明した場合など）。

静的リンカーにはライブラリのコードが含まれています（これはますますまれになっています！）できる脆弱になる壊れたコードを使用する場合図書館で。