Mazda のインフォテインメントに発生した障害:セキュア・コーディングだけで防げるのか?

Mazda Infotainment Crash Shows How Fragile Car Security Really Is

2022/03/30 BleepingComputer — 今日もまた、車載デバイス・ソフトウェアのクラッシュが発生した。今回、不具合が見つかったのは、2014年〜2017年の Mazda インフォテインメント・システムである。複数のドライバーたちが、ローカルラジオ局に接続する際に、HD ラジオ受信機がクラッシュしたと報告している。具体的に言うと、ラジオとディスプレイ、ブルートゥース、内蔵地図、デジタル時計などが、すべて焼けてしまったとのことだ。報告によると、システム障害は、ラジオ局がファイル名に必要な拡張子を付けずに画像を送信した際に起こった、単純なコーディング・エラーにより発生したようだ。

$1500 の CMU (Connectivity Master Unit) を所有する Mazda オーナーは不満に思うかもしれないが、このバグは比較的無害で、被害は最小限であった。残念ながら、今後も車載システムのソフトウェア障害の報告は続くと思われ、コードへの依存度が高まるにつれて、セキュリティや安全性に影響を及ぼす脆弱性のリスクは指数関数的に増大する。次のバグが、ドライバーに対して、どのような影響を与えるかは誰にも分からない。

Mazda CMU (Connectivity Master Unit) を破壊した単純なコーディングエラー

Mazda CMU のクラッシュを引き起こした、コーディング・エラーの完全な詳細は公表されていないが、NULL デリファレンス脆弱性の一種であると推測される。

その仕組みはこうだ。

C言語には、strchrと呼ばれる関数がある。この関数は、string と character に対するポインタとである2つのパラメータを受け取り、string で character を見つけ出す。そして、見つかった結果へのポインタを return するが、失敗した場合には NULL ポインタを return する。

続いて、このプログラムは、受け取った特定のファイルの拡張子を理解しようとする。
拡張子を見つけるために、おそらく strcmp に似た関数が使用されるだろう。この関数は2つのポインタを受け取り、その内容を比較する。最終的には、デリファレンス・ポインターを介して比較される。

デリファレンスとは、ポインタが指している値を取り出す動作のことである。このケースでは、この関数に NULL ポインタが送られ、関数が NULL の値をデリファレンスするため、例外が発生する。このようなコードの脆弱性は、受け取ったポインタが NULL ではないことを確認すれば、容易に回避できる。

予防と緩和

このような問題を、開発段階で防ぐには、ソフトウェア技術者が、デバイス・ソフトウェアのセキュリティ脆弱性を回避するための、コードの書き方を定義したセキュア・コーディング標準に従うことが必要だ。セキュア・コーディングは、ソフトウェアの脆弱性を防ぐための要素だが、あくまでも一つの要素に過ぎない。

たとえ経験豊富なプログラマーがコードを書いたとしても、常にヒューマンエラーの可能性が生じる。さらに、私たちが利用している製品の多くは、オープンソースやサードパーティーのソフトウェアを含む、サプライチェーンに大きく依存しており、対象となるプログラマーが作成に関与していないものもある。

Mazda infotainment system
Mazda infotainment system

スマートカーにはスマートなセキュリティが必要

自動車メーカーは、ステアリングや、ブレーキ、死角検出など、高度な自動安全制御に多額の投資を行っている。これらのシステムが、ソフトウェアへの依存度を高めているという現実を考えると、なぜ車載ソフトウェアのセキュリティに、同様の注意が向けられないのかと不思議に感じる。

車載デバイスにおけるソフトウェアの脆弱性が、車両の出荷後に発見された場合には、その修正のためのコストは急上昇する。生産中止やリコールに加え、ソフトウェアのバグは、インフォテインメント・システムが故障するという、不便さ以上のものをもたらす可能性がある。そのような欠陥が、重要とされる安全機能で発見された場合には、人命に関わる問題にいたる可能性があるのだ。

車載デバイスのソフトウェア・セキュリティに対する配慮が不十分だと、自動車を時限爆弾に変えてしまう可能性すら生じる。

今日の高度に自動化された車両では、物理的な自動車の安全性を超えたレベルで OEM たちが、設計段階の車両から一般道で走行している車両にいたるまで、セキュリティのためのソフトウェア・バージョン追跡しに焦点を拡大することが求められている。

自動車の安全性確保への道。安全なソフトウェア

脆弱性が存在しない安全な車載デバイスを実現するためには、セキュア・コーディングや手作業によるバグ追跡だけではなく、さらなるステップが必要となる。そのため、すべてのデバイスのファームウェアとコードを継続的に監視し、脆弱性の存在を確認し、エラーを迅速に検出/修正することが必要となる。

企業のトップニュースとして、セキュリティ・リスクが報道される前に、それに対処するには、製品のための自動化されたセキュリティ・プロセスが必要となる。

Cybellum のような、高度な自動車製品セキュリティ・プラットフォームは、ソフトウェアのコードを1行1行を追跡し、ソフトウェアの脆弱性を早期に発見して対処する。
それらのコードが、社内で作成されたものであっても、サードパーティやオープン・ソースから入手されたものであっても、深刻な損害を与える前に、確実に対処することが可能となる。

Mazda のインフォテインメントの事故は、単純なコーディング・ミスが予期せぬ大惨事を引き起こす可能性があることを改めて証明するものだ。幸いなことに、今回の被害はインフォテインメントに限られ、一時的にドライバーをイライラさせただけのものである。自動車メーカーは、自社製品が依存する、すべてのソフトウェアが道路から追い出されないようにするために、デバイスのセキュリティを優先させる必要があるだろう。

このインシデントに関連する記事としては、2021年5月の「Mercedes-Benz のインフォテインメント・システムはハッキングの対象になる?」があり、サーバー側の問題としては、2021年11月の「Tesla の Web サーバーに障害:スマホによるロック解除ができないという報告が続出」があります。また、「コネクテッドカーのインフラ:サイバー犯罪者が狙う格好の標的になる」も、なかなか興味深い記事です。よろしければ、ご参照ください。

%d bloggers like this: