アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
これって (スコア: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)