HN 日本語サマリー

← 一覧へ戻る
セキュリティ

Never Gonna Print You Up

Never Gonna Print You Up (dixken.de)

49 pointsby ta9882 コメント

要約

セキュリティ研究者がPrusa MK4Sのファームウェアに14件の脆弱性を発見し、そのうち最も深刻なものはPrusa Connect経由でリモートからコードを実行できる（RCE）脆弱性でした。この脆弱性は、ネットワーク経由でプリンターのメインコントローラーを完全に制御することを可能にします。Prusaは迅速かつ協力的に対処し、修正はファームウェアv7.0.0で提供されています。

全文翻訳

Never gonna print you up!

注: この記事の公開はPrusaと連携して行われ、公式のセキュリティアドバイザリと同時に公開されました。Prusaはこの記事で報告されたすべての脆弱性をBuddyファームウェア >7.0.0 で修正済みです。お使いのプリンターが記事末尾のリストにある場合は、すぐにアップデートしてください。また、すべての脆弱性に対してCVE IDの割り当ても依頼しており、近日中に公開される予定です。割り当てを早める方法を知っている方がいれば、ぜひ教えてください！

［画像: エクスプロイト実行後のMK4Sディスプレイ：ファームウェアのエラーダイアログの上に「Never gonna let you down」とキャプションされたリック・アストリーのビデオフレームが表示されている］ おい、リック、俺のプリンターで何してるんだ？！

TL;DR

8月、私はMK4Sを壊そうと1週間かけて調査し、その結果はかなりのものになりました。14件の発見、約23個の個別の欠陥、そしてプリンターのメインコントローラーがネットワーク経由で私が送ったコードを実行するに至る連鎖を発見しました。そうです、完全なRCE（リモートコード実行）です。

この記事では、これらの発見と、Prusaがこの状況全体にどのように対応したかについて説明します。

私と問題のプリンターについて少し

私はフリーランスのプラットフォームエンジニアリング、SRE、データベース関連の仕事をしており、セキュリティリサーチは趣味としてサイドで行っています（コンピューターを使った仕事の合間に、別のコンピューターを使った仕事で休む、というわけです）。私は物事を壊すことで内部構造を学ぶのが好きです。長年CTFに参加し（リバースエンジニアリングやpwningを理解することにLiveOverflowから大きな影響を受けました）、最近では本番のWebアプリケーションでいくつかの実際の発見をしました（顧客のためにプロアクティブにスキャンしています。ちなみに、プロジェクトベースで私を雇うこともできます！）。しかし、ファームウェアやハードウェアは私にとって新しい分野でした。そのため、これ以前はCortex-Mアセンブリを一行も書いたことはありませんでしたし、書く必要もありませんでした。

セットアップは非常に基本的でした。私のMK4Sと、当時最新だった署名済みのアップストリームイメージ（6.5.7、ビルド 6.5.7+12836）を実行していました。そして、Opus 4.8とファズーザーを手にしました。Gコード解析とPrusa Connectの2つの場所から調査を開始しました。ユーザー提供の入力が入ってくる場所から脆弱性を探し始めるのが定石であり、そこで最も深刻なバグを見つけました。USBとFATパス（ここでもユーザー提供の入力）、転送リカバリコードでもさらに多くのバグが見つかり、MMUとEEPROM側にもいくつかの小さな欠陥がありました。

手法

その週は以下のような流れでした。

  • ファームウェア自身のパーサーコードをホスト上で AddressSanitizer を有効にしてコンパイルし、クラッシュが私のグルーコードではなくPrusaの出荷コードで発生するようにしました。
  • メモリマップに対応する実際の署名済みイメージを実行する小さなCortex-Mエミュレーターをセットアップし、プリンターに触れる前に制御フローを検証し、不正なUSBスティックを挿入する前にそれを証明できるようにしました。まあ、私は怠惰なので :-)
  • Gコードパスに対して数百万回の変異したイテレーションを実行し、PrusaLink / Connectに対して数百万回の変異したHTTPリクエストを実行しました。
  • 実際のコンパイル済みビルドに対して大量のリバースエンジニアリングを行い、複数のソース監査を並行して実行しました。各監査では、開かなかったファイルも記録する必要がありました。

最も困難だったのは、制御フローのプリミティブでした。利用可能に見える候補となるディスパッチサイトが多数ありましたが、RCEにつながったのはそのうちの1つだけでした。残りは一つずつ除外され、そのほとんど（すべてではありませんが！）は、私が委任して確認できる機械的な作業でした。

Prusaに送付した開示パッケージには、私が構築したワークツリー全体、使用した手法、スクリプトなどが含まれていました。その手法の痕跡はすべて意図的に彼らに渡しました。ベンダーは欠陥と行番号を必要としますが、このキャンペーン全体のために私が構築したフレームワークを提供し、開発者が希望すれば私のプロセスを再現できるようにすることは有益だと感じたからです（そして、そうしてくれることを願っています！）。私は明確な違いを作り、発見したものが実際に本物であり（これについては後述）、再現可能であることを信頼させたいと思いました。そのため、開示パッケージは分離しました。それでも、手動でレビューした後、2番目の（ソース検証済み）コレクションの発見が本物であることに十分な自信がありました。

発見して報告したこと

Prusaには2つのパッケージを送付しました。最初のパッケージには4件の発見が含まれており、そのうち3件は物理プリンターで確認済みです。プリンター自身が書き込んだクラッシュダンプと、コントローラーの完全な乗っ取りの両方から確認しました。4件目はMMU側のオフバイワンエラーで、ソース検証のみです（これについては後述）。2番目のパッケージには残りの10件が含まれており、AddressSanitizerまたはソースレビューで確認済みです。

この決定にはいくつかの理由があります。発見の種類間の信頼度レベルが「混ざり合わない」ようにするためです。自分のハードウェアをクラッシュ（またはエクスプロイト）させたバグと、アップストリームソースツリーで論理的にたどり着いたバグは、同じレベルではありません。それらを一緒にパッケージ化すると、Prusaが弱いバグを過信したり、強いバグを過小評価したり、最悪の場合はすべて破棄したりする可能性があり、それらを区別する線引きをすることが理にかなっていました。それでも、すべての発見には完全な書き込み（すでに大幅にクリーンアップしましたが、その量の多さはPrusa側に苦痛を与えました - 以下参照）と、該当する場合は各発見をエクスプロイトするためのPoCコードが付属していました。Prusaが公開に踏み切った今、私もそれらをすべて公開します。

しかし、まずは最も深刻なものについて、高レベルで議論しましょう。実際のアドバイザリには完全な書き込みが含まれています。

しまった、RCEしちゃった

PFB-008 CVSS 8.1 High ハードウェアで再現可能 攻撃対象：Connectエンドポイント（制御下にあるかMITMされたもの）、または侵害されたConnectバックエンド

長いSEND_FILE_INFOパスがConnectタスクのスタックをオーバーフローさせ、制御下にあるか傍受されたConnectエンドポイントから攻撃者のコードを実行させる

リリースビルドでは104バイトのパスアサートが削除されるため、463バイトのパスはファイル名の書き込みを共有512バイトバッファの上にオーバーフローさせ、プランナーのプリンターポインタに影響を与えます。これは物理的なMK4Sで確認済みです。

これはPrusa Connect、つまりプリンターが通信するクラウド（またはセルフホスト）サービスにあります。プリンターを管理したり、プリントをディスパッチしたりするために使用されます。Connectが SEND_FILE_INFO コマンドを送信すると、コントローラーのハンドラーはコマンドのパスを共有512バイトバッファにコピーしますが、そのコピーはバッファサイズで境界設定されます。問題は、バッファがパス以上のものを含むことです。なぜなら、ファイル名がその直後に同じバッファに入るからです。そして、ファイル名を取得するコードは、パス文字列の末尾から歩いていくことでそれを見つけます。この配置は、パスが104バイトに制限されている場合にのみ機能します。

ええ、おそらくあなたはすでに問題に気づいたでしょう：それを104バイトに制限するものは何もありません。その仮定を強制する唯一のものは assert() であり、リリースビルドでは NDEBUG の下でアサートがコンパイルアウトされるため、十分に長いパスはファイル名スロットをバッファの末尾からその隣にあるものの上に押し出します。

// src/common/shared_buffer.hpp:102-108
char *name(){
    char *path = this->path();
    size_t plen = strlen(path);
    assert(plen < FILE_PATH_BUFFER_LEN);   // FILE_PATH_BUFFER_LEN == 104; リリースではコンパイルアウトされる
    return path + plen + 1;
}

その隣にあるのは、Connect自身のコマンドプランナーがプリンター呼び出しをディスパッチするポインタです。そのため、次の仮想呼び出しはそのポインタを歩き、私がそれを指した場所へ行きます。ファイルはプリンター上に存在する必要はありません。なぜなら、ルックアップはファイルを開く前にコールバックにファイル名を渡すからです。そして、バイトはどちらにしてもコピーされます。

さらに2つの詳細を言及すべきです。第一に、ペイロードは自己完結型です。コマンドはネットワーク受信プール内にあり、パス自体のバイトが偽のオブジェクト、偽のディスパッチテーブル、およびコードを運びます。ヒープスプレーやセカンドチャンネルはありません。第二に、ファームウェアにはスタックカナリアや _FORTIFY_SOURCE がありません。これが、この境界のずれを単純なクラッシュではなく、実際のプログラムカウンタ（PC）制御に変えた理由です。

予備的なCVSSスコアは8.1 Highで、攻撃者はプリンターと通信するConnectエンドポイントであるか、それをMITMできる必要があるという前提条件があります。これは、そのエンドポイントを制御する者、またはその経路にいる者、侵害されたConnectバックエンドまで含みます。LAN上では、ARPスプーフィングが選択肢となるため、これは現実的な位置です。私はローカル設定でTLSをオフにした自分のプリンターに対してテストしました。そのため、公式のクラウドベースのPrusa Connectにプリンターが接続している場合、MITMは依然としてTLSをダウングレードする必要があります。

最終的にそれを確認したのは（または、基本的にハードウェアで再現可能とタグ付けされた開示のすべて）、プリンターがクラッシュしたときにUSBに書き込むプリンター自身のクラッシュダンプでした。ダンプは、私のシェルコードのみが書き込む2つのマーカー値をレジスタに記録し、プログラムカウンタは私のバイト内にあり、リターンアドレスはディスパッチのすぐ後を指していました。ダンプ内のプールメモリにはチェーン全体が含まれており、正しく到着したことが検証されました。

その後、ハードウェアの制御権を証明するために、実際のPoCエクスプロイトの開発に着手しました。

これはPrusaに送った録画です。

［動画: 動画をダウンロード (MP4)］

私の完全なエクスプロイトPoCコードが実行され、初めてRCEを達成しました。はい、この哀れなMacBook Proは、その間にホコリを払われました :-)

私は、人々がマシンをパッチする時間をさらに確保するために、おそらく12月中に、完全なPoCコード（該当する場合は各バグについて）をリリースする予定です。Congress / 40C3の頃かもしれません。なぜなら、私のプリンターを私たちの組み立て会場に持ち込んで、このエクスプロイトを使って何か奇妙なことをさせているかもしれないからです :-)

私の書き込みからエージェントが独自のPoC実装を導き出せることは理解していますが、それでもこれははるかに責任ある方法だと感じています。

最初のパッケージの残りの部分

PFB-007 CVSS 6.4 Medium ハードウェアで再現可能 攻撃対象：電源投入時に存在する準備されたUSBスティック

細工されたUSBファイル名がget_SFN_pathのスタックパスバッファをオーバーフローさせ、プログラムカウンタを乗っ取る

細工されたUSBファイル名がプログラムカウンタを乗っ取ります。 ファームウェアは、ディレクトリエントリのFATショートネームでパスの最後のコンポーネントをインプレースで書き換えます。これは、ショートネームが決してロングネームより長くなることはないという文書化された仮定に基づいています。その仮定のガードは別の assert() であり、リリースビルドでは削除されます。この仮定は手書きでメディアを作成した場合に偽となります。なぜなら、PrusaはFATコードページをアイデンティティマップとしてマッピングするため、各ハイバイトはUTF-8の2バイトになり、名前全体の天井を23に引き上げるからです。これは6.4 Mediumと評価され、プログラムカウンタの完全な制御を与えます。私が示したハイジャックは私のコードを実行しません。その制限は、努力のギャップというより構造的なものです。オーバーフローバイトはFAT 8.3ショートネームを綴る必要があり、そのアルファベットはRAMアドレスや有用なガジェットを名前付けできません。物理的なUSBアクセスが必要であり、そのアルファベットと電源投入時にスティックが存在する必要があることが、攻撃の複雑性を高く評価する理由です。

PFB-011 CVSS 6.4 Medium ソースレビューのみ 攻撃対象：MMUの欠陥または悪意のあるユニット、細工されたEEPROMジャーナル

MMU進捗コンバーターでのオフバイワンの境界外読み取り、および2つのEEPROM駆動メモリ欠陥

MMU進捗コンバーターでのオフバイワンエラー。境界は <= で、本来は < であるべきです。そのため、29エントリテーブルの1つ先のインデックスが受け入れられ、ポインタとして読み取られ、文字列としてウォークされます。これはソース検証のみであり、MMUバス上の欠陥または悪意のあるユニットが必要です。私はこれを3.5 Lowと評価します。このオフバイワンエラーは、私が最初に間違えた発見でもあります。当初、実際のPrusaハードウェアがMMUセルフテスト中にトリガーコードを送信すると考えていましたが、実際の呼び出し順序をトレースしたところ、セルフテストはシリアル受信パスが有効になる前に実行されるため、プリンターがその状態にある間はワイヤ上に何もありませんでした。レポートは、それがすでに修正された状態でPrusaに送られました。（そのアドバイザリは6.4と表示されています。なぜなら、同じ書き込みには2つのEEPROM欠陥も含まれており、それぞれ6.4と3.1と評価されているからです。）

PFB-013 CVSS 6.1 Medium ハードウェアで再現可能 攻撃対象：USBスティック

E2EEアイデンティティブロックが1つの攻撃者フィールドからヒープバッファのサイズを決定し、それをオーバーランさせる

暗号化されたGコードヘッダーがバッファのサイズを決定し、同じフィールドから読み取ります。2つの減算は11だけ異なります。狭い範囲の値では、割り当ては0から10バイトになりますが、読み取り長はほぼ4GBにアンダーフローしてから、ファイルの残りのバイトにクリップされます。そのため、攻撃者は長さとオーバーフローの内容の両方を選択できます。本来拒否すべきヘッダーを拒否する代わりにゼロを返す関数があるため、見かけ上のガードは決して発火しません。プリンターがUSBスティックからプリントプレビューをスキャンするときに実行され、署名チェックもCRCも行われず、プリントを開始しません。これは6.1 Mediumと評価され、ハードウェアで5回確認しました。信頼性の高いサービス拒否（DoS）を引き起こしますが、信頼性の高いコード実行はできません。なぜなら、ヒープは5回の実行すべてでオーバーフローを4つの異なる場所に配置したからです。

2番目のパッケージ

他の10件の発見は2番目のパッケージに入っており、それぞれに独自の完全な書き込みがあり、カードからリンクされています。

PFB-014 CVSS 7.7 High ホストで再現可能 攻撃対象：信頼されたConnectバックエンド

110文字のクライアントGコードが、ガードされていないstrcpyにより96バイトのキューをオーバーフローさせる

110文字のクライアントGコードが、_enqueue内のガードされていない strcpy により96バイトのリングスロットをオーバーフローさせます。プリントおよびシリアルパスは96バイトに制限されていますが、クライアントパスはそうではなく、最後のスロットをオーバーフローさせると隣接するスタティックメモリに書き込まれます。

PFB-012 CVSS 7.5 High ソースレビューのみ 攻撃対象：プリンターのTCPサービスに到達できる任意のホスト

TCP経由でプリンターに到達する認証されていないホストが、イーサネット受信プール全体をピン留めし、すべてのネットワークを停止させる

通常ローカルセグメントにある、プリンターのTCPサービスに到達できる認証されていないホストが、イーサネット受信プール全体をピン留めできます。2つのタイムアウトリセットメカニズムにより、プールバッファを保持でき、リングバッファを枯渇させ、PrusaLink、Connect、mDNSを送信し続ける限り停止させます。どちらもパスワードを必要としません。

PFB-002 CVSS 5.9 Medium ネットワークパスMITM 攻撃対象：ネットワークパスMITM

Prusa Connectの暗号化ダウンロードは、プレーンHTTPで整合性チェックを行わない

Prusa Connectの暗号化ダウンロードパスは、AES-128-CTRのみで受信ファイルを保護します。CTRは整合性のないストリーム暗号であり、転送にはMACや署名が追加されないため、プリンターとそのファイルサーバー間のネットワークパス上のホストは、キーやノンスを必要とせずに、復号化されたGコードに正確で選択的な編集を加えることができます。

PFB-005 CVSS 5.4 Medium ホストで再現可能 攻撃対象：認証されたPrusaLinkまたはConnectアップロード、USBプリントファイル、USBシリアル

M919/M920が、scanfの幅オフバイワンにより16バイトのスタックバッファを1バイト超えて書き込む

M919とM920は、%16s を使用してトークンを16バイトのスタックバッファにスキャンしますが、終端のヌルバイトの余地がありません。16文字の引数を持つそのようなコマンド（シリアルから、またはプリントファイルから受信したもの）は、バッファを1バイト超えて書き込みます。

PFB-009 CVSS 5.2 Medium ソースレビューのみ 攻撃対象：物理USB

転送リカバリバックアップファイルが、攻撃者が選択した境界外読み取りを生成し、そのバイトがプリンターから流出する

停電後、プリンターは中断されたダウンロードをバックアップファイルから再開します。そこにある2つの欠陥（負のオフセットを拒否できないオーバーフローする範囲チェックと、転送中に失われる長さ）により、保存されたオフセットと長さのペアはリカバリバッファ外のポインタになり、プリンターがそこで読み取ったものはDNSクエリとHTTP Host ヘッダーとして送信されます。

PFB-004 CVSS 4.4 Medium ホストで再現可能 攻撃対象：プリンターで開かれた細工された.bgcodeファイル

E2EEアイデンティティブロックが、境界のない16ビットキー長を解析し、署名チェックの前にヒープをオーバーリードする

E2EEアイデンティティブロックは、.bgcode ファイルから16ビットキー長を直接読み取り、それをmbedTLSに渡しますが、割り当てに対して境界チェックを行いません。そのため、細工されたブロックにより、mbedTLSは署名がチェックされる前にヒープブロックを越えるキーを解析します。

PFB-001 CVSS 4.3 Medium ホストで再現可能 攻撃対象：USBスティック、PrusaLinkアップロード、Connectダウンロード

MeatPack Gコードデコーダーが出力バッファを2バイト超えて書き込む

MeatPack Gコードデコーダーは、2バイトの出力バッファを2バイト超えて書き込みます。1回の handle_rx_char 呼び出しで2つのデコードステップを実行できるため、細工された6バイトのストリームは出力カウントを4に押し上げ、それが配置されているオブジェクトをオーバーランさせます。USBスティック、PrusaLinkアップロード、Connectダウンロードからの任意のMeatPackブロックで発生します。

PFB-003 CVSS 4.3 Medium ホストで再現可能 攻撃対象：E2EEキーホルダーからの暗号化ファイル

E2EEデクリプタの整数アンダーフローが境界外読み取りにつながる

E2EEデクリプタ内の2つの整数アンダーフローが、ラップされたPKCS#7パディング長をポインタに変換し、次の decrypt がそのポインタ上の memcpy 長を16バイトバッファを越えて読み取ります。そのうち1つはホスト上でAddressSanitizerによって確認されており、もう1つはソース検証済みです。

PFB-010 CVSS 4.3 Medium ソースレビューのみ 攻撃対象：認証されたPrusaLink PUT、細工されたUSBファイル

転送、PrusaLink、libbgcode、Connectにおける5つの小さなソース検証済み欠陥

このカードは、転送、PrusaLink、libbgcode、Connectパスにまたがる5つの小さな自己完結型の脆弱性をカバーしています。それらのどれもメモリ破損プリミティブではありません。ネットワーク経由で到達可能なものは、PUT /api/v1/files/usb における未初期化のパスバッファです。

PFB-006 CVSS 0.0 None ホストで再現可能 攻撃対象：PrusaLink

PrusaLinkのURLからファイル名への処理における2つの欠陥（境界外読み取り、弱化されたトラバーサルガード）

PrusaLinkのURLからファイル名へのパスには、1文字の欠陥が2つあります。パーセントデコーダーが間違ったバッファを保護しているため、末尾の % は入力の2バイト先を読み取ります。トラバーサルガードは1ウィンドウ早く停止するため、/../ で終わるURLは決してチェックされません。どちらも出荷ファームウェアで実証された結果はありません。そのため、それぞれのガードが本来行うべきことを回復する修正として報告しました。

開示プロセス

最初に、このビデオをr/prusa3d subredditに投稿し、半ば冗談で「私のプリンターはこれをするはずですか？」と尋ねました。（多くの企業ではこれを推奨しませんが、ここでは、いくつかの初期の連絡先ポインターを得るために、調査後に適切なチャネルを見つけられなかったため、その時点で理にかなっていました。）

数分後（日曜日に！）、PrusaのコミュニティマネージャーであるTommyから、私のビデオが社内で投稿され、警鐘を鳴らしたというDMを受け取りました。彼は、さらに情報を提供できるか尋ね、正しい方向を示してくれました。その後、最初の投稿をオフラインにし、すでに準備していたメールを送信しました。

Prusa様、 [...] 合計で23件のバグを発見しました。そのうち最もクリティカルなものは、ローカルネットワーク経由で、物理アクセスなし、通常の初回セットアップ以外のユーザーインタラクションなしで、プリンターのメインコントローラーでのコード実行につながるチェーンです。これはエミュレーターだけでなく、実際のハードウェアで確認済みです。

完全なチェーンは当然機密情報です。完全な書き込み、動作する概念実証（スクリプトが必要..）、およびクラッシュダンプを用意してあります。手法に関する一言：Claudeと密接に連携しました（私もCyber Verification Programで認証されているため）、そのため一部の書き込みはかなり乱雑/ずさんです。最善を尽くしてクリーンアップし、可能な限り理解しやすくします。

それをあなたに渡す最良の方法は何ですか？あなたの都合の良い開示タイムラインに従います。実際の脆弱性はそれまで秘密にしておきます。リポジトリに対して問題を公開するのは意味がないと思います。

[...]

彼らはちょうど24時間後に返信し、私が正しいチャネルを持っていることを確認しました。その後、私は完全なワークツリー、約800メガバイトとチェックサム付きのものを送信しました。両方のパッケージ、テストハーネス、生成したすべての出力、概念実証コード、およびビデオです。

その後、しばらく静かになり、それは良い種類の静けさであることが判明しました。彼らが戻ってきたとき、彼らは発見を検証・再現しており、その量のために開発者は頭痛の種になったと言いました（すみません！）。彼らは私に、a)修正が公開され、人々がインストールするのに十分な時間が経過するまで公開を保留すること、およびb)それらを回避するのではなく、それらと開示を調整すること、を求めました。もちろん、私は同意しました。適切なCVD（協調的脆弱性開示）の行動を念頭に置いていました。

最近、彼らは私にどのようにクレジットを記載したいか尋ねました。 refreshing experience!

それがすべての話であり、ひねりはありません。このプロセス全体を調整するために、まだ少しやり取りが必要でしたが、発見の検証と修正にどれだけの人が関わったか想像できます。

Prusaが正しく行ったこと

  1. レポートを迅速に承認したこと。 1営業日以内に返信があり、返信は名前のある実際の人間からでした。
  2. 迅速な検証。 彼らは自身のハードウェアで発見を再現しました。発見の数を考えると、それでも合理的な期間内でした。
  3. タイムラインについて正直だったこと。 「通常より時間がかかります。その構造的な理由はこちらです」という回答は、彼らが遅れる日付よりもはるかに良い回答でした。
  4. 沈黙を要求するのではなく、エンバーゴを求めたこと。 調整要求とNDAの違いは、作業が発生したことをまだ言えるかどうかです。私は言えました。ありがとう！
  5. 研究者を協力者として扱ったこと。 すべてのメールで、双方向の質問のドアが開かれていました。素晴らしい！
  6. クレジットの帰属方法を尋ねたこと。 彼らは尋ね、関係者全員の名前を挙げることも申し出てくれました。そして、はい、報酬も受け取りました。

7番目の点として、彼らに当時提供した唯一の修正を追加します。動作する security.txt です。彼らのものは404だったので、すでに送信がやや厄介だったレポートは、私がアドレスを推測し、プライバシーインボックスがそれを転送してくれることを願って始まりました。今日、連絡先アドレスとポリシーを持つものとして解決されています。

これがトピックになる可能性があるため、Marlin GPL違反についてはここでは議論しません。ファームウェアは、ソースが公開される前に、より多くのプリンターがパッチを適用できるようにするために、実際のソースが保留されたままリリースされたためです。GitHubのすでに熱い議論に有用なものを追加できるとは思えません。Prusaはこのプロセスとコミュニティの反応から多くのことを学んだと思いますが、私にとっては、この状況全体が彼らの通常の開発プロセスからの大きな例外であり、最終的に従った決定の背後にある完全な理由を知ることはないでしょう。しかし、両方の側面を理解できます。誤解しないでください。

これが安価になった理由

徹底性、しかしまず詳しく説明させてください。

私は1週間、1台のプリンター、そして実際のファームウェアのバックグラウンドなしで作業しました。数年前なら、この作業には10年の組み込み経験を持つ専門家が必要でした。今回はそうではなく、私は特に賢いわけではありませんが、この分野全体でかなりの経験を積んでいるため、ツールがそのギャップを完全に埋めたと考えています。

だから、徹底性が安価になったのです。すべてのバイトエンコーディングを列挙し、候補を1つずつ除外して機能するものを見つけ、同じ呼び出しパスを3回異なる方向から読む：これらの作業はすべて、もちろん常に可能でしたが、適切に行うにはかなりの時間がかかりました。この制約は現在ほとんどなくなっています。個人的には、プログラミング全般がこの大規模なパラダイムシフトによりはるかに民主化されたと信じていますが、エージェントが何をしているかを理解し、その真の可能性を解き放つために正しい方向に導くことができる「ドライバーのシート」にいる誰かを引き続き必要とする/望むでしょう。適切な例（このような例は多数ありました）：PFB-008（RCEの脆弱性）の作業中、私は（いくつかのヒントを使用して）繰り返しそれをプッシュする必要がありました。Opus 4.8（私の claude ステップがサイバーセキュリティ関連トピックを認識するとダウングレードされる）は何度も諦め、「見つけたものでRCEを達成する方法はない」と私に伝えましたが、私の知識と見つかったROPガジェットの手動レビューにより、私はまだそう考えていたので、押し返し、最終的にモデルを正しい方向に導きました。（「あなたは完全に正しいです！... blah blah blah」）

ただし、1つのこと：

はい、PHP、Next.js、または数日前のカーネルのように、大量のクリティカルなCVEも目にしていますが、既存のものをすべて調べ終えたら、これらのCVEが実際に減少する転換点があるのだろうかと思っています（生成されたコードも同じ問題に苦しむでしょうが、ちなみに、生成されたコードの安全性と人間が書いたコードの安全性に関する、読む価値のある記事を見た人がいたら、メールをください！）。

しかし個人的なメモとして：

私はまだAIの部分を声に出して話すことに抵抗がありません（この事実は確実にバラバラにされるでしょうから、覚悟してください）。もし慎重な方法でソフトウェア、特にIoTデバイスをはるかに安全に使用できるようにするツールが現在あると確信しています。私が意味するところは：OSSプロジェクトを破壊するのをやめてください - Daniel StenbergのcURLに起こったことを見てください。cURLのSummer of bliss中に、実際の発見といくつかの幻覚的なナンセンスを整理するために必要な作業のため、問題の受け入れを一時停止しました。ただし、Stenbergが報告するにつれて品質は徐々に向上しています。

このスクリプト AIキディ問題に対する実用的な解決策がない限り、人々は広範なOSSコミュニティへの実際の負担について正当に不満を言っています。

</rant>

本日出荷されているもの

Prusaの修正はBuddyファームウェア7.0.0（最新は8.0.0です。はい、新しいバージョン番号システムも少し紛らわしいと思います）で出荷されました。この記事のすべての発見は、対象となる15台のプリンターすべてに影響します：CORE One L+, CORE One L, CORE One+ (Gen 2) INDX, CORE One INDX, CORE One+ (Gen 2), CORE One, XL+, XL, MK4S, MK4, MK3.9S, MK3.9, MK3.5S, MK3.5, および MINI。お使いのプリンターがリストにある場合は、アップデートしてください。Prusaは本日、GitHubで独自のAdvisoryとソースリリースを公開しました。実世界での悪用は私のプリンター（リックロールされたもの）を除いて認識していないとのことです。

そのソースリリースはv7.0.0リリースタグであり、7.0.0ソースが含まれています。

すべての14件の発見に関する完全な書き込みは、修正とともに公開され、上記の各発見からリンクされています。

3Dプリンターはおもちゃではありません。ネットワークスタック、クラウド統合、USBホスト、ファイルシステムパーサー、署名チェックパス、およびシリアルバスで通信するマイクロコントローラーを備えており、それらは誰かの家のヒーターやステッピングモーターにボルト留めされています（そのため、ある程度のリスクが伴います。そのため、問題がパッチされるのは非常に理にかなっています）。それらに欠陥があることに驚きません。すべてに欠陥があるからです。それらを可能な限り安全にしましょう！

私をまだ驚かせているのは、受け取った対応です。私はこれを2回公開で行い、一度は法律事務所からの応答と刑事コードの引用（笑）を受け取りましたが、もう一度は、私の作業を再現/検証し、クレジットのスペルをどのようにしたいか尋ね、報酬でこの作業への感謝を示した（私は何かを学ぶためだけに行いましたが）適切なエンジニアを受け取りました。それらの間には世界があります。

その2つの応答のうち、1つだけが次の研究者が電話を取るようにします。

楽しい時間をありがとう！

Cheers, Y