FC2ブログ

鈴の音情報局blog

携帯関連の将来や最新の技術情報や業界の行く末などを適当に綴るblogです。 内容の信憑性は?余り信じない方がいいと思います。
本家の鈴の音情報局はこちら→http://suzunone.0g0.jp:8800/
スマホ・携帯端末アクセス[ランキング][アクセスシェア(グラフ)] (毎年10/1にログをクリア)

【大バグ・深刻】iPhone/MacOSXにセキュリティーに大穴、SSL証明書が偽物でも「正しい」と判断し盗聴し放題、それを大したことないとこっそりとiOSを修正してダンマリ、OSXはまだ未修整

アップルがやらかした、これは酷すぎる。
先日の7.0.6のアップデートの詳細が分かったので記事にする。

途中プログラムコードとか出てくるので、分からないと思ったらそこは読み飛ばし、
画像とか下の方を読んで下さい。
Apple史上最悪のセキュリティバグか、iOSとOS XのSSL接続に危険すぎる脆弱性が発覚──原因はタイプミス? ~ Appllio
Appleは21日、iOSのソフトウェアアップデート7.0.6をリリースした。
iOS 7.1が早ければ3月中旬にもリリースされるとみられていたが、SSL接続の検証に関して、半月以上も待つことができない重大なバグが見つかったためだ。
【Apple史上最悪のセキュリティバグか】
SSLとは、「ウェブサイトで入力する個人情報やクレジットカード情報などを暗号化し、安全に送受信する技術」(Symantec)だ。データを安全にやりとりするために利用されている非常に重要な技術となっている。
そして今回、クライアント(ユーザ側)とサーバ(ウェブサイト側)の間をSSL接続する際のプログラムに、「BASIC初心者でも一目で分かるようなミス」(Wired)が見つかり、修正されることになったようだ。

アップル「iOS」に深刻なバグ iPhoneからカードなど個人情報盗まれる恐れ ~ J-Castニュース
米アップルの「アイフォーン(iPhone)」「アイパッド(iPad)」に搭載されている基本ソフト「iOS」に、深刻なバグが見つかった。
対策を施さず放置したままだと、悪意のある第三者の侵入を受けてクレジットカード番号などの重要な個人情報を盗まれる恐れがある。

アップル iOS 7.0.6提供開始、SSLの脆弱性を修正。OS X にも同じバグ発覚 ~ engadget
アップルが iOS のアップデート 7.0.6 をリリースしました。中身は「SSL接続時の検証に関する問題」の修正。iPhone 4以降, iPad 2以降, iPod touch (第5世代)それぞれに適用されます。また iOS 7に対応しない iPhone 3GS, iPod touch (第4世代) には、同じバグ修正内容の iOS 6.1.6 がリリースされています。
また複数のセキュリティ研究者によると、このSSL接続時のバグは最新版 OS X 10.9.1 にも存在しており、アップルがパッチを提供するまでは、中間者攻撃を避けるため信頼できないネットワークには接続しないことが望ましいとされています。

金曜日にAppleはiOS 7の深刻重大なバグを修復 ~ TechCrunch
昨日(米国時間2/21)Appleは、iOS 7のセキュリティ関連のバグを直したと発表した。
今日(米国時間2/22)になってWebのセキュリティの専門家たちが、パッチを解析してバグの正体を突き止めた。
それはどうやら、相当深刻なバグのようだ。
Wired誌に、そのおそろしい詳細が載っている:
“Appleの昨日の発表があまりに簡潔なので、インターネットの暗号に関する高名な専門家たちは、そのバグの性質について訝(いぶか)った。バグの詳細を非公開で調べ始めた彼らは、いろいろ分かってくるにつれて、仰天のあまり沈黙してしまった。ジョンズホプキンズ大学の暗号学の教授Matthew GreenはTwitterのツイートで、‘Appleのバグの正体が分かった。相当ひどいバグだ’、と述べた”。

Major Apple security flaw: Patch issued, users open to MITM attacks ~ ZD Net
Apple on Friday revealed a major SSL (Secure Socket Layer) vulnerability in its software that affects all devices, allowing hackers to intercept and alter communications such as email and login credentials for countless Apple hardware users.
A new version of Apple's iOS for its tablets and phones was rushed out the door Friday to patch the vulnerability, wherein its mobile, tablet and desktop software is not doing SSL/TLS hostname checking — communications meant to be encrypted, are not.
The patch has only been issued for the more recent iPhones (4 and later), iPod touch (5th generation) and iPad (2nd generation).
Google翻訳:
Appleは金曜日に、ハッカーが傍受して変更した通信を、電子メールなど、無数のAppleハードウェアのユーザーの資格情報をログインすることができ、主要なSSLのすべてのデバイスに影響を与え、そのソフトウェア(セキュアソケットレイヤー)の脆弱性を明らかにした。
暗号化されることを意図した通信は、ありません - そのタブレットと携帯電話用のAppleのiOSの新バージョンは、モバイル、タブレット、デスクトップソフトウェアは、SSL / TLSのホスト名のチェックをしていない、請求脆弱性を、パッチを適用する金曜日のドアを飛び出した。
パッチが唯一の最近のiPhoneの(4以降)のために発行された、iPod touchの(第5世代)およびiPad(第2世代)。

Security researchers across several communities believe that Mac computers are even more exposed, as they are currently left hanging without a patch.
Unfortunately, Apple has not released a statement on when to expect this patch, nor what version range of iPhone, iPad, iPod touch, or Mac computer is affected by the major, and somewhat shocking, flaw.
Google翻訳:
いくつかの地域社会全体のセキュリティ研究者は、彼らが現在、パッチなしでぶら下がって残っているようにMacコンピュータは、さらに多くの露出していると信じています。
残念ながら、Appleはこのパッチを期待するときに声明を発表していない、またどのバージョンiPhone、アプリ、iPod touchの、またはMacの範囲のコンピュータは、主要な、やや衝撃的な、欠陥の影響を受けます。

要約を書くと、iOS7.0.6で慌てて修正されたのは「SSLの証明書の正当性が
正しくチェックされていなかった」という事です。

そしてそれがiOS7だけの問題ではなくiOS6も、更にはMacOSXにも同様の
セキュリティーホールを抱えていたという事です。

アップルはもうサポートしないはずのiOS6でもiOS6.1.6をリリースしている
辺り、その深刻性が伺える。これで3GS迄は塞ぐことが出来た。
iPhone 3GとiPhone初代は諦めてもらうしかない。

本国でも酷いという事が分かるツイートがされています。




このようにまあ酷いものです。

とりあえずブツの確認だけしておきましょうか。
sslKeyExchange.c ~ Apple
static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
uint8_t *signature, UInt16 signatureLen)
{
OSStatus err;
SSLBuffer hashOut, hashCtx, clientRandom, serverRandom;
uint8_t hashes[SSL_SHA1_DIGEST_LEN + SSL_MD5_DIGEST_LEN];
SSLBuffer signedHashes;
uint8_t *dataToSign;
size_t dataToSignLen;

signedHashes.data = 0;
hashCtx.data = 0;

clientRandom.data = ctx->clientRandom;
clientRandom.length = SSL_CLIENT_SRVR_RAND_SIZE;
serverRandom.data = ctx->serverRandom;
serverRandom.length = SSL_CLIENT_SRVR_RAND_SIZE;


if(isRsa) {
/* skip this if signing with DSA */
dataToSign = hashes;
dataToSignLen = SSL_SHA1_DIGEST_LEN + SSL_MD5_DIGEST_LEN;
hashOut.data = hashes;
hashOut.length = SSL_MD5_DIGEST_LEN;

if ((err = ReadyHash(&SSLHashMD5, &hashCtx)) != 0)
goto fail;
if ((err = SSLHashMD5.update(&hashCtx, &clientRandom)) != 0)
goto fail;
if ((err = SSLHashMD5.update(&hashCtx, &serverRandom)) != 0)
goto fail;
if ((err = SSLHashMD5.update(&hashCtx, &signedParams)) != 0)
goto fail;
if ((err = SSLHashMD5.final(&hashCtx, &hashOut)) != 0)
goto fail;
}
else {
/* DSA, ECDSA - just use the SHA1 hash */
dataToSign = &hashes[SSL_MD5_DIGEST_LEN];
dataToSignLen = SSL_SHA1_DIGEST_LEN;
}

hashOut.data = hashes + SSL_MD5_DIGEST_LEN;
hashOut.length = SSL_SHA1_DIGEST_LEN;
if ((err = SSLFreeBuffer(&hashCtx)) != 0)
goto fail;

if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)       
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)  
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)  
goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;   ←{}無しで記述しているのでif文の効力はここまでしかない
goto fail;   ←ここで証明書を必ずOKにしてしまう(以下の行は実行されない)

if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)     
goto fail;    何が何でも絶対実行されない

err = sslRawVerify(ctx,
ctx->peerPubKey,
dataToSign, /* plaintext */
dataToSignLen, /* plaintext length */
signature,
signatureLen);
if(err) {
sslErrorLog("SSLDecodeSignedServerKeyExchange: sslRawVerify "
"returned %d\n", (int)err);
goto fail;
}


fail:
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;

}

つまり、④の所の一つ目のgoto fail;だけif文の影響下に有るのですが、
二つ目は平文のgoto fail;という解釈になります。
なので二つ目のgoto fail;以降は絶対に実行されない行となります。

二つ目のgoto fail;で飛んだ先では「この証明書は正しいですよ」という
判断を下した結果を返してしまっています。

つまりSSLの証明書がどんな嘘んこのものでも「正しいですよ~」と返して
しまうバグだったのです。

そうなると、MacOSX 10.9/10.8.5とiOS6/7を使っていると、インターネット上の
秘密通信の根底を支えていると言っていいSSLが全く信用の無い状態になっていた
という事になります。

SSLはどういう場所で使われているかというと、銀行の預貯金などを扱う
ネットバンキング、実名や収書電話番号その他、個人情報を扱う各種サイトの
登録やアクセス、最近では特に盛んなアマゾンや楽天、ドコモのdマーケットも勿論。

インターネットで秘密通信したい事はほぼ全部がそのSSLの証明書を信用して
動いていると思って構いません。

それがMacOSX 10.9/10.8.5とiOS6/7では嘘の間違っている成りすまし証明書でも
全然OKって事になります。

そう言えば孫正義氏がナンバーワンiPhoneキャリアを名乗っていたソフトバンクって
何かカード決済やっていましたよね。

アレだけiPhoneを我が物顔で自慢しておきながら何か声名出さないのですか~~~??


それはいいとして、とりあえず簡単にできる事だけ検証しておきました。
判定サイトに(https://gotofail.com/)アクセスした結果です。
今回の危険性が有るかどうかを判定してくれます。

iOS 6.1.3(iPhone 4)
Safari
iOS 6.1.3(iPhone 4)
Chrome 33.0.1750.14
Android 4.1.2(Xperia GX)
Chrome 32.0.1700.99/Blink 537.36
Android 4.4.2(Nexus 7)
Chrome 32.0.1700.99/Blink 537.36

結果はiOS6.1.3はChromeはワーニング、Safariは完全にアウト。
Androidは4.1.2JerryBeanも4.4.2KitKatもセーフ。
さすがにAndroidで今時SSL証明書如きでバグは残ってないと思いますので当たり前ですね。
勿論この記事を書いているWindows 7+Chromeでもセーフでした。



そう言えば問題の場所って、goto fail;を多用していますよね。
あれ普通に考えて30年前ぐらいにBASICマガジンに乗っていたようなレベルのソースですよ。
64bitなiOS7!!!!とか言いながら、それを操っているソースコードの品質がベーマガ
レベルとは・・・iPhone恐るべし。

大抵ミスは人が犯すと言いますが、まあその通りでした。
昔ダムの制御プログラムのif文の後ろの「;」を忘れただけで村が一つ沈んだとか、
本当か嘘か分からない話とか有りました。その類ですかね。

とにかくアップルのコードの品質がこれでよく分かりました。
少なくともこんなおもちゃレベルのコードで組まれている物等ビジネス使用には堪えません。

iPhone/iOSのセキュリティー性が高い?
バカな事を言うな。

goto fail;
goto fail;

で嘘の証明書を全部有効にしておきながら言えた言葉じゃない。
だだ漏れもいい所じゃないか。
しかも秘密にしたいものに限って嘘の証明でもいいという・・・。


ちなみに一例ですが、こんな感じで書いてgotoを排除していれば、
問題なかったのではないでしょうかね。
偉そうに例を挙げておいてもしバグっていたら申し訳ない。
あくまでこんな風に書けばどう?っていう雰囲気だけ感じとってください。

if ((err = SSLFreeBuffer(&hashCtx)) == 0){
if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) == 0){
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) == 0){
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) == 0){
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) == 0){
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) == 0){

err = sslRawVerify(ctx,
ctx->peerPubKey,
dataToSign, /* plaintext */
dataToSignLen, /* plaintext length */
signature,
signatureLen);
if(err) {
sslErrorLog("SSLDecodeSignedServerKeyExchange: sslRawVerify "
"returned %d\n", (int)err);}

}
}
}
}
}
}
SSLFreeBuffer(&signedHashes);
SSLFreeBuffer(&hashCtx);
return err;

}

これが正常に動作したとして、特に速度も変わらないだろうし、何の問題もないでしょう。




このセキュリティーホールはiOS 6.1とOSX 10.8.5迄有ると書かれていますが、
そもそも「そこまでは最低ある」という意味で、「それ以前が安全」と保障
されているわけではないことに注意が必要です。誰も確認して公表していませんから。

そもそも違うiOSとMacOSとコードになっているはずのOSに共通の「タイプミス」が
有る事がプログラムを書いていた人間からすると不自然なわけで、論理ミスではなく
同じ行が二行とか別々に組んでいたら考えられないのです。


最悪の可能性を導き出すと、iOSは元々MacOSXのソースコードからフォーク(分岐)
して派生したものです。MacOSXをコピーしてそれを書き替えてiOSを作ったわけですね。

そうなると、同じタイプミスのgoto fail;がそのソースを分岐した時には既に
入っていた可能性が考えられます。というか、同じタイプミスが混入する可能性は
ソースコードのコピー時に生まれると考えるのが一番自然です。


という事は・・・?

今回iPhone 3GS迄の修正を行いましたが、それどころではなく、iOSの初代から
ずっとこのバグが入っており、iPhone/iPad/iPod touch/の全てのiOSデバイス、
そしてそれとソースコードの分岐を行った時期以降の全てのMacOSXにこのバグが
入っている事になります。

初代iPhoneっていつでしたっけ?
ソースコードのフォーク後にSSLの証明書関係を書き替えた時に混入したバグである
可能性も有りますが、ああいう比較的上層はそう頻繁に書き換える所ではなく、
これより下層を書き換える事の方が多いのではないかなと思います。
SSL周りが大きく変わらない限りは。まあセキュリティー関連は門外漢なので
詳しい事は知らないので間違っているかも知れませんけど。
少なくとも私はそう頻繁には書き換えるものでもない場所だという認識です。
だから長らく見過ごされていても当然と言えば当然だったのです。

が、こういったバグには対抗手段も有りまして、静的なソースコードを検査する
ツールが有りまして、二つのgoto fail;の後の絶対に実行されない部分などを
簡単に検出してくれます。また、こういったベーマガクラスのソースコードは
今時どころか、20年以上前のコンパイラですらワーニングが大量に出ていたと
思われます。無視してたんでしょうかね?


とりあえず古いiOSやMacOSXをまだお持ちの方は判定サイト(https://gotofail.com/)にアクセスしてテストしてみてください。
その結果の画像等をコメ欄に張って頂けたら嬉しいです。
どこまでこのセキュリティーホールが遡るのか、私の最悪のシナリオが真実と
なった場合、アップルはどういった行動をとるのか。

私からすれば今回のアップデートは最大警告を持ってリリースすべきだったと思います。
マイクロソフトはそうやっていますし、ドコモやKDDIもAndroidに何かあったらそう
アナウンスしています。(ソフトバンクは知らないというか見た事無い)

しかしアップルは上記記事に記して有るように、
Appleの昨日の発表があまりに簡潔なので、インターネットの暗号に関する高名な
専門家たちは、そのバグの性質について訝(いぶか)った。
こんなレベルの公開の仕方しかしていません。


私は先日このアップデートの公開は端末が燃えたから火消しのタイミングを狙ったの
ではないかと書きましたが、とんでもない。それも有ったのかも知れませんが、
それどころの話じゃない。アップルの社を揺るがすレベルの大バグなので、
どう火消をしようと考えた結果、MWC2014の直前に出したのではないかと考えました。

iOS7.1のイメージは汚したくないからiOS7.0のうちに汚れは被ってもらい、
MWCの勢いで火消しを図った。タイミング的に見てこんな所じゃないかなと考えています。

結局中国の感電死の件とか全力を挙げて調査するとか言って何のリリースも
出しませんしね。爆発しても燃えても、人が死んでも絶対自らは公表しない。
マイナスになる事はこっそり隠す、そういう企業です。
まるでソフトバンクですね。

【当時の当ブログ記事】
タイでまたiPhoneによる感電死、今回はアップルによる殺人行為
中国でiPhone感電が二人目に、一人目の充電器は正規品に見えるのですけど


私は過去のiOS、MacOSXまで全て調査し、調査結果をマトリクス状の表で公表し、
まだ修正されてないとされるiOSとMacOSXの機器ではSSLを利用するようなアクセスは
控え、バージョンアップが出たらすぐに適用する事べきだという事を強く強く
アップルが告知を行うべきだと思います。

現状、セキュリティーに詳しい方達のアンダーグラウンドな解析によってのみ
分かった事でしかありません。本来はアップルがすべきことなのに。

これではアップルは社会的な責任を果たしているとは言えません。
もっと日本のPCやモバイルのメディアも騒ぐべきです。
ジャーナリストの方、全力で記事を書く時だと思いますよ。
この危険度をより多くのアップル製品ユーザーに告知してください。


それとドコモ、KDDI、ソフトバンクも端末を売っている責任上、確認して一日も
早く何らかのリリースをしてください。キャリアはアップルに直で確認できると
思うので、宜しくお願いします。
関連記事
  1. 2014/02/25(火) 19:48:35|
  2. 携帯
  3. | トラックバック:0
  4. | コメント:16
<<Nexus8の発売予測で見えるGoogleの動き | ホーム | MWCで存在感を示そうとするFirefox OS、まだ間に合うかも知れないが、展開が遅すぎる>>

コメント

システム開発者ではないのですが多少プログラムはわかる自分からしてもちょっと考えられないというか、コピペしまくってたらこうなったという私のような素人プログラマーがよくやりそうな酷いレベルじゃないかと思います。

もっと酷いのは対応ですね。こっそり誤魔化そうというあるまじき対応には怒りしか感じません。洗練されたデザインがどうだというのでしょうか?そんな上辺だけ取り繕うのがAppleという会社なら早く退場願いたいですね。ユーザーを馬鹿にし過ぎです。
  1. URL |
  2. 2014/02/25(火) 20:12:44 |
  3. 空耳 #-
  4. [ 編集]

>空耳さん
私もiOS7.0.6のリリースの時、おかしいなとは思いましたが見過ごしていました。
まさかこんな大バグを危険度を示さずにこっそりと入れ替えてしまおうなんてちょっと想像の中に無いです。
しかもセキュリティーの事で散々叩きまくられてきたAndroidの方が実は安全だったという落ちにもガックリです。
今までのマスコミを上げてのAndroid危ない報道は何だったんだと。

それとiOSのソースコードを見て更にガックリ。
これもしNeXT STEPの頃から有るバグとかだったらもう笑うしかないですよ。
可能性だけを言うと、ジョブズの書いたコードかも知れないって事ですよね。
(それとも彼はコードは書けないのかな?何方かアップルファンの方知ってます?)
私だって綺麗なコードなんて全然書けませんけど、さすがにこのgoto fail;の山は無いです。
  1. URL |
  2. 2014/02/25(火) 23:03:41 |
  3. 鈴 #GpEwlVdw
  4. [ 編集]

なんでもGoto処理か・・・。
私はあまりやりたくないのできっちりソースコードのプロセスの範囲を分けて明示したいとき以外は使わないですねぇ。
基本フラグ立てて処理してます。
(まあフラグ立ても同じようなミスは起こす可能性がありますが)

・・・つか・・・どうしてこうなったレベル・・・。うっかりフラグが逆転していたよりもひどいよ・・・。
  1. URL |
  2. 2014/02/25(火) 23:53:21 |
  3. D #hEXeLq3g
  4. [ 編集]

>Dさん
まあgotoを使いたい気持ちは私も分からないではないですが、
それにしても完全に依存した組み方をしていますよね。
幾らスコープを絞っているとはいえ、
まさかこんな前時代的なソースコードで動いていたとは驚きです。
  1. URL |
  2. 2014/02/26(水) 00:04:41 |
  3. 鈴 #GpEwlVdw
  4. [ 編集]

「Appleのセキュリティ対策はMicrosoftより10年遅れ」――KasperskyのCEO
http://www.itmedia.co.jp/enterprise/articles/1204/27/news031.html

この記事が出て2年弱。
何にも変わっていないですね。
  1. URL |
  2. 2014/02/26(水) 00:26:53 |
  3. 白ロムXperiaユーザー #-
  4. [ 編集]

>白ロムXperiaユーザーさん
成程、見ている人はきちんと見ていたんですね。
今回のお粗末な顛末を見てその記事を見ると非常に納得できるものが有ります。
あんなソースコードを見た後だと実感が半端ないです。
  1. URL |
  2. 2014/02/26(水) 00:37:31 |
  3. 鈴 #GpEwlVdw
  4. [ 編集]

これ、静的解析ツールにかけると「実行されないコードがあります」等の警告がでそうな感じです。
switch/caseにbreak;がないと警告を出してきますから。

SSL証明書の正当性のテストすら実施してこなかったということで、酷いですね。
  1. URL |
  2. 2014/02/26(水) 00:42:24 |
  3. mono #kpjYxc8I
  4. [ 編集]

>「Appleのセキュリティ対策はMicrosoftより10年遅れ」――KasperskyのCEO
10年遅れというのが、とんでもない過大評価だったと証明されたわけですね。
  1. URL |
  2. 2014/02/26(水) 02:02:33 |
  3. b #FUfi/TkY
  4. [ 編集]

分岐する前の
可能性もありますよね
  1. URL |
  2. 2014/02/26(水) 08:25:44 |
  3. 質問 #-
  4. [ 編集]

大事なことなので、2度書きたかったんだよ(震)
  1. URL |
  2. 2014/02/26(水) 09:35:38 |
  3. die #-
  4. [ 編集]

goto分是非はともかく、1行文でも { と } で囲む癖は付けた方がいいですね。囲ってあれば何の問題も無かったのに。

# 大昔、バグに注意で例によく出ていたケースですな。
  1. URL |
  2. 2014/02/26(水) 09:39:52 |
  3. ばっくらっしゅ #-
  4. [ 編集]

うーん、ソースのコーディングがどうのこうのと言うよりも、テストがちゃんとされているの? って思います。
結構 Apple ってポカミスというかテストしていれば、ちゃんと発見できるよねと言うのが多いですよね。
# いや、テストしていないから、こういう不具合が出るんですけどね。

まさに作品レベル!!
  1. URL |
  2. 2014/02/26(水) 10:24:54 |
  3. 生ぴーまん #bnistvpo
  4. [ 編集]

最近の端末ですが・・・

バグに関しては大事故だと思いますしお粗末とも思いますが、
iPhoneはアプリ主体ですしこのバグによる大きな被害があったかは疑問です
Macは・・・ご愁傷様でした・・・

Apqleの対応は酷いの一言ですね


iPhone4、iOS5.0.1の試験端末があったので引っ張り出してSafariで確認してみました
(UA情報の信憑性は皆無かもしれませんが、
このコメントはこの試験端末から書き込んでいます)
結果は「Safe」です

なお、iPhone4S、iOS6.0.1、Safariでの結果は真っ赤でしたので、
この間にバグが混入したのかもしれません

その他、
初代iPad、iOS3.2.2、Safari
GalaxyS、Android2.3.3、標準ブラウザ
でもアクセスしてみましたが、共に「Safe」でした
  1. URL |
  2. 2014/02/27(木) 09:59:48 |
  3. Rの中の人 #KnHW2vQ.
  4. [ 編集]

直接関係ありませんが、

折角なので、ネタ投下

今回選ばれたアップル本社に設置予定の故ステーブ・ジョブズの彫刻、どう思います?
http://www.excite.co.jp/News/it_g/20140226/Gizmodo_201402_post_14061.html

故ジョブズ氏が生きていたらなんというでしょうね。
  1. URL |
  2. 2014/02/27(木) 15:43:39 |
  3. 故思我 #HSDP1/G.
  4. [ 編集]

これは酷過ぎますね。一体いつからこの問題を放置し続けていたんでしょうか。。。

しかも今更になってこっそり修正して注意喚起を一切しないとか、企業として恥ずかしくないのかな・・・
  1. URL |
  2. 2014/03/02(日) 23:04:04 |
  3. T.モルディオ #-
  4. [ 編集]

そしてインドでは型落ちのiPhone4を売ろう、と。
7.0.6以降で無いなら「セキュリティゼロ(ソ○スネクストの商品ではない)ですよ」と。
さらに7xはバッテリーの減りが劇速。
iPhoneにした瞬間、どこにも逃げ道が無いですな。
後は野となれ山となれ。
(iPhoneを敬遠して)インドに幸多かれ。
  1. URL |
  2. 2014/04/12(土) 08:23:12 |
  3. 南 #22s72cIM
  4. [ 編集]

コメントの投稿(投稿時には必ず何らかの名前を付けてください)


管理者にだけ表示を許可する

(名前を入れないとクリックできません)

トラックバック

トラックバックURLはこちら
http://suzunonejh.blog15.fc2.com/tb.php/4513-b19ae65b
この記事にトラックバックする(FC2ブログユーザー)

最近の記事

機能リンク

最近のコメント

カテゴリー

ブログ内検索

ブログリンク

RSSフィード

QRコード

QR

月別アーカイブ



メールフォーム

お問い合わせ・ご質問はこちらから。

名前:
メール:
件名:
本文:

suzunone.m(あっと)gmail.com に
直メでもOKです。