オープン ソースのオペレーティング システム ディストリビューションである OpenBSD は、システム管理者、特にサーバーを管理する管理者の間でよく知られており、そのスピード、機能、ファンシーなフロントエンドよりもセキュリティに重点を置いています。
おそらく、そのロゴはふくらんだフグであり、そのスパイクは、やって来る可能性のある狡猾なハッカーを撃退する準備ができています.
しかし、OpenBSD チームはおそらくディストリビューション全体ではなく、リモート アクセス ツールキットで最もよく知られています。 OpenSSHの これは、オペレーティング システム自体に含めるために 1990 年代後半に作成されました。
SSH、略して 安全なシェル、もともとはフィンランドのコンピューター科学者によって作成されました タトゥ・イロネン Telnet プロトコルを使用するという危険な習慣からシステム管理者を引き離すことを期待して、1990 年代半ばに開発されました。
Telnetのトラブル
Telnet は非常にシンプルで効果的でした。リモート サーバーへのテレタイプ接続を行うために物理的なワイヤを接続する (または電話回線でモデムを使用する) 代わりに、代わりに TELetype NETwork 接続を使用しました。
基本的に、通常は専用のシリアル接続またはダイヤルアップ電話回線を介してやり取りされるデータは、回線交換のポイントツーポイント リンクの代わりにパケット交換 TCP ネットワーク接続を使用して、インターネット経由で送受信されました。 .
同じ使い慣れたログイン システム、安価な接続、専用のデータ回線は不要です。
もちろん、Telnet の大きな欠陥は、暗号化が完全に欠如していたことでした。そのため、正確な端末セッションを盗聴することは些細なことであり、クラッカーは、入力したすべてのコマンド (あなたが犯した間違いや、何度打ったかさえも) を見ることができました。 [Backspace]
)、そして出力のすべてのバイトが生成されます…
…そしてもちろん、セッション開始時のユーザー名とパスワード。
あなたのネットワーク パス上の誰もが、あなたのシステム管理者セッションを自分の画面上でリアルタイムに簡単に再構築できるだけでなく、リモート サーバーに送信したコマンドを変更し、返信を偽装することであなたのセッションを改ざんする可能性があるため、気付かない可能性があります。策略。
彼らは、なりすましサーバーをセットアップして、あなたをそこに誘い込み、その欺瞞を見抜くのを驚くほど困難にすることさえできます。
強力な暗号化 FTW
Ylönen の SSH は、Telnet のようなセッションの両端に強力な暗号化と認証の層を追加することを目的としており、 安全なシェル (疑問に思ったことがあるなら、それが名前の意味ですが、ほとんどの人は単にそれを呼んでいます エスエスアイッチ 最近)。
これはすぐにヒットし、このプロトコルはあらゆる場所のシステム管理者にすぐに採用されました。
上で述べたように、OpenSSH はすぐに続き、1999 年後半に OpenBSD 2.6 リリース。
OpenBSD チームは、彼らが開発したプロトコルの無料で信頼性の高いオープン ソース実装を作成したいと考えていました。 他の誰でも使用できますリリース直後の数年間、イロネンの最初の実装を妨げていたライセンスや商業的な複雑さはありません。
実際、Windows SSH サーバーを実行して Linux コンピューターから接続する場合、ほぼ確実に両端で OpenSSH 実装に依存することになります。
SSH プロトコルは、SCP や SFTP などの他の一般的なクライアント サーバー サービスでも使用されます。 安全なコピー & 安全な FTP それぞれ。 SSH は大まかに、コマンド シェル用の Unix プログラムが通常 /bin/sh
. SCP は似ていますが、Unix のファイル コピー コマンドが一般に呼び出されるため、ファイルのコピー用です。 /bin/cp
、および SFTP はほとんど同じ方法で命名されます。
SSH ツールキットは OpenSSH だけではありません。
その他のよく知られた実装には次のものがあります。 libssh2、独自のアプリケーションに SSH サポートを組み込みたい開発者向け。 ドロップベア、オーストラリアのコーダーからの簡素化された SSH サーバー マットジョンストン これは、ホーム ルーターやプリンターなどのいわゆる IoT (モノのインターネット) デバイスで広く見られます。 と PUTTYは、インディー オープンソース開発者による Windows 用の SSH 関連ツールの人気のある無料のコレクションです。 サイモンタサム イングランドで。
しかし、通常の SSH ユーザーであれば、現在少なくとも XNUMX つの OpenSSH サーバーに接続していることはほぼ間違いありません。これは、最新の Linux ディストリビューションのほとんどに標準のリモート アクセス ツールとして OpenSSH が含まれており、Microsoft が OpenSSH クライアントと OpenSSH の両方を提供しているためです。サーバーは、最近では公式の Windows コンポーネントとして使用されています。
ダブルフリーのバグ修正
OpenSSH バージョン 9.2 出てきたばかりで、 リリースノート 次のように報告します。
このリリースには、[…] メモリの安全性の問題に対する修正が含まれています。 [このバグ] が悪用される可能性はないと考えられていますが、ネットワークに到達可能なメモリ障害のほとんどはセキュリティ バグとして報告されています。
バグが影響する sshd
、OpenSSH サーバー ( -d
サフィックスは デーモン、Windows が呼び出す一種のバックグラウンド プロセスの Unix 名 サービス):
sshd(8): OpenSSH 9.1 で導入された認証前の二重解放メモリ障害を修正します。 これは悪用できるとは考えられておらず、chroot(2) の対象であり、ほとんどの主要なプラットフォームでさらにサンドボックス化されている非特権の事前認証プロセスで発生します。
ダブルフリー バグとは、既にオペレーティング システムに返されたメモリ ブロックが、プログラムの他の部分で再利用されることを意味します…
…後で、実際にはそのメモリを「所有」していないプログラムの一部によって再び返されますが、所有していないことはわかりません。
(または、意図的にバグを引き起こそうとするコードのプロンプトで意図的に引き返し、 脆弱性 に エクスプロイト.)
これは、特にシステムが解放されたブロックを最初の free()
発生し、後でメモリを要求するときにコードの別の部分に割り当てます malloc(
)、そして余分な呼び出しが free()
表示されます。
そのため、ホテルにチェックインしたときに経験するような状況に陥ります。 私たちは満室だと思っていましたが、別のゲストが早めにチェックアウトすることに決めたので、部屋を確保できます。」
入室時に部屋がきれいに掃除され、新しい居住者のために準備されていて、あなた専用に適切に割り当てられているように見えたとしても、前のゲストのキーカードが実際に正しくキャンセルされ、彼らの「アーリー チェックアウト」は、同じ日にこっそり戻ってラップトップを盗む狡猾な策略ではありませんでした。
バグ修正のためのバグ修正
皮肉なことに、最近の OpenSSH コードの履歴を見ると、OpenSSH の関数にささやかなバグがあったことがわかります。 compat_kex_proposal()
、接続を設定するときに使用するキー交換アルゴリズムの種類を確認するために使用されます。
しかし、そのささやかなバグを修正すると、代わりにより深刻な脆弱性が発生しました。
ちなみに、接続のセットアップ中に使用されるソフトウェアの一部にバグが存在することが、これをいわゆる ネットワーク到達可能な事前認証 脆弱性(または 事前認証バグ 略して)。
ダブルフリーのバグは、実行する必要があるコードで発生します After クライアントがリモート セッションを開始しましたが、 鍵合意または認証が行われているため、理論的には、検証のためにパスワードまたは暗号鍵が提示される前に脆弱性がトリガーされる可能性があります。
OpenSSH 9.0 では、 compat_kex_proposal
次のように見えました(ここでは大幅に簡略化されています):
char* compat_kex_proposal(char* suggestion) { if (condition1) { return suggestion; } if (condition2) { suggestion = allocatenewstring1(); } if (condition3) { suggestion = allocatenewstring2(); } if (isblank(suggestion)) { error(); } return suggestion; }
アイデアは、発信者がキー交換設定を提案するテキスト文字列を含む独自のメモリ ブロックを渡し、送信した提案そのものを使用する承認、または更新された提案を含む新しく割り当てられたテキスト文字列を返すというものです。 .
バグは、条件 1 が false であるが、条件 2 と 3 の両方が true の場合、コードが割り当てを行うことです。 2 新しいテキスト文字列ですが、返すだけです XNUMXつ.
によって割り当てられたメモリ ブロック allocatenewstring1()
解放されることはなく、関数が戻ると、そのメモリアドレスは永久に失われるため、コードが解放される方法はありません free()
それは将来的に。
そのブロックは本質的に放棄され、いわゆる メモリーリーク.
時間の経過とともに、これが問題を引き起こす可能性があり、メモリの過負荷から回復するためにサーバーを強制的にシャットダウンすることさえあります。
OpenSSH 9.1 では、XNUMX つの文字列の割り当てを回避し、そのうちの XNUMX つを破棄するためにコードが更新されました。
/* Always returns pointer to allocated memory, caller must free. */ char* compat_kex_proposal(char* suggestion){ char* previousone = NULL; if (condition1) { return newcopyof(suggestion); } if (condition2) { suggestion = allocatenewstring1(); } if (condition3) { previousone = suggestion; suggestion = allocatenewstring2(); } free(previousone); } if (isblank(suggestion()) { error(); } return suggestion; }
条件 1 と条件 2 が両方とも false であるが、条件 3 が true の場合、コードは新しい文字列を割り当てて、その答えとして送り返すため、これには double-free バグがあります…
…しかし、呼び出し元が最初に渡した文字列を誤って解放します。 allocatenewstring1()
変数を更新するために呼び出されることはありません suggestion
.
渡された候補文字列 呼び出し元に属するメモリです、したがって、呼び出し元は後でテーマを解放し、ダブルフリーの危険につながります。
OpenSSH 9.2 では、コードはより慎重になり、使用される可能性のある XNUMX つのメモリ ブロックすべてを追跡します。 suggestion
(他の誰かが所有するメモリ)、および途中で割り当てられる可能性のある XNUMX つの新しい文字列:
/* Always returns pointer to allocated memory, caller must free. */ char* compat_kex_proposal(char* suggestion) { char* newone = NULL; char* newtwo = NULL; if (condition1) { return newcopyof(suggestion); } if (condition2) { newone = allocatenewstring1(); } if (condition3) { newtwo = allocatenewstring2(); } free(newone); newone = newtwo; } if (isblank(newone)) { error(); } return newone; }
条件 1 が真の場合、渡された文字列の新しいコピーが使用されるため、呼び出し元は後で free()
いつでも渡された文字列のメモリ。
条件 1 を通過し、条件 2 が真であるが条件 3 が偽である場合、 allocatenewstring1()
返され、渡された suggestion
文字列はそのままです。
条件 2 が false で条件 3 が true の場合、新しい文字列が生成されて返され、渡された suggestion
文字列はそのままです。
条件 2 と条件 3 の両方が true の場合、途中で XNUMX つの新しい文字列が割り当てられます。 最初のものは不要なので解放されます。 XNUMX 番目のものが返されます。 そして渡された suggestion
文字列はそのままです。
また、ご購読はいつでも停止することが可能です RT×M あなたが電話した場合、それを確認するために free(newone)
いつ newone
is NULL
、その後「操作は実行されません」。これは、常に安全であるためです。 free(NULL)
. それにもかかわらず、多くのプログラマーは、 if (ptr != NULL) { free(ptr); }
.
何をするか?
OpenSSH チームが示唆しているように、このバグを悪用することは困難です。 sshd
プログラムは、使用するための接続をセットアップしているときに持っています。
それにもかかわらず、彼らはそれをセキュリティ ホールとして報告しました。 OpenSSH 9.2.
また、C でコードを書いている場合は、どんなに経験を積んでも、メモリ管理は間違いやすいということを覚えておいてください…
…だから気をつけてね。
(はい、Rust とその現代の仲間は 正しいコードを書くのに役立ちます、しかし、それでもCを使用する必要がある場合があり、Rustでさえそれを保証できません 間違ったコードを書くのをやめる 無分別にプログラムすると!)
- SEO を活用したコンテンツと PR 配信。 今日増幅されます。
- Platoblockchain。 Web3メタバースインテリジェンス。 知識の増幅。 こちらからアクセスしてください。
- 情報源: https://nakedsecurity.sophos.com/2023/02/03/openssh-fixes-double-free-memory-bug-thats-pokable-over-the-network/