アカウント名:
パスワード:
int xxx_func(...){ char *str; str = (char *)malloc(sizeof(char) * x); (strに文字が入る処理) printf(str); return ret;}
printf("%s",str);
# I will work seriously this year!
たまたま引数が入るはずのスタックに有効なアドレスが入ってて、 こっそりどこかが書き変わってるって言うことでは…!?
というか, コーディング以前にバグの無い仕様を作るほうが大変じゃないですかね.
# バグ上等な仕様しか書いたことないのでID
-- 不具合の内容としては、au のほうがまずいと思うんだけど…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
よくやっちゃうんだよね (スコア:5, 参考になる)
# printf Injectionとでも言うのだろうか
M-FalconSky (暑いか寒い)
Re:よくやっちゃうんだよね (スコア:5, おもしろおかしい)
# 晒しなのでACなM-FalconSky
Re:よくやっちゃうんだよね (スコア:3, 参考になる)
一般的には、format string bug とか、format string vulnerability とか
呼ばれてます。
"vulnerability" なのは、場合によっちゃ攻撃可能だから。
携帯電話でどうなのかはよくわかりませんが。
参考: http://www.acm.uiuc.edu/sigmil/talks/general_exploitation/format_strings/
Re:よくやっちゃうんだよね (スコア:3, 参考になる)
SH902iのメール件名に「%」が入っていると異常動作 [itmedia.co.jp]を真っ先に思い出しました。
カシオ日立モバイルコミュニケーションズはW42CA・W42Hから
KCP [itmedia.co.jp]に切り替えたようで、
今回のバグはBREW化されたメーラーが臭いですね。
Re:よくやっちゃうんだよね (スコア:2, 参考になる)
%S=%lsで、ふつーの%sがchar*を期待するのに対して、%Sはwchar_t*だ。なんで%sは大丈夫なんだろう。%Sはマイナーだから対策を忘れてたのかな。
%nもあんまり使わないから忘れてたのかな。
Re:よくやっちゃうんだよね (スコア:1)
# ずいぶん昔にCから足を洗った(ということになっている)のでtuneo。
Re:よくやっちゃうんだよね (スコア:1)
例で上げたのは、%系一般で問題を起すだけです。
# やたら+モデもらっちゃって悪い気がする。
あと、最近NetBSDのカーネル周りを見ているんですが、
コンパイル時に引数の数と型をチェックできてるんですよね。
これコンパイラのオプションだろうか。
# フォーマットはstaticな文字列だけ+型チェック+引数の数チェックでだいぶマシ
# でもカーネル内の関数なので使えるフォーマットはとても少い...
# そしてprintf家系は最終的にvsnprintfに到達していました。
M-FalconSky (暑いか寒い)
Re:よくやっちゃうんだよね (スコア:2, すばらしい洞察)
理解したつもりで使わない奴はただの馬鹿
BREWでの文字列の扱い (スコア:2, 興味深い)
http://plusd.itmedia.co.jp/mobile/0311/14/n_bapp.html [itmedia.co.jp]
をみると画面描画文字列はラップされているが、
デバッグ用関数がprintfっぽい。
ということでログ出力用のprintfの不具合くさいかな。
もしデバッグ用ログでリセットなら最悪ですな。まさにミイラ取りがミイラ。
サニタイズ?? (スコア:1, 参考になる)
format string脆弱性はどんな文字列でも発動するわけじゃないんだって。
「%n」はスタックに書き込む機能だから攻撃に使われる。
ちなみに、対策が「%をサニタイズすること」とか
「%をエスケープすること」ってのは大間違いなので
勘違いしないように。
正しくは sprintf(var) を sprintf("%s", var) にすること。
参考:JPCERT/CCの判断力も蝕む サニタイズ脳の恐怖 [takagi-hiromitsu.jp]
W42CA使ってるので実験 (スコア:5, 参考になる)
2.メール宛先に%S入力→問題なし
3.メール本文に%S入力→画面真っ暗に。しばらくしてボタンを押すと初期画面。(起動プロセスなし)
4.%Sを本文に含むメールを受信→メールを読もうとしたら3と同じ症状(一覧までは問題なし)
5.%Sを件名(subject)に含むメール→受信途中で3の症状→センターにメールありの表示→受信しようとしたらメールなしと表示→メール一覧に該当メールあり→メール見ようとしたら本文受信開始(メール自体は普通に見れました)
#送らないでくださいorz
Re:W42CA使ってるので実験 (スコア:4, おもしろおかしい)
って本文を入れてもアウトなんだろうか?
#『みられまくっちゃ』にやられまくっちゃった
Re:W42CA使ってるので実験 (スコア:5, おもしろおかしい)
なんと7割引っすか。
そりゃ急いでメールで知らせまくっちゃ
Re:W42CA使ってるので実験 (スコア:1, おもしろおかしい)
#見切り品LoveなのでAC
Re:W42CA使ってるので実験 (スコア:2, おもしろおかしい)
「凄いナンパ成功率!100%S●Xできちゃいます!」
Re:W42CA使ってるので実験 (スコア:3, おもしろおかしい)
該当ユーザぐらいには (スコア:4, おもしろおかしい)
auは該当ユーザに
「メールタイトル、本文に%S,%nが含まれると端末が再起動してしまう」
と注意を促す「メール」を送ればいいのに。
Re:該当ユーザぐらいには (スコア:4, おもしろおかしい)
♪携帯さんたら読めずに落ちる
♪しかたがないのでお手紙書いた
♪さっきのお手紙再送してね
かくして無限ループ
いやいや (スコア:2, すばらしい洞察)
すごく、回避しづらい嫌がらせだと思うんですが。
>事象が発生する条件が限定的であるため
限定的と言えるんでしょうか??
Re:いやいや (スコア:1, 興味深い)
発表されてしまった今となっては改修するしかない。
この手の脆弱性は公表されてからそれを衝くマルウェアもといマルメール登場までゼロ日です。
URLエンコード (スコア:2, すばらしい洞察)
そのへんはどうなんだろうか
Re:URLエンコード (スコア:3, 参考になる)
http://www.google.co.jp/search?q=%E3%81%94%E3%82%81n
Re:URLエンコード (スコア:5, 参考になる)
>
>http://www.google.co.jp/search?q=%E3%81%94%E3%82%81n
3日前に機種変したばっかりのW42Hで実験してみました。
結果→エラーにならずに正常表示。
ありー?
%nを直接入れたメールなら、あっさり落ちます。
なんか悔しいので更に調べる。
「%81n」→落ちる。
「%82%81n」→落ちる。
「%E3%82%81n」→落ちない!
「%23%82%81n」→落ちた!!
どうやら、最初の%からnまでの間に数字や%以外が入るとキャンセルされるようです。
というわけで、真打ち登場。コレで落ちました。
Shift_JISで「ゴメn」と入力
http://www.google.co.jp/search?ie=Shift_JIS&q=%83%53%83%81n
Re:URLエンコード (スコア:4, おもしろおかしい)
カシオ日立に感謝しても悪くない(かも
Re:URLエンコード (スコア:1)
たまたま引数が入るはずのスタックに有効なアドレスが入ってて、
こっそりどこかが書き変わってるって言うことでは…!?
Re:URLエンコード (スコア:1)
Sもnも含まれて居ませんが…
Re:URLエンコード (スコア:1, 参考になる)
Re:URLエンコード (スコア:1)
そりゃ大変だ。
C言語書けばという奴に限ってC言語はできない法則 (スコア:2, 興味深い)
いや自分自身「○○のサブセット」よくやるんで。
でもフルセットのprintf()バグなしで書けといわれて書ける人間なんてぶっちゃけなかなかいないぞ。
+=======------
| K.Hamaura a.k.a. SeyfertSluw
| 「SFはどこまで実現するか」 復刊希望は→http://www.fukkan.com/vote.php3?no=4901
Re:C言語書けばという奴に限ってC言語はできない法則 (スコア:1)
というか, コーディング以前にバグの無い仕様を作るほうが大変じゃないですかね.
# バグ上等な仕様しか書いたことないのでID
Re:C言語書けばという奴に限ってC言語はできない法則 (スコア:1)
# 当たり前だ。
メール受信時にも発生ってことは (スコア:1, すばらしい洞察)
# それでも修正しないんですか?
Re:メール受信時にも発生ってことは (スコア:2, すばらしい洞察)
最近だと、学校やプロバイダのアドレスに来たメールも携帯電話のアドレスに転送してる人もいますしねぇ…。
対策 (スコア:1, すばらしい洞察)
Re:対策 (スコア:5, 参考になる)
%%S (%%n)と入力すると正しく動作します(笑)
#その後%を1文字削るとちゃんと再起動(笑)
Re:対策 (スコア:1)
それでいいのか? (スコア:1)
--
不具合の内容としては、au のほうがまずいと思うんだけど…。
Re:それでいいのか? (スコア:1)
もっとも、告知しただけましな気がします。「告知はしない、ユーザが希望する場合は預り修理」と言い切ってしまう au よりは。
Re:それでいいのか? (スコア:2, 興味深い)
比較対照としてはどうかと思いますが、
今回は、相手から送られたメールの題名でも引っかかるので
運用法で回避しにくいと言う問題がある分痛いですね。
流石にメールを使わないわけにも行かないし、
Cメール転送でタイトル抜いて受信でも文字数制限が…
あと、auのこういった場合の対処ですが、たまに微妙ですね。
以前のA5403CAカメラ&電源問題の時も私が知る限りそう言った告知はなく、
店頭に持っていっても通知が来てないとかで、店員がどこかに問い合わせて
やっとファームアップできるようになりましたからねぇ。
正直、最近のサポセンのふざけた対応やサービスの方針を見ていると
乗り換えたくなってきた今日この頃です。
#以前は良かったのになぁ…
#状況はいつも最悪、でもそれが当たり前
Re:それでいいのか? (スコア:1)
> ただのau嫌いなだけではないの?
んー、au 信者は嫌いですね。
# au は別に嫌いじゃないけど KDDI は嫌い。
ケータイアップデート (スコア:1)
W3xあたりからこの機能はあったと思うのですが、どうしてこういう時に使わないんでしょう。
もしかしてケータイアップデートはSA限定?
-- やさいはけんこうにいちば〜ん!
Re:ケータイアップデート (スコア:1)
事情は変わっていると思うので想像ですが、ユーザがアップデートして、ちゃんと起動できない可能性があるものは修理扱いなのかなと思いました。
違う文字を使おう (スコア:1)
url送付する前に全部変換をかければOKだ。
#面倒だけれども。
Re:部門名 (スコア:3, おもしろおかしい)
そりゃユニークな発想だ
メールサーバー内で対処 (スコア:1)
メールフィルターサーバー増設で凌いでいるけど、端末側が不具合では困りますよね。
Super Souya
よくある「余計なもの」 (スコア:1)
Re:ぐはっ (スコア:1, 参考になる)
以前オンラインアップデートしたらそのまま電源が落ちて、結局預かり修理になっちゃいましたが・・・。
Suica再発行でもめたのでAC
Re:OSと噛んでる? (スコア:3, 参考になる)
BREWにバグがあったんならともかく。
この2機種に関しては他の方のコメントにもあるとおりKCPが導入されていますが
各社見た目が異なることからも判るとおり、すべて共通化されてるわけではありません。
独自部分に関してはネイティブの部分もあります。
ちなみにauの携帯はほぼ全てQualcommのREX OSを使用しています。
(上記コメントのKCP記事辺りでも触れていますが)
で「再起動してしまう」ということですが、これは避けられなかったのではなく
ある程度以上の問題が発生した場合は、「自動的に再起動するようにしてある」のが真相です。
ファームの全更新はショップで可能ですし、一部ならケータイアップデートで可能です。
ハードのリソースが厳しいかはともかく、開発期間は短いですし、某所の開発はタコですが
影響範囲は別として、バグの要因としては極普通レベルだと思います。
#これ以上は「業務上知りえた秘密」になるのでAC
Re:OSと噛んでる? (スコア:2, 興味深い)
Au携帯の開発実務には関わったことが無いので勉強になりましたm(__)m
>この2機種に関しては他の方のコメントにもあるとおりKCPが導入されていますが各社見た目が異なることからも判るとおり、すべて共通化されてるわけではありません。
>独自部分に関してはネイティブの部分もあります。
>ちなみにauの携帯はほぼ全てQualcommのREX OSを使用しています。
>(上記コメントのKCP記事辺りでも触れていますが)
参考になります…
ついでに質問で恐縮ですが、
>で「再起動してしまう」ということですが、これは避けられなかったのではなくある程度以上の問題が発生した場合は、「自動的に再起動するようにしてある」のが真相です。
…と言うことは、今回の現象はOS自体が飛んだのでは無く、当該タスクがリソース(CPU時間)を占有してしまって(もしくはMPUを「想定外の条件下で落として」しまって)ウォッチドッグが動作してリブートするという流れだと考えれば良いのでしょうか?
>ハードのリソースが厳しいかはともかく、開発期間は短いですし、某所の開発はタコですが影響範囲は別として、バグの要因としては極普通レベルだと思います。
この部分については確かに仰る通り(下手すればソースコードのtypoやロジック設計の条件不足と言う単純なレベルでも起こりうる不具合現象)だと思うんですが、Auだかカシオ・日立だかの後始末対応が拙すぎるという感じがどうしても拭えないです…単純なミスだから逆にきちんと対策しないと拙いような。
# まぁ、開発が外注で契約関係でこういう対処になってしまってるのかもしれませんが
# …まぁ、そこは問いますまい。でも、商品の品質管理の視点から見ると腑に落ちない。
Re:OSと噛んでる? (スコア:3, 参考になる)
大体それであってると思います。
多分今回の場合は不正参照関連の方ではないかとは思いますが。
私の知る限りでは携帯関連は大体こういった実装をしています。
>この部分については確かに仰る通り(下手すればソースコードのtypoやロジック設計の条件不足と言う単純なレベルでも起こりうる不具合現象)だと思うんですが、Auだかカシオ・日立だかの後始末対応が拙すぎるという感じがどうしても拭えないです…単純なミスだから逆にきちんと対策しないと拙いような。
どう対応するかは開発側ですがOKだしたのはauのはずです。
恐らくは、ケータイアップデートが出来ない=預かり修理になる=コストかさむ
に対して、文としてレアケースと判断した。ってことでしょうが
受信メールの表示で落ちるのでメールボム化すると厄介ですね。
#ちなみにファームとしては既に修正対応してあるはずです。
#問題は回収対応するだけのコストを出せるかの問題。
ただ恥ずかしい話、こういったケースは珍しくないので
ユーザーにわかる形で発表されたのはまだ評価できると思います。
下手すると問い合わせをしてもわからない場合が往々にしてありますので。