各実行可能ファイルのビルドを確認し、すべての.oファイルを逆アセンブルします。 Linuxディストリビューションの他の場所でxz型バックドアを見つける方法は? [閉鎖]

各実行可能ファイルのビルドを確認し、すべての.oファイルを逆アセンブルします。 Linuxディストリビューションの他の場所でxz型バックドアを見つける方法は? [閉鎖]

xz5.6.0(version and)コマンドを使用してリリースされたバックドアについて読みました5.6.1
悪意のあるコミッタは管理者の信頼を取得し、いくつかのコードをビルドに挿入します。sshdをターゲットにしてバックドアを作成する

すべてのLinuxディストリビューションの他のファイル.oも同じバックドアの影響を受ける可能性があります。
悪意のあるコミッタがここで正常に行ったことは、他の場所でも実行できます。おそらく数年前でしょう...

Linuxディストリビューションの設計者が
これらのバックドアを喜んで削除したい場合は、破損した実行可能ファイル(変換されたビルドプロセスによって生成されたもの)をどのように見つけ続けるのですか?

これまでに見た方法は次のとおりです。

  1. 生成されたすべてのLinuxコマンドのすべてのビルドプロセスを確認してください。
    確認する必要があるgitリポジトリがたくさんあるようです。

  2. また、既存の.oファイルをそれぞれ分解し
    、対応するアセンブリコードを調べて、実行可能ファイルが実行する必要がある作業と一致していることを確認してください。

このバックドアを追跡するにはどのような方法を使用する必要がありますか?

ベストアンサー1

あなたの2.オプションは実行可能ではなく、1.オプションを含める必要があります。 「何をすべきか」とは何か、どうすればわかりますか?はい、ソースコードには何をすべきかが示されています。ただし、最新のバイト/マシンコードの分解は、それを生成するために使用された元のC / C ++ / rust / ...コードとはほとんどまったく異なります。 libreoffice calcを分解して、それがOfficeスイートのスプレッドシートエディタコンポーネントであり、「日付による並べ替え」機能がこれを1時間以内に実行することを確認することはできません。非常に簡単なものを見つけるには数時間かかり、多くの経験が必要であり、ツールは、liblzmaのように複雑なライブラリ全体ではできず、Firefoxのように複雑なライブラリでは100年以内にもできないはずです。

したがって、他の方向を確認する必要があります。私が得ている機械語コードは、レビューされたソースコードを実際に翻訳しましたか?

ソースコードをオブジェクトファイルの機械語コードに変換するには?そうですね。コンパイラを実行します。コンパイラはどのように実行しますか?プロジェクトのビルドシステムを使用します。
それがまさに最初に攻撃を受けることです。

したがって、挿入を「見る」ことができる唯一の方法は、人間のコードとドメインの知識を使用してコードツリー全体の詳細なレビューを実行することです。あなたがそれを調べるとき、それを説明するものを開発した人が本質的に必要です。まさにそこに別の妥当性と別の信頼問題があります!悪意のあるコード挿入は、ビルドシステムの修正されたM4コード(言語)で発生します。ビルドシステムの作成者を含むよく知られています。あまりにも不思議なので、誰もそれを理解できず、他の人のコードをコピーします。

自動的に何ができますか?エクスプロイトの内容を見るとするロードすると、バックドアライブラリとはまったく異なるソフトウェア機能を修正します。これを検出するのは簡単ではありません。ソフトウェアで常に行うからです。プログラムが共有オブジェクトをロードするたびに、その共有オブジェクトの初期化関数が実行され、最後に何を意味するかに関係なく、ライブラリを初期化して入力します。シンボル (つまり、このライブラリで使用される関数の関数名) を関数のアドレスに変換するテーブルの項目です。簡単に言えば、動的リンク

さて、このハッカーがとてもエレガントにしたことはめちゃくちゃでした。その他自分のシンボルでもありません。申し訳ありませんが、現在私たちはこれに適切な保護を持っていません。部分的には、プラグインAPIからランタイムスケジューラ(GCCifunc機能など)まで、あまりにも多くの機能がこれに依存しているためです。これらすべてを達成できることに注意してください。どう考えても構いません。

たとえば、ある程度参加しています。図書館さまざまなプロセッサのベクトル最適化、直接最適化、およびコンパイラ最適化バージョンを含む数学カーネル(「Cコンパイラのターゲットであるすべて」、「MMXサポートを含むx86用」、「AVX2サポートを含むx86_64用」、「aarch64 + NEON」、「altivecを含むPPC用」、...およびそれらの組み合わせ)。しかし、すべてが実現するわけではありません!したがって、場合によっては、「一般C」の実装に置き換える必要があります。

消費者が呼び出す関数はmultiply_two_vectors(float* out, const float* vec1, const float* vec2, int num)そうではないように見えますが、multiply_two_vectors_on_CPU_with_MMX_SSE_SSE2_SSSE3_AVX_AVX2(…)ライブラリは追加のランタイムオーバーヘッドなしでCPUの「魔法のように」最速の実装を選択します。どのように?初期化関数が入り、最良の実装を識別するベンチマークテーブルから値を取得し、最速の関数のアドレスをテーブルに配置しますmultiply_two_vectors。それはすべてです。 GCCを使用して同じ機能を実現できますが、ifuncGCCを搭載したシステムでのみ作業できます。 Linuxでは動作しますが、clangでコンパイルされたLinuxシステムやMac OSでは動作しません。他のBSDでも動作しますが、動作しません。 Windowsでは動作せず、clangでコンパイルされたLinuxシステムでは動作しません。 Intel ICC以外のIBM zOSでは...このライブラリには深刻な問題があります。

したがって、他の多くのライブラリと同様に、初期化時に自己予約を実行します。したがって、初期化関数の実行内容を変更するためにシンボルテーブル項目を修正するのが一般的な視点である。しかし、これらの初期化と状況が変わる可能性があるという事実は、そのような悪用につながる原因の一部です。したがって、ifuncルックアップの使用やカスタム共有オブジェクトファイルイニシャライザ自体は、何かが疑わしいことを保証しません。実際、コードはほとんどの場合コンパイラによって自動的に生成され、一部のユースケースに合わせて最適化できます。

問題はさらに深刻です。これらの修正はすべて、完全に正常なライブラリコードでも実行できます。私のライブラリは、multiply_two_vectors初期化プログラムではなく実行中のプロセスに関数がパッチされていることを確認し、必要に応じてすべての呼び出しをその関数に置き換えたり、必要なすべてのprintf悪いprintf("chickens!\n")操作を実行したりできます。問題は、実際にはプログラム空間ではなく、プログラム空間の一部に触れることができるということです。通常しかし、これは非常に経験的な実現であり、生態系全体の分析に容易に変換されません。関数が呼び出されたときにのみ変更が発生した場合(実際にはSSHデータを処理するために必要な関数)、誰かが解凍後に正確に133700バイトの長さのパケットを送信するとどうなりますか?この動作を「偶然に」実行することはできません。

実際、マルウェアは行動検出を回避するために多くの作業を行うことがよくあります。たとえば、多くのウイルスは、デバッガが現在プロセスに接続されているか、仮想マシンで実行されている(少なくともデスクトップユーザーを対象とする)、実行中のデバイスのIPアドレスを検出した場合、何もしません。彼らはイランのウランガス遠心分離機で動作しました(Stuxnetを覚えておいてください!)。

したがって、ディストリビューションに推奨される「1つ」がないことがわかります。もちろん、「読んで信頼できるコードのみをリリースするように注意する」ことは良いことですが、それが彼らが望むものであり、理想的にはとにかくまだ達成できません。

この場合、脆弱性はtarballにのみ存在し、上流のgitリポジトリには存在しません。したがって、「タールボールを使用せずにgit repoを使用してください!」はもう一つの良い推奨事項ですが、いくつかのディストリビューションでは好むそして必要彼らは開発者が最後のパッケージビルドベースのgitハッシュを削除しないことに頼りたくないので、Tarballを使います。これは両刃の剣です!

おすすめ記事