ARM/XScale/PPCにNULL-pointer脆弱性、家庭のルータにも影響 27
ストーリー by kazekiri
ほぅ 部門より
ほぅ 部門より
ガッなのでAC 曰く、
C でよくある NULL-pointer dereference は、単独ではせいぜい DoS 脆弱性にしかならない問題として看過されがちだ。 しかし CanSecWest 2007 においてJuniper Networks の Barnaby Jack は、一般的な ARM/XScale アーキテクチャ製品がNULL-pointer 書き換えが任意コードの実行に直結する設計になっているという調査結果を発表した。PowerPC も下位アドレスに例外処理を格納しているため、同様の攻撃が可能であろうと見られている。これは特にルータなどの組み込み機器で常時 SVC モードになっている場合に、いとも容易に exploit できてしまうことを意味する。 要約 PDFによれば、この攻撃は 0x0 付近を書き込めなくしたり (MMU) 使わないようにする (HIVECS) ことで回避することができる。
ぜんぜん大丈夫 (スコア:4, おもしろおかしい)
# 絶対AC
もう一つの問題点 (スコア:3, おもしろおかしい)
ハードウェアハッキングが増加すると予想されている。
Re:もう一つの問題点 (スコア:1, すばらしい洞察)
Re:もう一つの問題点 (スコア:1)
# 昔みたいに内部OTP+外部EPROMって時代でもあるまいに…
MCU内部にデバッガの最低機能仕込んどいてシリアルで外部のデバッガとつなげばいいんじゃない？と言う説もありますけど、今のMCU利用製品は周辺回路が高度化している上にMCUのひとつの端子に多くの機能を付加していますからね…最終的にはバスタイミングと命令実行タイミングを厳密に見る必要もある訳で、ブートローダ内蔵のモニタでやれる範囲で決着が付かないことも出てきていますし。
まぁ、そういう事を抜くにしても、ワンチップMCUの範囲内で完結させて、なおかつ書き換え禁止設定をしておいて内部をロックでもしておかない限り、ハードウェアクラッキングはJTAGがあろうがなかろうができてしまう訳で。
外部のプログラムROMなり外部記憶としてのフラッシュROM(＋展開用のRAM)なりがあれば、そこをひっぺがしてコードを読んでしまうという荒技もありますしね(^^;
# まぁ、手段はどうであれ内部のROM読めればそのMCUのまっさらなのを買ってきてそこにクラックしたプログラム仕込んで載せ替えるという
# 方法もありますけど、そこまで行ったらなんでもありなわけで。
TYPO (スコア:1, 参考になる)
Juniper Networks
# それだけなのでAC
これって (スコア:1)
「やっぱり何事もほどほどに」っていう東○寺駅近くにある某社からの人生の訓示なのかなぁ。
それでも団長腕章欲しいよ。
すたー○いと！ぶれいかぁ！（笑）
Re:これって (スコア:2, 参考になる)
大抵のRISC系のMPUや8/16bitの統合型MCUは0番地にリセットベクタ置いていますから（今まで私が使ったことがある石では。ですが…Freescaleの68HC11系は6809系を継承していて後ろの方にベクタ置いていたと思いますが、Z80系を継承していたり独自に開発したのはどうだったやら…）、この手の事は回避できないでしょう。
とはいえ、MMUの設定さえしっかりやってカーネルモードのプログラムでもブートシーケンスの後はそこいらへんを弄れないようにブートローダでしっかりやっておけば防げるから、PPCやCellを積んでいるパソコンなどではそんなに気にしないでいいと思いますよ。
ブートローダ自体を、ベクタ領域を後からexproit出来るようなものにすり替えれば話は変わりますが…
まぁ、この手の物でややこしいのはMMU（と言うか仮想アドレスによる保護機能）非対応のRTOS(μITron v3以前の規格に忠実な実装のOSとか…）載せている組込み系の製品ではないかと。
この手の物だとメインプログラム乗っかってるROMなりHDDなりを書き換えられれば（勿論、ブートローダのチェック機能を回避することも含めて）いくらでも悪さできますからね。ベクタだけ書き換え不能化してあればリスクは低減できますが。
そういう意味では、パソコンやゲーム機などの「比較的高級な」OS乗っかってる物は、リスクは極めて低いと思いますよ。
（と言うか、それを言い出したらWindowsもLinuxなどといった「高級な」OSカーネルも、同じようにアコギな真似をしてベクタ領域を書き換えられると言う弱点を理論上内包している訳で…）
Re:これって (スコア:2, すばらしい洞察)
> まぁ、PPCやARM系に限らず、リセットベクタか外部割り込みベクタの物理アドレスがわかっていて、
> そこにアドレスを直書きするのではなく、「JMP xxxx」のような4bytes (又は8,16bytes)のジャンプ命令が
> 書けるMPUならば、なんでもこの手の攻撃はやられるでしょうね。
んなこたぁ敢えて主張するまでもありません．任意のアドレスを弄れるなら，もっと直接的な攻撃方法も考えられます．
今回のレポートの着眼点は，NULL-pointer脆弱性と組み合わせることで，実行時の乗っ取りが割と簡単に成功する(かもしれない)ということですよ．
from もなか
PowerPC (スコア:1)
ふつーROMがあるのでは？ (スコア:1)
// そもそもSVCで動いていると想定した時点でやりたい放題じゃんとも思うID
from もなか
Re:ふつーROMがあるのでは？ (スコア:2, 参考になる)
2. ページ単位のアクセスだけでメモリマップできない Flash ROM （NAND Flash にはできないのが多い）の場合はRAMに展開するしかありません。
Re:ふつーROMがあるのでは？ (スコア:1)
それって，ARM/XScale/PPCの0番地付近で一般的に見かけるケースですか？
DigiのNS93xxのように，0番地にRAMを置く気満々なアーキテクチャも無くはないですけれど，
ああいうのはARMの中でも極めて少数派だと思うのですよ．そうでもないのかなぁ．
from もなか
Re:ふつーROMがあるのでは？ (スコア:1)
ブート時だけ外部バス領域が0番地にかぶさります。
SamsungのS3C2410 (ARM9系) は、0番地にNOR Flash を置くこともできますが、NAND Flash を使う場合は
リセット時に内蔵SRAMが0番地にマッピングされます。(Flashの最初のページが内蔵SRAMにコピーされる)
多数派ではないかもしれませんが、0番地にROMが無いシステム構成は、それほどめずらしくないのではないかと思います。
Re:ふつーROMがあるのでは？ (スコア:1)
> それほどめずらしくない
それでもやはり，ARM/XScaleを俯瞰すると，珍しい部類ではないかしら．(←主観です．)
でも，ARM7系のremapの利用率次第では，様相はがらりと変わってきますね．
私は，使わないと思っているけれども，定量評価をしたわけでもないし．
from もなか
Re:ふつーROMがあるのでは？ (スコア:1)
ブートコードでROM→RAMコピーをした後にROMを切り離すという実装はよくある実装じゃない？
volatile long *ptr;
for( ptr = ( volatile long *)0; ptr < ROM_SIZE; ptr++){
*ptr = *ptr;
}
// ここでROM切り離し。
最近はROMもマイコンに内蔵だからこういう実装は少ないのかな。
Re:ふつーROMがあるのでは？ (スコア:1)
特に省ピン品のARM7系では，外部メモリが実質使えなかったりしますし．
#1180635 で示唆した通り，ARM/XScale系ではremap(or HIVECS)を使うのが定石でしょうね．
しかし，ARM/XScaleのいずれも，割り込みや例外の要因毎にダラダラとベクタが並ぶタイプではありません．
ベクタをRAMに置きたがる積極的な理由はないはずなのですよ．
間接ジャンプ1個追加しても占有メモリへの影響は誤差範囲なのです．
from もなか
間接ジャンプを嫌う理由 (スコア:0)
OSにハンドリングさせたらそんなん無視できると思うんですが…
Re:ふつーROMがあるのでは？ (スコア:0)
Re:ふつーROMがあるのでは？ (スコア:1)
まあ，CPU例外ハンドラを実行時にユーザ定義できるようなRTOSでは，ベクタをRAMにremapするなんていう実装も，考えられなくもないですけれどねぇ．
そういう実装なら，実行時にNULL-pointer脆弱性を持つかもしれないですねぇ．
(ふつうRAMエリアへの間接ジャンプにするとは思いますけれど．身近な例だとGame Boy Advanceとかね)
from もなか
意味が取りにくいのだが (スコア:1)
確かに、0x0000近辺がを書き換えられるならハックされそうだな。
ぬるぽ！ (スコア:0, 荒らし)
ガッ (スコア:0, 荒らし)
（ ・∀・） ＜ 喜びそうだから叩かない
（ ） ＼＿＿＿＿＿＿＿＿＿＿
| | |
（＿_）＿） ∧＿∧
Σ（´Д｀ ）
（ ）
Armadillo (スコア:0)
使っているのでAC