Android向けSkypeに個人情報流出の脆弱性
mamoru info
mamoru info
From: mamoru info <info....@gmail.com>
日付: 2011年4月20日8:01
件名: Android向けSkypeに個人情報流出の脆弱性
To: android-sec...@googlegroups.com
丹羽直也(MineStudio)
詳しくいじろうと思ったら、先に修正アップデートきたので、諦めてアップデートしちゃいました(^_^;)
たしかに、最初に暗号化してなかったという問題はほめられることではないですが、ちゃんと発覚して、すぐに修正したというのは、まもるさんが言うようにかっこいいですね。
たまに仕様だと言いはる会社がありますが、アレはセキュリティ的に当然望ましいことじゃないですし、かっこわるいです。
又、審査がないAndroid Marketだからこそ、このような迅速な対応ができた、と私は考えています。
審査が果たして吉と出るか凶と出るか、そういう議論で重要な事例だと思います。
--
このメールは「Android セキュリティ部」のメンバーに送られています
Android セキュリティ部 サイト http://android-security-japan.mns.me
このグループにメールで投稿: android-sec...@googlegroups.com
当グループのページ http://groups.google.com/group/android-security-japan?hl=ja?hl=ja
--
Android セキュリティ部(Android Security Japan)
丹羽 直也
Twitter : @mine_studio
Site: http://www.mine-studio.com/
Blog: http://blog.mine-studio.com/
Masakazu Hattori
なるほど、審査がないから脆弱性修正版もすぐにマーケットで公開できる面もありますね。
2011/04/21 22:40 "丹羽直也(MineStudio)" <naclub...@gmail.com>:
部長の丹羽です。
詳しくいじろうと思ったら、先に修正アップデートきたので、諦めてアップデートしちゃいました(^_^;)
たしかに、最初に暗号化してなかったという問題はほめられることではないですが、ちゃんと発覚して、すぐに修正したというのは、まもるさんが言うようにかっこいいですね。
たまに仕様だと言いはる会社がありますが、アレはセキュリティ的に当然望ましいことじゃないですし、かっこわるいです。
又、審査がないAndroid Marketだからこそ、このような迅速な対応ができた、と私は考えています。
審査が果たして吉と出るか凶と出るか、そういう議論で重要な事例だと思います。
2011年4月21日11:35 mamoru info <info....@gmail.com>:
>
> まもるです。
>
> 続報です。Skypeさん、対応＆声明が早かったですね。
> 自分は、こういうことがアプリ開発者の「責任」の１例と思います。
> むしろ、「責任」を明確に果たされれば...
--
Android セキュリティ部(Android Security Japan)
丹羽 直也
Twitter : @mine_studio
Site: http://www.mine-studio.com/
Blog: http://blog.mine-studio.com/
--
このメールは「Android セキュリティ部」のメンバーに送られています
Android セキュリティ部 サイト http://android-security-japan.mns.me
...
mamoru info
kaito
こんにちは、かいとです。
遅レスではありますが、この脆弱性が気になったので調べてみました。
> せっかくなので、iPhoneでは暗号化されていますが、Androidは根本的に、暗号化されていないという。。。
> 専門家からみたら、OSの完璧な脆弱性ですね。。。
今回公表された Skype の脆弱性のキモは、ファイルシステムのパーミッション
の不備にあると、僕は考えます。具体的には、以下のようなファイルの other
権限で、rw が許可されていたことが脆弱性の原因だと考えます。
/data/data/com.skype.raider/files/<Skype ID>/main.db
/data/data/com.skype.raider/files/shared.xml
この脆弱性関連の情報を読んでいて気になったのは、
「/data/data/<アプリ名>/ 以下に、なんでそんなファイルができたのか」
という点です。Android API を介してファイルを生成していた場合、こういった
ファイルができないと僕は理解していたからです。
僕のできる範囲で、脆弱性の影響を受ける Android 版 Skype(com.skype.raider)
1.0.0.831 を調べてみました(*)。結局、該当ファイルをどのコードが生成しているか
わからなかったのですが、JNI 経由で呼び出すネイティブコード libpcmhost.so が
脆弱性の原因を作ったのでは？という推測に至りました。
ネイティブコード部分に原因があったとすると、au 向けSkype や Verizon 向け
Skype に影響がなかった点も説明がつくかなと思いますした。
# 説得力が弱いですが(--;
http://blogs.skype.com/ja/2011/04/19/skype_android_privacy_vulnerability.html
> ※注意： au携帯用Skypeをご使用のユーザーは、情報流出における脆弱性の影響はございません。
http://www.sophos.co.jp/pressoffice/news/articles/2011/04/skype-for-android-leaks-sensitive-data.html
> Case 氏は、(略)Skype for Android の現在の製品 (Verizon 版を除く) でも同じ設定になっていました。
とはいえ、僕自身が Android アプリなどを開発する立場ではないため、ネイティブ
コードの実装でこういったファイルが生成され得るか分かりません。
【可能性】として読んでいただき、「実際にそういったファイルできる！」とか、
「いやいや、それ間違っている」などあったら、教えていただけると幸いです。
(*) 以下のような調査を実施しました。
(1) Skype の classes.dex をデコンパイルして、Java コードを生成。
Java コード内で「shared.xml」や「main.db」を検索。
該当なし。
(2) Skype のリソースファイル（各種 xml）のテキストファイルを生成。
それらのテキストファイル内で「shared.xml」や「main.db」を検索。
該当なし。
(3) libpcmhost.so を逆アセンブリし、「shared.xml」や「main.db」を検索。
該当なし。
※デバッガの使い方に不慣れなため、(3) の確認に少し自信がない（ｘ
2011年4月20日8:01 mamoru info <info....@gmail.com>:
> --
> このメールは「Android セキュリティ部」のメンバーに送られています
> Android セキュリティ部 サイト http://android-security-japan.mns.me
> このグループにメールで投稿: android-sec...@googlegroups.com
> 当グループのページ http://groups.google.com/group/android-security-japan?hl=ja?hl=ja
>
--
kaito<kait...@gmail.com>
Blog: http://d.hatena.ne.jp/kaito834/
Twitter: http://twitter.com/kaito834/
サーバ管理者の戯言
ちょっとだけ調査してみました。
Javaプログラム単独では出来ないかと思いますので、JNIで調査しました。
１．fopenを利用する場合
２．openを利用する場合
１．のfopenを利用した場合は、過去に私は利用していますがパーミッション指定が無いためJavaと同等になります。
２．のopenを利用する場合は、fopenよりも低レベルな関数です。パーミッション指定が可能で/data/data/～にファイルを
吐き出してみました。
想定通り666で作成することが出来ました。
恥ずかしいのですがテストJNIソースを添付します。
#include <stdio.h>
#include <fcntl.h>
#include <jni.h>
#include <android/log.h>
#define DEBUG 1
#if DEBUG
# define DebugLogInfo(...)
((void)__android_log_print(ANDROID_LOG_INFO, "TestOpen", __VA_ARGS__))
#else
# define DebugLogInfo(...) do{}while(0)
#endif
JNIEXPORT jint JNICALL Java_jp_co_anaheim_1eng_MainActivity_testOpen
(JNIEnv *env, jobject thiz)
{
int fd;
fd = open("/data/data/jp.co.anaheim_eng/testfile1.txt", O_CREAT | O_RDWR);
if (fd == -1) {
DebugLogInfo("testfile1.txt File cannot open error.");
return 1;
}
close(fd);
fd = open("/data/data/jp.co.anaheim_eng/testfile2.txt", O_CREAT |
O_RDWR, 0666);
if (fd == -1) {
DebugLogInfo("testfile2.txt File cannot open error.");
return 1;
}
close(fd);
return 0;
}
2011年4月30日14:01 kaito <kait...@gmail.com>:
サーバ管理者の戯言
fopenも同様に実験すれば良かったですね。すみませんでした。（/dataに書きだしたことが無かったもので・・・滝汗）
結論から言うと、JNIでfopenを無意識に使うケースとopenを意識してパーミッションを与えるケースが666になります。(^^;
ということで、JNIを利用してファイルを作成する場合には注意しましょうってことですね。
最終確認ソースを添付します。
＝＝＝Java側
package jp.co.anaheim_eng;
import jp.co.anaheim_eng.R;
import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;
public class MainActivity extends Activity {
static {
// ライブラリロード
System.loadLibrary("TestOpen");
}
public native int testOpen();
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
TextView tv = (TextView) findViewById(R.id.textView1);
int rtncd = testOpen();
if (rtncd != 0) {
tv.setText("false");
} else {
tv.setText("sucess");
}
}
}
＝＝＝JNI側
#include <stdio.h>
#include <string.h>
#include <fcntl.h>
#include <jni.h>
#include <android/log.h>
#define DEBUG 1
#if DEBUG
# define DebugLogInfo(...)
((void)__android_log_print(ANDROID_LOG_INFO, "TestOpen", __VA_ARGS__))
#else
# define DebugLogInfo(...) do{}while(0)
#endif
JNIEXPORT jint JNICALL Java_jp_co_anaheim_1eng_MainActivity_testOpen
(JNIEnv *env, jobject thiz)
{
FILE *fp;
fp = fopen( "/data/data/jp.co.anaheim_eng/testfile0.txt", "w+" );
if( fp == NULL ) {
DebugLogInfo("File cannot open error.");
return 1;
}
fclose(fp);
サーバ管理者の戯言
JNI側でfopen等のファイル生成を行うとパーミッションが666になるっぽい記述を行いましたが、解決方法が
あまりよろしくないですね。パーミッションを付与すれば良いのですが、JNIサンプルを掲載します。
#include <sys/stat.h>
if (chmod("/data/data/jp.co.anaheim_eng/testfile0.txt", S_IRUSR |
S_IWUSR | S_IRGRP | S_IWGRP) != 0) {
DebugLogInfo("File cannot change chmod.");
return 1;
}
こんな感じで、660としてパーミッションの実行しました。問題無く動作しています。
昨日のサンプルにfopen生成直後に上記ソースを付与した際の実行結果を添付します。
＃open関数部分は無変更です。
丹羽直也(MineStudio)
調査、ありがとうございます。
fopenは内部でopenをDEFFILEMODEというモードで呼び出していますね。
http://android.git.kernel.org/?p=platform/bionic.git;a=blob_plain;f=libc/stdio/fopen.c;hb=HEAD
このDEFFILEMODEというのはlocal.hで
#define DEFFILEMODE (S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH)
と定義されていて、まさに666となっています。
これが問題になっているのではと思ったりするのですが・・・・
GCCのfopenのソースをご存知の方はいますか？
2011年5月4日10:28 サーバ管理者の戯言 <ley....@gmail.com>:
> --
> このメールは「Android セキュリティ部」のメンバーに送られています
> Android セキュリティ部 サイト http://android-security-japan.mns.me
> このグループにメールで投稿: android-sec...@googlegroups.com
> 当グループのページ http://groups.google.com/group/android-security-japan?hl=ja?hl=ja
>
--
サーバ管理者の戯言
Ubuntu 10.10では644になっています。gccソースまでは調べていませんが。(^^;
取り敢えずまで。
mamoru info
服部です。
Ubuntu 10.10では644になっています。gccソースまでは調べていませんが。(^^;
取り敢えずまで。
--
サーバ管理者の戯言
私も過去の人に該当するのですが、OS側やフレームワーク側に依存して開発者は何も考えないというのは
良くないと思います。
＃フレームワークやOSの仕様変更、機種間等でパーミッションが担保できない可能性があるシステムは問題
＃と思います。
特にAndroidの場合には、GCや操作途中でのアプリ強制終了等も想定しなければならないと思いますし。
kaito
こんばんは、かいとです。
> 結論から言うと、JNIでfopenを無意識に使うケースとopenを意識してパーミッションを与えるケースが666になります。(^^;
興味深い実証結果、ありがとうございます。libpcmhost.so が
脆弱性の原因となっている可能性が高そうですね。JNI で
ロードするネイティブコードが多いのであれば、同じ問題を
抱える Android アプリが他にもあり得るのでは？という疑問が
沸きました。