2012年10月21日

Androidのroot化必須アプリへのリンク・パストラバーサル攻撃

TwitterのTLに懐かし(?)のパストラバーサル攻撃の話が流れていたのでAndroidについて考えてみた。
(たどっても見つからなかったので昨日以前ぽい……)

WindowsNT系を含むPOSIX互換OSとそのファイルシステムでは、相対パスやシンボリックを悪用することで、特権(root)を持つプロセスに意図しないファイル操作を行わせる、という攻撃が昔から存在する。
たとえば、root権を持ったプロセスがシステムのファイルをバックアップ、あるいは展開する、といったサーバー保守作業の過程で、一般ユーザー(例えば共用Webサーバのをレンタルしているユーザ)がシンボリックリンクをタイミングよく作成すれば、他のユーザーやシステムファイルを抜き取ったり、上書きできる可能性がある。
こういった攻撃は古くから知られていて、TarのようなUnixの基盤的なソフトウェアでは基本的にrealpathを利用したりシンボリックリンクを識別して動作を変えるよう対策が行われている。


Androidにはsuからroot権を取得してファイル操作できるアプリには各種あるが、もしrootアクセス時に正しくシンボリックリンクやパスを扱っていないと、この攻撃に脆弱になる。

たとえば、各々のアプリが個別に持っているストレージ(/data/data/アプリ名/など)はPOSIX互換ファイルシステムに置かれるため、サンドボックスの外、たとえばシステムファイルや電話帳ファイルへのリンクを作っておき、アプリバックアップ用のアプリがroot権を取得しバックアップ操作してSDカードに保存されたタイミングで、誰でもアクセス可能なSDカードから情報を搾取することが考えられる。
逆に、/systemなどへのシンボリックリンクを作っておき、バックアップアプリが不用意に復元操作すれば、システムが破壊される恐れがある。

Androidの各アプリサンドボックスはLinuxのユーザーIDを利用しているので、通常の利用ではシンボリックリンクをどう作ろうとリンク先のアクセス権がないので問題は無いようだ。
しかし、自分のデータ領域にアクセスしにくるroot取得アプリが動いている事がわかれば、意図的にroot必須アプリを悪用することが出来るかもしれない。
DRM目的でroot取得可能かどうかやインストール済みアプリをチェックしているアプリは既に存在するので、それらの一つが悪意を持った場合、suにアクセスすること無く特権が必要なデータにアクセスしうる事になる。

自分はJavaがほとんど書けず実機検証できていないが、AndroidAPIや関連情報を見る限り実行は可能に見える。
root化できるユーザはSuperUserのダイアログをチェックできるが、この攻撃にsuへのアクセスとroot権は必要なく、ユーザーが脆弱性に気づくことは難しい。アプリ開発者が気をつけるしか無い。

Link2SDのようにLinuxのファイルシステム特性を理解してアプリ開発している人と利用者は当然考慮しているだろうが、root必須アプリにはよくよく注意したほうがよさそうだ。
(TiraniumBuckupはtar保存だったので、Tarが古かったりオプションを間違えてなければ致命的なことにはならないはず。まぁそもそもデフォルトではSDカードに固定ファイル名でバックアップするのでデータ抜き放題だけど。)
posted by ko-zu at 01:32| Comment(0) | TrackBack(0) | Android | このブログの読者になる | 更新情報をチェックする

2012年10月09日

Android/Xperia Acroへのカーネルモジュール導入についてメモ

Linuxではカーネルの機能がモジュール化されていて、コンパイルオプションで自由にオンオフできる(静的リンク)。さらに、カーネルが起動した後でも、同じモジュールをカーネルに導入できる(動的リンク)

Linuxでは、*.koというファイルが動的リンク可能なカーネルモジュール(kernel objectファイル)になる。
動的リンクされるカーネルモジュールは再起動すれば消えるので、ちょっとやそっとでは文鎮化することが無いので安心できる。(システムファイルやハードウェアを壊すようなバグを含んでなければ)
同じバージョン・同じCPU向けのモジュールなら基本的に互換性があるので、依存関係をしっかり解決すれば、Androidメーカーの作ったカーネルにOSの基幹機能を安全に追加できる。

カーネルバージョンや端末指定で.koファイルが配布されている場合、suシェルからinsmodコマンドでロードしてシステムが壊れないか確認した後で、init.dなどの起動スクリプトで自動導入するようにすればほとんどリスクなく利用できる。
CWMなどを使えば、自動インストールも簡単。

hw_setup.shなど、起動時にrootで実行されるスクリプトにbusybox insmod hogehoge.koと入れておけば、起動時に導入されるし、アプリによってはroot権限取得してインストールしてくれるものもある。


結局自分のAcroは
http://thjap.org/android/xperia-series/2011-xperia/291.html
を参考に、
etc/init.dの 99complite  (sqlite最適化)と 09disablevsync (vsync無効化)を削除して適用

ondemand2がかなり効果があるようで、ロック中の電力消費がかなり減っている。
384MHzでも音楽再生には問題ないようだ。Bluetoothが瞬断しやすくなったかもしれないので少し増やすといいかもしれない。

Android2.3.4のXperia Acroでは、CIFSでWindowsファイル共有をマウントするために、
cifs.ko slow-work.ko(これはandroid独自?) nls_utf8.ko
が必要だった。

cifs.koはWindows共有をファイルシステムとしてマウントする機能そのもの、nls_utf8.koは、windowsのファイル名エンコーディングを、AndroidOS内部エンコーディングに変換するための機能を提供している。

試していないが同様に、USB-OTGでUSBメモリをマウントするには、usb-storage.ko が必要。ファイルシステムがNTFSなら、ntfs.ko、ext4ならext4.ko。

CIFSマウントが実用的とわかってNexus7購入を決断してしまった。
posted by ko-zu at 22:05| Comment(0) | TrackBack(0) | Android | このブログの読者になる | 更新情報をチェックする

Android/Linuxでのファイルシステム文字コードの扱いのメモ


ファイルシステム上のエンコード
最近のファイルシステムはユニコードで決め打ちされているので考慮する必要はない。FATなどの古いファイルシステムでのみ問題になる。(厳密にはUCS-2でUTF-16非対応だったりするけど。)
FAT32ショートファイル名ならShift_JISなど(正確にはcp932)。ロングファイル名(8.3形式でない名前)は後付け規格なので問題ない。

OSの内部エンコード
基本的にUTF-8。

Linuxネイティブソフトウェアのエンコード
ソフトウェアが解釈できるエンコードはソフトによる。ASCIIしか表示できないアプリもあれば、UTF-8を解釈できたり、EUC-JPのままだったりする古いアプリもある。

Androidアプリのエンコード
Java自体ユニコードに対応しているので、HTTPなどで外から取得したバイナリを下手に変換しない限り考慮する必要は無い。

マウントオプション
vfatマウントについては、
http://archive.linux.or.jp/JF/JFdocs/kernel-docs-2.6/filesystems/vfat.txt
がわかりやすい。

XperiaAcroのマウントオプションは(noatimeに上書きしているけどfatは意味ないはず)
/dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,noatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
Xperiaデフォルトの文字コード関連オプションは、codepage=cp437,iocharset=iso-8859-1,utf8なので、ショートファイル名には1バイト文字、ロングファイル名とOS内部とのIOはUTF-8変換がなされる。
もし接続したSDメモリなどのショートファイルに日本語文字が含まれてしまっていて、正しく読み書きできない場合は、codepage=cp932にすれば解決するはず。

USB-OTGでFATファイルシステムをマウントする場合、マウントオプションでcodepage=cp437,utf8を指定すれば、windowsマシンに持って行っても文字化けしたりアクセスできなくなることは無いはず。

だけど、デザイアさんが四苦八苦していた。有償版StickMountが発行するマウントオプションが知りたい。
もしかしたら、nexus7はSDメモリ非対応なのでFAT用のnls_cp437が入っていないのかも。nls_cp437.koとnls_utf8.koをいれればどうにかなるかも?

なおCIFSで日本語の読み書きにはiocharset=utf8にする必要があった。
ウィンドウズファイル共有自体はUTF-16で決め打ちなので、SMBプロトコルとOS内部間でUTF-16/UTF-8変換が必要で、nls_utf8.koも同時に必要だった。



posted by ko-zu at 19:54| Comment(0) | TrackBack(0) | Android | このブログの読者になる | 更新情報をチェックする

2012年10月08日

Android端末から自宅NASをマウントしてみた

root化済みAndroid端末にCIFSのカーネルモジュール導入して自宅のNAS(samba3/fedora)をマウントしてみた。

WiFi環境は11nで、SMBユーザライブラリでの接続は上下ともに実効500〜800KB/s程度出る(ワイヤレートで10Mbpsくらいでてるのかな)
転送速度の律速は恐らく端末でのWifiのAES暗号処理速度。ノートPC(古いVAIO)では最大15MB/sほど出ていた。

マウントオプションは iocharset=utf8 (utf-8だと思って小一時間ハマった。)だけで日本語の処理も問題無さそう。
linuxのioバッファがcifsも共用かわからないけれど、念のためSD Speed Increseで4096KBに拡大してある。

動画
300kbps〜100kbps程度にトランスコードして保存してあるニコ動をMX動画プレーヤで再生。
1000ファイル50フォルダほどあるせいでリスト作成に時間がかかるものの、一旦作成されてしまえば問題なく再生可能。
動画をタップしてからの再生までの反応はSDと区別がつかない程度。

画像
1ページあたり100KB程度(かなり低画質。拡大には耐えない)に圧縮したZIP自炊コミックも問題なく読める。
連続移動すると引っ掛かりを感じるが、(古い端末なので)SD内でもJPEG展開速度で律速されるのであまり変わらない感じ。
ページあたり1M程度の圧縮前画像を読もうとするとさすがに厳しい。というか展開処理でほぼ固まる。

音声
問題なし。そもほとんど128kbpsだし。


普段使いには十分。いい加減容量がやばくなりつつあったので、SDメモリからあまり見なくなったコンテンツをNASに移動中。
ついでにパーティション空けるのが面倒でやっていなかった、Link2SDを導入。本体のスペースが空いてGoogle日本語入力やデザイアさん紹介のアプリもサクサクとインストール出来るように。

今のところCIFS managerを使っているが、MountManager買うか検討してい見る。
ラベル:android NAS CIFS
posted by ko-zu at 18:50| Comment(0) | TrackBack(0) | Android | このブログの読者になる | 更新情報をチェックする
×

この広告は90日以上新しい記事の投稿がないブログに表示されております。