4 ポイント 投稿者 GN⁺ 2023-12-09 | 1件のコメント | WhatsAppで共有
  • ポーランドのNewag製 Impuls 45WE 列車が独立系整備後、診断上は正常にもかかわらず発車できず、整備会社SPSはDragon Sectorにオンボードコンピューターのリバースエンジニアリングを依頼した
  • 研究者らはCANバス解析、TriCoreベースのメモリダンプ、Ghidraの改良を経て、ソフトウェア内のロックフラグと起動条件を突き止め、列車を再び動かした
  • 一部列車のコードには、特定の整備工場のGPS座標に10日以上とどまると起動を阻止する条件、部品交換によるロック、100万km後の故障条件、日付ベースのコンプレッサー故障報告条件が含まれていた
  • 解析対象は合計29編成で、5編成を除く列車から公式運用指針外の「surprises」が見つかり、Wrocław、Opole、Krakow、Szczecin、Warsawなど複数地域へ問題が広がった
  • 事件は訴訟と法執行機関の調査につながったが、消費者・競争保護機関や鉄道輸送機関による具体的措置は確認されていない

整備後に停止したNewag Impuls列車

  • 事件は2022年春、Lower Silesian Railwaysが運行するNewag製 Impuls 45WE 11編成のうち最初の列車が、100万kmの義務整備を終えた後に発車できなくなったことから始まった
  • 整備は独立系整備会社 Serwis Pojazdów Szynowych(SPS) が担当した
    • Newagも入札に参加していたが、メーカー側の提案は約75万ドル高かった
    • SPSは11編成の整備を約550万ドルで実施する条件で落札した
  • SPSはメーカー提供の約2万ページに及ぶ整備マニュアルに従って列車を分解・点検・組み立てたが、オンボードコンピューターが正常と表示している状態でも列車は動かなかった
  • インバーターがモーターに電圧を供給しておらず、整備技術者らはマニュアルと電気・機械点検だけでは原因を突き止められなかった

繰り返される停止と高まる契約リスク

  • 2編成目の列車も同じ整備後に同じ方法で停止し、メーカーのNewagは支援を拒否した
  • 3編成目はバッテリー問題で検査を逃し、代わりに4編成目が整備工場に入った
    • 4編成目の正常運行列車を停止中の列車に接続すると、正常な列車も停止した
    • この原因はまだ確認されていない
  • Szczecinの別の整備工場でも、整備後に Impuls 列車が起動しない事例が発生した
  • Lower Silesian Railwayの長編成6本が抜けたことで、ダイヤ縮小、代替列車投入、より短い編成の混雑が続いた
  • Newagは列車が「安全システム」によって遮断されたと説明したが、2万ページのマニュアルには該当システムへの言及がなかった
  • 整備工場で停止している列車1編成あたり1日1,000ドル以上の契約上の違約金が発生し、SPSの負担は増していった

Dragon Sectorによるリバースエンジニアリング

  • SPSは「Polish hackers」を検索してCTFで知られる Dragon Sector を見つけ、両者は契約を結んだ
  • プロジェクトにはMichał “Redford” Kowalczyk、Sergiusz “q3k” Bazański、Kuba “PanKleszcz” Stępniewiczが参加した
    • Redfordとq3kはToshibaノートPCのハッキングで知られる人物たちである
    • Kubaには産業オートメーションの経験があった
  • 現場で研究者らは、動かない列車、予備コンピューター2台、コンピューターメーカーのSDKファイルを受け取った
  • 初期解析は CANバス をタップする方法で始まったが、プロトコル文書がなく、トラフィックの解釈は難しかった
  • SDKは新しいソフトウェアのアップロードだけをサポートしており、既存ソフトウェアのダンプ機能はなかった
    • 見つけた旧バージョンのソフトウェアを1台目の予備コンピューターに載せると、そのコンピューターは応答しなくなった
    • 研究者らは残った予備コンピューター1台で作業を続けた
  • 最終的にデバッグインターフェースを見つけ、デバイスメモリをバイト単位でダウンロードした
  • オンボードコンピューターは自動車分野でも使われる TriCore アーキテクチャベースで、優れた逆アセンブラが不足していたため、Ghidraを一部改良してコードを解析した

締め切り直前に見つけた起動条件

  • 1カ月半ほどが過ぎた後、Lower Silesian Railwayはこれ以上待てないとして、Newagと故障列車の修理および整備協力を決めた
  • SPSとの契約解除は1週間後と見込まれ、研究者らは残り時間の中で成果を示す必要があった
  • 研究者らは正常列車と故障列車のコンピューターメモリイメージを比較した
    • 列車ごとに機能セットとソフトウェアバージョンが異なり、単純比較は難しかった
    • 一部の列車で設定されていた値が、別の列車では0になっている差分を見つけた
  • コンピューターを列車から取り外した状態でも短時間実行してインバーターの運転準備状態を確認できたため、机上テストが可能だった
  • 締め切りまで1日も残っていない時点で、列車を動かせる可能性のあるフラグ構成を見つけたが、実験中に最後の正常なオンボードコンピューターのコンデンサーが焼損した
  • 損傷したコンピューター2台を組み合わせる試みの末、焼けたコンピューターを修理し、午前2時に列車起動用に設定した
  • 研究者がそのコンピューターを持って整備工場へ向かったが列車が遅れ、現場到着後に接続したコンピューターでも最初は列車が起動しなかった
  • 追加の議論の末、欠けていたフラグを1つ見つけ、午前8時42分に列車の起動に成功した
  • 午前9時30分、Lower Silesian Railwayの代表団は列車が復活する可能性を確認し、SPSとの契約を解除しなかった

コードに隠されたロック条件

  • 数カ月にわたる解析とリバースエンジニアリングにより、Newagが供給した複数の列車ソフトウェアから、突然の運行不能を引き起こす条件が見つかった
  • コード内の 53.1384517.99011 といった数字はGPS座標で、Bydgoszcz Główny Railway Station近くのPESA敷地を指していた
  • その後、ポーランド国内の他の整備・修理可能な工場の座標も見つかった
  • 列車が特定の整備工場エリアのいずれかに少なくとも10日間とどまると、起動能力を無効化する条件がコードに含まれていた
    • 座標の1つはNewag自身の整備工場だった
    • Newag整備工場の座標には別の論理条件が定義されており、テスト目的だったと推定される
  • 他の列車からは別のロック条件も見つかった
    • 特定部品が交換されると、部品のシリアル番号確認によって列車を遮断する
    • 運転室とオンボードコンピューター画面で特定のボタン順序を押すと、ロックを解除できるオプションがあった
    • Impulsの起動成功のニュースが報道された後、列車にはこの「fix」オプションを削除するソフトウェアアップデートが適用された
    • 別の列車では、100万km後に「故障」するよう指示するコードが見つかった

日付条件で発生したコンプレッサー故障報告

  • 別の1編成は、2022年11月21日に整備中ではなかったにもかかわらず動作を拒否した
  • コンピューターはコンプレッサー故障を報告したが、整備士らはコンプレッサーに問題はないと見ていた
  • コード解析の結果、次の条件が見つかった
    • 日が21以上で
    • 月が11以上で
    • 年が2021以上なら
    • コンプレッサー故障を報告する
  • この列車は本来2021年11月に整備予定だったが、実際にはより早く整備に入り、2022年1月になってようやく復帰した
  • 2021年11月には条件が偶然発動せず、2022年11月21日になって初めて予定された故障条件が満たされた

ハードウェアで見つかったGSM接続装置

  • ソフトウェアだけでなく、ハードウェアからも奇妙な装置が見つかった
  • ある列車セットで研究者らは「UDP<->CAN converter」と表示された装置を発見した
    • リモートで列車と通信できるようにする装置に見えた
    • 装置を取り外しても動作が停止する機能はなかった
  • オンボードコンピューターはロック状態情報をこの装置に送っており、装置自体はGSMモデムに接続されていた

複数地域へ広がった問題と解析規模

  • SPSがNewagの「故障」列車を直したというニュースは他社にも広がり、似た問題が一般的であることが明らかになった
  • Wrocławでは 13編成のImpuls が解析された
  • 他地域でも問題のある列車が確認された
    • Kolej Mazowieckie 1編成
    • Opole 2編成
    • Krakow 4編成
    • Zielona Góra 1編成
    • Szczecin 4編成
    • Warsaw 1編成
  • 研究者らが作ったツールはオンボードコンピューターのソフトウェアロックを解除し、各列車は修理できた
  • 合計29編成のソフトウェアが解析され、そのうち5編成を除く列車から公式運用指針外の要素が見つかった

その後の対応と公開範囲

  • この件では訴訟が進行中である
  • ポーランドのOffice of Consumer and Competition ProtectionやRailway Transport Officeが具体的措置を取ったかどうかは知られていない
  • 研究者らは発見内容を CERT Polska に通知した
    • CERT Polskaは「関係当局」に知らせた
    • 事件は法執行機関が扱っている
  • この内容は、2023年12月5日の Oh My H@ck カンファレンスでJakub Stępniewicz、Sergiusz Bazański、Michał Kowalczykが発表した内容を簡潔にまとめたものである
  • 原文は技術解析全体のかなりの部分を省略しており、研究者らが別途技術文書を作成して公開することを期待していると述べている

1件のコメント

 
GN⁺ 2023-12-09
Hacker Newsの意見
  • 関連する最新の投稿もある: Polish trains lock up when serviced in third-party workshops - https://news.ycombinator.com/item?id=38530885 - 2023年12月、コメント347件

  • ここまで厚かましいのは信じがたい。GPS座標が競合整備業者のエリア内に10日以上留まると機関車を文鎮化するコードだなんて
    文書化されていないインターフェースや暗号署名付きファームウェアのように修理を難しくする程度をはるかに超えていて、悪意ある財産破壊に近いと思う。ポーランドの法体系は知らないが、これがどうやって許されるのか想像もつかない

    • 利害対立のせいで法的地獄に陥る可能性が高い
      列車はすでに存在し運行されなければならないが、整備・修理会社は著作権のためにソフトウェアを合法的に修正できない。完全な板挟みだ。その会社が巨額の罰金を科され、刑事処罰まで受けてほしいが、実際にそうなるかは疑わしい
    • 個人がこんなことをしたなら刑務所行きだったはず
    • これは財産破壊というより、悪意ある行為者が金を稼ぐためのサービス拒否攻撃に近く見える
      やる気のある法務チームなら適用可能な重大な容疑を見つけられそうだ。特に当該列車や機関車が重要インフラに当たるならなおさらだが、それが保証されているわけではない
  • 秘密のハンドシェイクを入れ、手順書を不十分にして競合を無能に見せるのと、競合の整備工場に入ったという理由で自社製品を意図的に故障させることは次元が違う

  • タイトルは少し誤解を招く。この件の「ゲート」は、Dieselgateのように人工的な条件で認証を通すため環境性能をごまかしたのではなく、偽の故障をシミュレートしたという意味だ
    会社は位置情報に基づいて他社が列車を修理したと判断すると、コンプレッサーのような正常に動作する部品に故障が起きたかのように報告し、列車の運行を停止させるアルゴリズムをハードコードしていた

    • 産業用ロジックコントローラを逆コンパイルして明らかになった詐欺的・悪意ある行為であり、違法性を裏付ける反論しがたい証拠がある
      もちろん両事件が完全に同じとはいえないが、なぜそういう比喩が出てきたのかは明らかだ
    • 私の理解では、その説明は正確ではない。ここには実際に2つの別個の行為がある
      1つは、GPS基準で競合整備場所に10日間留まった後、列車が動作しないようにしたこと。もう1つは、特定のファームウェアで次回予定整備の数日後にコンプレッサー故障が起きたように見せかけるようハードコードしたことだ
  • 「ポーランドでこの件について丁重な関心表明以上のことをした機関を見つけるのは難しい。消費者・競争保護庁や鉄道交通庁が何らかの措置を取ったのかも分からない」という部分がいちばんひどい

    • いまや政府の反腐敗機関が正式捜査に入っているので、ほぼ確実に誰かは刑務所に行くことになると思う
      消費者保護機関はこれらの機関ほど権限が強くない
    • こうした行為が処罰されないのを企業が見れば、競争力を維持するために結局それぞれが自分たちの版を実装しなければならなくなる
  • 関連記事の前回投稿の議論も参考になる: https://news.ycombinator.com/item?id=38530885

  • 排ガス試験の不正や第三者修理妨害のような奇妙なエンジン制御問題の解決策は、こうしたシステムのインターフェース標準化かもしれない
    センサー出力が標準化されれば、さまざまな構成要素を差し替えながら、システムが規制当局を欺いていないか確認できる

    • F1はそうしている。すべてのチームは承認された同一のECU[1]を使わなければならない。特定のマッピングテーブルなどは変更できるが、装置は封印されており、ファームウェアを入れ替えることはできない
      [1]: https://wheelsports.co/formula-1s-standardised-ecu-explained...
    • 自動車には、センサーデータを横取りして偽データをECUに返し、排ガス制御を回避する装置がある。かなり簡単にできる
      WRXを持っている友人がいるが、触媒もなく、大きなターボとチューニングまでされているので、絶対に排ガス検査を通ってはいけない車だ。ところがセンサーデータが合成されて関連部分を制御するため、エラーコードも出ず、毎回問題なく通過する
    • メーカーに対して、顧客へ完全なソースコードとソフトウェア更新・交換ツールを提供するよう義務付けるだけでもよさそうだ
      ファームウェアというブラックホールをなくし、監査可能にしてほしい
    • 標準化だけでは少し足りない。ソフトウェア変更の障壁も取り除かなければならないからだ
      完全な標準化までは必要なく、公開性があるだけでもよい。それでも基本的にはその方向性で合っている
  • メーカーのサービスではなく、より安い第三者サービスを使えないようにするため、ソフトウェアで意図的な妨害をしたように見える
    裁判所がどう判断するのか気になる

    • 妨害行為であることに疑いの余地はない。残るのは犯人を立証することだけで、動機・手段・機会を見れば99%メーカーに見えるが、誰が責任を負い刑事責任を問われるべきかは当然法廷で確定されなければならない
      立法者、裁判所、大衆が技術問題の前で道に迷うのは問題だが、この犯罪は既存の妨害行為に関する刑法に十分当てはめられるはずだ。手口は「新しい」が、犯罪そのものは古典的だ
  • 列車ファームウェアの品質は全体的にあまり良くないという印象で、このスキャンダルをきっかけにより厳格なレビューが行われてほしい。
    3年前、Deutsche Bahnは新たに納入されたBombardier車両の「奇怪な」ソフトウェア問題について公然と不満を述べていた。たとえば運転士が進行方向を切り替えると列車ソフトウェアがクラッシュし、再起動に1時間かかったという [0]。スイスでも2018年に似た問題があった [1]。
    コンピュータ科学者として、これは恥ずかしい。つい最近までここで1950年代の西ドイツ製客車 [3] を牽引していた1980年代の東ドイツ製旧型列車 [2] と比べればよい。デジタル電子機器はほとんど、あるいはまったく搭載されておらず、起動時間もなかった。ただ動いた。動かなければ、運転士はたいていエンジンのどこをハンマーで叩けば直るかも知っていた。運転士に列車ファームウェアをハックして gdb を立ち上げ、なぜ動かないのか調べろと期待することはできない。
    [0] https://www.sueddeutsche.de/wirtschaft/deutsche-bahn-ic-1.47...
    [1] https://bahnblogstelle.com/33872/twindexx-swiss-express-soft...
    [2] https://de.wikipedia.org/wiki/DR-Baureihe_243
    [3] https://de.wikipedia.org/wiki/N-Wagen

    • ソフトウェアを製品として見ている企業が開発者に与える報酬が、熟練開発者を大量に吸い上げたのだと思う。以前なら面白さゆえにこうした仕事を選んでいた人たちが、今では別の場所へ行ってしまう。
      ソフトウェア入りの製品を作る企業は、ソフトウェア人材に以前の2〜3倍を払う用意のある市場にはいない。残るのは、その面白さを総報酬の差額として受け入れる人たちと、より高給の職に就けなかった人たちだ。私たちが使う大半の 安全クリティカルシステム はこうした人たちが作っている。XとSpaceXの開発者報酬を比べれば、市場がどう機能しているかが分かる。面白さも総報酬の一部ではあるが、優秀ではない開発者たちがこの領域で新しいプロセスやツールを設計する側に回る、という結果も生む。すでに流行遅れになったフルスタック流行を引きずって列車ファームウェアに適用しようとするかもしれない。JiraにはGitの10倍のテキストがあり、スクラム滝落ち式開発を行い、安全クリティカルな組み込みシステムにREST APIやサービス指向アーキテクチャを入れていても驚かない。
    • このソフトウェアはソフトウェアエンジニアが作ったのではなく、PLCプログラマ、電気回路設計者、たまたまその分野に流れ着いた人たちが作ったものだ。
      BeckhoffのTc3あたりを除けば、いまだにオブジェクト指向にすら到達しておらず、分野全体が昔のブルースクリーン鉱山に閉じ込められている。薄い標準文書で複雑さを管理し、バージョン管理すらないまま、機械はセンサーとアクチュエータの面でますます複雑になっている。現代の機械を小さな趣味用組み込み機器のように扱うことはできないが、業界はそうしている。外部のプログラマが入ってきて、まともなソフトウェアアーキテクチャとCの開発慣行で昨日の問題を解決し、しっかり稼ぐこともある。しかし業界はそこから学ばない。彼らにとってソフトウェア開発は永遠に専門職にはならないのだろう。
    • ときには ローテク のほうがよい。フィンランドには1970年代にソ連から導入したSr1電気機関車があり、何度かの改修を経て、少なくとも2030年までは使われ続ける可能性が高い。
    • 私も同感だ。列車のソフトウェア化は、基本的な信頼性と 相互運用性 の両面で大きな後退をもたらした。
      多くの現代の列車は、基本走行ソフトウェアの問題 [0] やソフトウェア承認の遅延 [1] に苦しんでいる。しかし最悪の後退は互換性の喪失だと思う。現代の電車は事実上、同じ一群の編成同士でしか一緒に動けない。同じモデルでも、2社が別々に発注すれば互換性がないことが多く、会社が違ったり発注時期が10年以上離れていたりする電車を一緒に使うのは、ほぼ諦めるしかない。一方、デジタル化以前には、世代の異なるトラムを一緒に使い、配線を変更して合わせることはよくあった。古い客車同士は問題なく一緒に動くが、IC2とRailjet、あるいはRailJetとICE-Lを一緒に使うのは簡単ではない。特定の機関車と客車の組み合わせでしか動かないことも多かった。
      コンピュータ化されたシステム同士は、複雑性が高く不透明性も大きいため、一緒に動作させるのがはるかに難しい。従来のロジック回路基板はたいてい容易にリバースエンジニアリングできるが、ソフトウェアのリバースエンジニアリングは非常に専門的な作業だ。独自のデジタルプロトコルへ移行したことで相互運用性が大きく悪化した他分野でも、この現象は目立つ。
      これは、ソフトウェアが不透明で以前の技術より承認を取りにくいせいでもあるが、実際の品質不足も大きい。Bombardierが大きな苦境に陥った理由の一つも粗悪なソフトウェアで、40編成以上が発注されていた契約が取り消される事態にまでなった ([2])。
      信頼できて理解可能なソフトウェアを作ることは、ロジック回路や機械システムを作ることよりはるかに難しいと思う。解決策は分からないが、昔から続いている問題だ。
      [0]: https://www.vrt.be/vrtnws/de/2013/02/12/belgische_bahn_storn...
      [1]: https://www.augsburger-allgemeine.de/augsburg/Neue-Zuege-auf...
      [2]: https://de.wikipedia.org/wiki/Bombardier_Talent_3#%C3%96BB
    • たいていのソフトウェアについても同じことが言える。最新のフレームワークであるほど、穴がよりはっきり見える。最近の文章では「Software disenchantment」がある: https://tonsky.me/blog/disenchantment/
  • 英語のコンテンツだけを消費している。他国のコンテンツは、大手メディアを通じて漏れ伝わってきたものしか目にしていない
    翻訳されうる良質なコンテンツがどれほど多いのか気になってくる

    • 英語しか読まないせいで見逃している優れたコンテンツがどれほどあるのか、という意味なら、良い視点だと思う
      ただ、英語は少なくとも世界のより高学歴な層では、皮肉にも今や共通語になっており、母語のほうが楽な人たちでも、自分の最高の仕事をより広く読んでもらうために英訳することが多い。科学論文がその代表だ。もしかすると、イギリスが世界に与えた最大の贈り物は英語なのかもしれない
    • ポーランド出身で、その止められた特定の列車に乗っていた可能性もある。Wrocław に住んでいて、Koleje Dolnośląskie、つまり Lower Silesia Railways に乗って近隣を巡っていた。Wrocław 周辺には美しい場所がたくさんある
      ただ、この列車のベンダーロックイン全体については HN で初めて知った。そうでなければ、まったく知らなかったか、知るとしても数週間後か数か月後だっただろう