ビットコードの終焉はアプリケーションセキュリティの将来に何を意味するのか? - TechRepublic

ビットコードの終焉はアプリケーションセキュリティの将来に何を意味するのか? - TechRepublic
開発者が開発者向けソフトウェアを起動
画像: Konstantin Savusia/Adobe Stock

アプリ開発者にとって、Low-Level Virtual Machine(LVM)ビットコードは、過去7年間、AppleのツールチェーンとAndroid Native Development Kit(NDEK)の定番でした。今年からiOSとmacOSの開発標準となるXcode 14ベータ版のリリースに伴い、Appleはビットコードアプリのビルドオプションを廃止しました。

ビットコードを中心にコード難読化のアプローチを設計・統合してきたアプリケーションセキュリティ業界にとって、これは甚大な影響を及ぼします。セキュリティベンダーが適応しなければ、そう遠くない将来、多くのアプリがセキュリティに大きな穴を抱えることになるかもしれません。

コード難読化とは何ですか?

コード難読化は、コードを保護する強力な手法であり、アプリケーションセキュリティ製品に不可欠な要素です。難読化の背後にある考え方は、実行ファイルを改変することで、ハッカーにとって透明性を失わせながらも、完全に機能し続けるようにすることです。

参照: モバイルデバイスのセキュリティポリシー(TechRepublic Premium)

難読化は効果的に実施すれば、プログラムのリバースエンジニアリングを極めて困難にするため、機密性の高い知的財産を保護するために用いられます。例えば、企業が競合他社に解読されたくないアルゴリズムを隠すために、特にセキュリティコードを保護するために難読化が用いられます。

アプリシールドの分野では、アプリが安全に動作する環境を確保するために、様々なツールを活用しています。フック検出、アンチデバッグ、改ざん防止といった機能が含まれますが、皮肉なことに、これらの機能は適切に隠蔽されていない限り、改ざんや削除の危険にさらされます。そのため、難読化はこれらのツールを保護するために用いられます。

難読化は3つの異なるレベルで導入できます。ソースコードベース、ネイティブバイナリベース、そして最も広く普及している中間レベルです。多くのコンパイラとネイティブコードの間には、最適化が行われる中間層が存在します。

低レベル仮想マシン(LLVM)は、その最もよく知られた例です。LLVMは、あらゆるプログラミング言語のフロントエンドと、あらゆる命令セットアーキテクチャのバックエンドを開発するために使用できるコンパイラとツールチェーン技術のセットです。LLVMは、ClangやRustcなどのコンパイラが、X86_64上のLinux、armv7、iOS、Windowsなど、さまざまなバックエンドをターゲットにできるという点で便利です。難読化ツールがこのレベルで動作する場合、フロントエンドのコンパイラ言語やバックエンドのマシン命令セットに縛られないため、構築と保守が最も容易になります。

しかし、欠点が一つあります。それは、多くの場合、ツールチェーンに縛られていることです。iOSやmacOSのアプリの場合、中間レベルで難読化を行うと、Xcode 14などのAppleの統合ソフトウェア開発システムに変更や大幅な改修が行われる可能性があります。

ビットコードとは何ですか?

ビットコードは、LLVM の中間表現のシリアル化バージョンです。

LLVMがアプリ開発、ひいてはビットコード開発で広く利用されている大きな理由は、オープンソースであり、誰でも利用できることです。そのため、多くのベンダーがビットコードに対応する難読化ツールを開発しています。これらの難読化ツールの利点は、多くのバックエンド、そして通常は複数のフロントエンドを対象とすることができることです。LLVMライブラリがビットコードを操作するために必要なすべてのAPIを提供していることも、LLVMの優位性をさらに高めています。

Appleはこれまで、Intel、arm32、arm64など複数のCPUアーキテクチャに対応していたため、ツールチェーン内でビットコードを活用してきました。Appleは、場合によってはアプリをマシンコードではなくビットコード形式で提出することを義務付けています。これにより、Appleはインストールするデバイスに合わせて最終段階のマシンコードへのダウングレード処理を実行できるようになりました。

今後の Xcode リリースによって、bitcode はどのような影響を受けますか?

Appleは現在、すべての新ハードウェアでarm64を採用し、LLVMが提供する柔軟なバックエンドを必要としない段階に到達しました。特に、WWDC 2022の基調講演では、このアーキテクチャに完全に特化した最適化が可能になるとの言及があり、これはLLVM中間層が将来的にその目的で使用されなくなる可能性を示唆しています。

これを受けて、Xcode 14ベータ版では大幅な改訂が行われ、Appleはビットコードアプリのビルドオプションを非推奨としました。iOSおよびmacOSの開発者は引き続き警告付きでビットコードを使用できますが、これは後日削除される予定です。つまり、ビットコードアプリの開発は以前ほど容易ではなくなりました。

これはなぜ重要なのでしょうか、そして誰が影響を受けるのでしょうか?

今後のXcodeリリースでは、セキュリティベンダーによるビットコードの使用が禁止される可能性があります。難読化ベンダーは通常、ビットコードの難読化に2つのアプローチを採用していますが、それぞれ影響が異なります。

最初のアプローチはアプリの難読化です。難読化ツールは、ビルド後にアプリ全体をビットコード形式でIPAまたはXcarchiveファイルとして処理します。これは、難読化ツールをツールチェーンに緊密に統合する必要がなく、個々のモジュールではなくアプリ全体に対して難読化を適用できるため、優れたアプローチです。

2つ目はツールチェーン統合型のアプローチです。難読化ツールがAppleツールチェーン内のコンポーネントを置き換えたりパッチを適用したりすることで、ビルドプロセス中に確実に呼び出されるようにします。このアプローチはメンテナンス上の問題を引き起こす可能性がありますが、通常は既存のclangコンパイラのラッパーを作成することで軽量な統合を実現します。

最初のアプローチは事実上非推奨となりました。この方法を使用しているベンダーは、少なくともあと1年間は(警告を出しながら)作業を続ける可能性が高いでしょう。ただし、この方法はXcode 15または16では使用できなくなる可能性があります。

2つ目のアプローチも、AppleがLLVMをいつか削除するか、あるいはコンパイラでLLVMへのアクセスを遮断するかどうかは不明であり、将来的に不安定になる可能性があります。場合によっては、事前の警告なしに行われる可能性もあります。iOSおよびmacOSアプリの保護にLLVMベースの難読化ツールを現在使用しているすべてのベンダーは、この変更の影響を受けるでしょう。

これはアプリケーション セキュリティの将来にとって何を意味するのでしょうか?

AppleがCPU、GPU、MLアクセラレータの統合アーキテクチャの活用を目指すにつれ、LLVMは最終的にはその有用性を失い、場合によっては完全に消滅するでしょう。Xcode 14には、この点でLLVMと競合するツールチェーンコンポーネントが既に含まれています。LLVMが消滅すれば、今後Appleのプラットフォームの保護ははるかに困難になり、そのための製品を提供するベンダーは減少するでしょう。

この大改革により、App Storeにある多くのアプリのセキュリティが危険にさらされる可能性は十分にあります。実際にそうなるかどうかは、セキュリティベンダーの適応力にかかっています。ツールチェーン統合型のアプローチを採用しているアプリは当面は問題ありませんが、将来、このアプローチが予告なく閉鎖されるリスクを負うことになります。

今後、ネイティブバイナリベースの難読化手法が増加する可能性が高いでしょう。この難読化手法の主な違いは、ビルドされたマシンコードを直接操作することです。この手法は実行が非常に難しく、多くのバイナリ形式やCPU命令セットのサポートが必要になる可能性があるため、現在この手法を採用している難読化ツールは多くありません。

いずれにせよ、コード難読化の将来は不確実かもしれませんが、1つ確かなことは、アプリ開発者は、アプリの安全性を確保したいのであれば、セキュリティベンダーを監視し、それに応じて計画を立て、積極的なアプローチを取る必要があるということです。

アンドリュー・ホエリー

アンドリュー・ホエリーは、ノルウェーのアプリセキュリティ企業Promonのシニアテクニカルディレクターです。ペネトレーションテスト、アプリケーション強化、コード難読化、暗号化、ブロックチェーンの分野で豊富な経験を持つアンドリューは、Promonの研究開発チームを率いて、同社のコア製品スイートに新たなセキュリティ機能を追加し、強化に取り組んでいます。 

Tagged: