1日で大手検索プロバイダのYahooから2ニュースが発表がありました。
①検索情報の削除の基準を作成
http://japan.cnet.com/news/service/35062495/
基準を作ったのは業界初とのことです。
Google はポリシーのみ公開されています。
今回公開されたYahooの基準
・被害申告者の属性(公的な側面を持つ人物であるか否か)
・プライバシー保護がより必要な未成年かどうか
Yahoo 削除申請ページ
https://www.yahoo-help.jp/app/ask/p/2508/form/searchfdbk-info
Google 削除申請ページ
https://www.google.com/webmasters/tools/removals
Google 削除ポリシー
https://support.google.com/websearch/answer/2744324
※Yahooの基準のページが見つかりません。誰か知っている人がいましたら教えてください。
②YahooとMicrosoftが検索提携を1か月延長
http://jp.reuters.com/article/technologyNews/idJPKBN0MQ03220150330
検索情報の提携を1か月延長されました。
3月で切れる予定だったものを単純に1か月伸ばしただけのものです。
今後も現在の体制を続けるかどうかは不明です。また、1か月で結論が出るかも不明です。
Yahoo、Microsoftどちらからもノーコメントです。
Googe、Yahoo、Microsoft(Bing)で世界の検索シェアの9割を占めています。
約ですが、Google 6割、Yahoo2割、Microsoft1割です。
この3社はライバルですが、協力関係を持っています。
GoogleとYahooは同じ検索エンジンを利用しています。
YahooとMicrosoftは検索のもととなる情報の共有を行っています。
Googleの独自性は自社の検索結果やIDから得られた情報で検索結果を表示することです。これによってID保有者に対して最適な検索結果を表示するようにしています。
Yahooの独自性は、様々なところから検索のもとになる情報をため込み、それによって検索結果を表示しています。
また、商業化への意識が強いため、広告費を多く払っている企業のページを検索結果の上位に持ってくる傾向にあります。
Microsoftは他社とは違い、ナチュラルな検索結果を意識しています。
また、Windowsとの一体化をかなり意識しています。
2015年4月1日水曜日
2015年3月26日木曜日
日立、20km長の光ファイバーで毎秒400ギガビット級の伝送に成功
日立製作所は20kmにも及ぶ光ファイバーで高速な伝送に成功しました。
http://www.nikkan.co.jp/news/nkx0320150319eaaa.html
今まで、長距離での光ファイバーは実現できていませんでした。
理由は素材的問題と光の減衰の問題です。
この技術によってデータセンター間の通信によるパフォーマンス劣化を防ぐことができます。むしろ、ここまで早いとネットワーク装置が先に限界になる可能性の方が高い気がします。
この技術で直接データセンター間をつなげば、セキュリティ面でもIP-VPNや専用線よりも安全な通信ができることになりますので、広まってほしい技術だと思っています。
IP-VPNはインターネット上に固定のルートを作って暗号化して通信を行う方式です。そのため、固定ルートが解析され、暗号化を解除された場合、盗聴の危険性がありました。
専用線は名前の通り専用の線を使っていますが、技術的に長距離の線を作ることができなかったので何度もスイッチを介していました。そのため、スイッチの乗っ取りによって盗聴される危険性はありました。
今回は20kmなので日本の巨大なデータセンターをすべてつなぐには至っていませんが、今後さらに距離が延びれば、日本に安全なネットワークが構築されることになります。
この技術は非常に未来があって期待したいものです。
http://www.nikkan.co.jp/news/nkx0320150319eaaa.html
今まで、長距離での光ファイバーは実現できていませんでした。
理由は素材的問題と光の減衰の問題です。
この技術によってデータセンター間の通信によるパフォーマンス劣化を防ぐことができます。むしろ、ここまで早いとネットワーク装置が先に限界になる可能性の方が高い気がします。
この技術で直接データセンター間をつなげば、セキュリティ面でもIP-VPNや専用線よりも安全な通信ができることになりますので、広まってほしい技術だと思っています。
IP-VPNはインターネット上に固定のルートを作って暗号化して通信を行う方式です。そのため、固定ルートが解析され、暗号化を解除された場合、盗聴の危険性がありました。
専用線は名前の通り専用の線を使っていますが、技術的に長距離の線を作ることができなかったので何度もスイッチを介していました。そのため、スイッチの乗っ取りによって盗聴される危険性はありました。
今回は20kmなので日本の巨大なデータセンターをすべてつなぐには至っていませんが、今後さらに距離が延びれば、日本に安全なネットワークが構築されることになります。
この技術は非常に未来があって期待したいものです。
ラベル:
IT業界,
インターネット,
日本のメディアが放送しないNEWS
2015年3月16日月曜日
モジラ、『Shumway』でFlash対応
ブラウザのfirefoxで有名なMozillaが『Shumway』というプロジェクトでFlashの対応を進めることがわかりました。
http://japan.zdnet.com/article/35060439/
今までFlashはAdobe Flash Playerをインストールしないと使えませんでした。
また、これは標準的でオープンな技術ではありませんでした。
これを嫌ったMozillaはFlashをHTML5で動作させるためのプロジェクトとして『Shumway』を立ち上げました。
このプロジェクト完了後は、 Adobe Flash PlayerがなくてもHTML5で動作するように変換されます。
予想ですが、Firefoxでは変換することがデフォルトになると思われます。
また、HTML5で動作するため、通常のFlashよりも軽量に動作するため、PC専用だったページもスマートフォンで動作することが想定されます。
とても楽しみなので期待です。
http://japan.zdnet.com/article/35060439/
今までFlashはAdobe Flash Playerをインストールしないと使えませんでした。
また、これは標準的でオープンな技術ではありませんでした。
これを嫌ったMozillaはFlashをHTML5で動作させるためのプロジェクトとして『Shumway』を立ち上げました。
このプロジェクト完了後は、 Adobe Flash PlayerがなくてもHTML5で動作するように変換されます。
予想ですが、Firefoxでは変換することがデフォルトになると思われます。
また、HTML5で動作するため、通常のFlashよりも軽量に動作するため、PC専用だったページもスマートフォンで動作することが想定されます。
とても楽しみなので期待です。
2015年2月12日木曜日
google chrome SPDY から http/2へ
google chrome が SPDY を http/2 に移行することがわかりました。
http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html
http/2 については依然ご紹介しました。
いつ移行するかずっと噂になっていましたが、ついに移行されることがわかりました。
これはgoogle chromeユーザは爆速が楽しみですね。
調べたら、現在対応しているブラウザはgoogle chrome、firefox、IE(windows 10のみ)のようです。
これらのユーザは少しずつ以降されgoogle関連サービスが早くなります。
速さの違いはもはや数十倍とかそういうレベルではないので本当にありがたいです。
しかし、google意外のサービスは対応していないため今まで通りhttp/1.1のままになってしまいます。
これは各WEBサーバが対応していないためです。
たぶん、Windows Server 2016と噂される次期Windows ServerのIISでは対応されると思われます。
apacheはいつの対応になるかまったく見えません。(むしろ、プロジェクトってまだ運営されているのかすら・・・)
一方で普及することでの問題もあります。
まずは、ハードウェアスペックが追い付かない人が出てくることです。
早くデータ転送されることでたくさん処理できるようになるためブラウザが利用するメモリ量が増えることが予想されます。いくらメモリが余っているからとはいえ、古めのPCを使っている人には逆に遅くなることも想定されます。
最近はやりのIoTで組込系ではそれがなおさらです。
ほかにもあまりにも転送速度が速いため、マルウェアにかかってしまったコンピュータが外でデータを流出されてしまう速度も上がってしまいます。
気が付いたときにはもう間に合わないということが用意に想定されます。
これからはよりセキュリティへの投資が増えることになると思われます。
http://blog.chromium.org/2015/02/hello-http2-goodbye-spdy-http-is_9.html
http/2 については依然ご紹介しました。
いつ移行するかずっと噂になっていましたが、ついに移行されることがわかりました。
これはgoogle chromeユーザは爆速が楽しみですね。
調べたら、現在対応しているブラウザはgoogle chrome、firefox、IE(windows 10のみ)のようです。
これらのユーザは少しずつ以降されgoogle関連サービスが早くなります。
速さの違いはもはや数十倍とかそういうレベルではないので本当にありがたいです。
しかし、google意外のサービスは対応していないため今まで通りhttp/1.1のままになってしまいます。
これは各WEBサーバが対応していないためです。
たぶん、Windows Server 2016と噂される次期Windows ServerのIISでは対応されると思われます。
apacheはいつの対応になるかまったく見えません。(むしろ、プロジェクトってまだ運営されているのかすら・・・)
一方で普及することでの問題もあります。
まずは、ハードウェアスペックが追い付かない人が出てくることです。
早くデータ転送されることでたくさん処理できるようになるためブラウザが利用するメモリ量が増えることが予想されます。いくらメモリが余っているからとはいえ、古めのPCを使っている人には逆に遅くなることも想定されます。
最近はやりのIoTで組込系ではそれがなおさらです。
ほかにもあまりにも転送速度が速いため、マルウェアにかかってしまったコンピュータが外でデータを流出されてしまう速度も上がってしまいます。
気が付いたときにはもう間に合わないということが用意に想定されます。
これからはよりセキュリティへの投資が増えることになると思われます。
2015年1月25日日曜日
【参加】HTML5 Conference
やはりこれからはHTML5の時代だと改めて感じました。
これからはどのプラットフォームでもHTML5で開発できるようになるのは非常に強みです。
一方で同じ方法に進んでいる言語として、C#とJavaがあります。
C#は.net Framework core、JavaはJava ME Embedded と組込にも積極的です。
メモ(メモを取ったものだけです。)
HTML5 Conference
http://events.html5j.org/conference/2015/1/
■HTTP/2の現状とこれから
www.slideshare.net/shigeki_ohtsu/http2-ohtsu-html5conf2015
講師:IIJ 大津繁樹
日程:2015年1月25日 14:20~15:00
・http2の標準化されもうすぐRFCに登録される予定。
今後は、3の作成を行っていく。
脆弱性が見つからない限りはメジャーバージョンアップのみを行う。
・http1.1の問題は、TCPが同時に4~6個までしか並列ができなかった。
→1つのTCPの中にストリームという単位で分割して送ることでリソースの限り並列できるようになった。
・6本のTCPがそれぞれ調整しあいながらデータの送受信を行っていた。
→1本にまとめることによって、調整という処理がなくなった。
・http1.1ではテキストプロトコルは自由に書くことができたが、http2ではバイナリプロトコルにし、バイト単位で内容を決定したため、正確情報になった。
・spdy3はほぼすべてのブラウザが対応している。
http2はfirefox35、chrome41、windows10 IEはすでに標準で対応になる。
・ブラウザ側で処理によって優先度のタグ処理が追加されて操作性が向上する。
・tlsのみのサポートになる予定でしたが、平文も仕様に導入することになったが、
各ブラウザベンダーともtlsを用いたものを中心としている。
現在検討中のtls3が公開されたら、tls2を切り捨て、3のみの対応になる見込み。
・http3で検討中のこと
ALT-SVCフレーム
Websocet over HTTP2
明示的プロキシ機能
日和見暗号化
WEB Pushの拡張(ブラウザ上でアプリが動作しいている時、ブラウザを立ち上げているが、アプリを起動していないとき、ブラウザも立ち上げていないとき、1つのブラウザで複数のインスタンスを立ち上げているとき
・新プロトコルQUIC
googleが独自に開発
UDPレベルでTCP、TLS相当の機能を可能にする。
googleのサービスは実装している。
2015年中にライブラリ化して全国に広める予定。
■Web of Things を実現する技術 - Mozilla が取り組む Web プラットフォームの進化
講師:Mozilla Japan 浅井 智也
日程:2015年1月25日 15:20~16:00
http://www.slideshare.net/dynamis/web-of-technologies
・FirefoxOSを作った理由
WEBとモバイルが分断されたていた。WEBをプラットフォームとしてWEBとクライアントをシームレスにするために作った。
・FirefoxOSの今後
テレビへの搭載は決定
ウェアラブル端末に導入しすべてがインターネットにつながって素晴らしい世界を作りたい。
・ChromecastのFirefoxOS版のHDMI端末Matchstickが2月に発売。
ソフトだけでなく、ハードウェアまですべてオープンにしている。
・OpenWebBoard
KDDIがHDMI端末の組込端末でリモコンの受け側になる。
・APIでアプリ同士がつながるのは当たり前なのでよりハイレベルへ。
・WebGLやasm.js、Emecriptenを導入にインターネットでのゲームに貢献してきた。
ゲームエンジンをWeb対応、移植を予定。
Unityの場合、ネイティブとWebでほぼ差がなくなってきた。特にWebGLの場合は内部動作も一緒の状態になっている。
・ビデオカメラなどで画像認識して、顔認識、翻訳などネイティブとWEBを比べるとWEBが弱く、遅かった。
それの改善を取り組んでいる。
また、バーチャルリアリティを実現することもエンジンは用意されているが、実装はまだされていない。誰かやって・・・(WebVR)
電子書籍・組版技術用技術も実装されている。是非、標準化、商品化を・・・
・LowerLevel
asm.jsはアセンブリのようなJavaScript。
JavaScriptが遅いの型が動的であること。変数をWebkit側で変数を事前を予想・定義すること、C言語の一部の機能を停止することによって、速度をほぼ同じにしている。
■転ばぬ先のエンタープライズWeb開発プランニング
講師:小川 充 株式会社クレスコ
酒巻 瑞穂 グロースエクスパートナーズ株式会社
日程:2015年1月25日 16:20~17:00
・オフライン機能、アクセシビリティを導入するか、どこまで導入するか決めない必要がある。
・パッケージ管理が難しい。バージョンなどがめちゃくちゃになっているケースが多い。
・成長や保守を行うアプリの場合、自動テストを導入しないと本当に苦しい。
自動テストのステップ4
①やらないという決断を下す
作り捨てや止まっても業務に影響の少ないものは誤ればよいのでしない。
②テスト基盤の整備をする。
③カバレッジゼロ/pendingシナリオファイルを準備
スタートとゴールを明確にする。
④カバレッジの上昇とデバックの消化を行う。
・コード品質を上げるためにLintを導入する。各フレームワーク専用で用意されているものもある。
・コード品質のメトリックス評価をする。Plato
ファイル単位での可視化をする。どのファイルに問題が出ているか理解する。
・自動化の可否、結果レポートのフォーマット、運用ルール、テスト自動化の導入プランの決定が必要。
・Single Page Application ではクライアントの操作や状態をトレースできないため、モニタリング、再現できるように環境を整える必要がある。
操作ログ、クラッシュログ、利用環境、パフォーマンス
・パフォーマンスは定期的に取らないと利用しているうちに徐々に遅くなるアプリが多い。
・フロントエンド開発は昔よりもやることが増えたため、Grunt タスクラニングツールを導入しないときつい。
・各ツール連携を検討しないと管理だけで開発ができなくなってしまう。
・人材が非常に不足している。
これからはどのプラットフォームでもHTML5で開発できるようになるのは非常に強みです。
一方で同じ方法に進んでいる言語として、C#とJavaがあります。
C#は.net Framework core、JavaはJava ME Embedded と組込にも積極的です。
メモ(メモを取ったものだけです。)
HTML5 Conference
http://events.html5j.org/conference/2015/1/
■HTTP/2の現状とこれから
www.slideshare.net/shigeki_ohtsu/http2-ohtsu-html5conf2015
講師:IIJ 大津繁樹
日程:2015年1月25日 14:20~15:00
・http2の標準化されもうすぐRFCに登録される予定。
今後は、3の作成を行っていく。
脆弱性が見つからない限りはメジャーバージョンアップのみを行う。
・http1.1の問題は、TCPが同時に4~6個までしか並列ができなかった。
→1つのTCPの中にストリームという単位で分割して送ることでリソースの限り並列できるようになった。
・6本のTCPがそれぞれ調整しあいながらデータの送受信を行っていた。
→1本にまとめることによって、調整という処理がなくなった。
・http1.1ではテキストプロトコルは自由に書くことができたが、http2ではバイナリプロトコルにし、バイト単位で内容を決定したため、正確情報になった。
・spdy3はほぼすべてのブラウザが対応している。
http2はfirefox35、chrome41、windows10 IEはすでに標準で対応になる。
・ブラウザ側で処理によって優先度のタグ処理が追加されて操作性が向上する。
・tlsのみのサポートになる予定でしたが、平文も仕様に導入することになったが、
各ブラウザベンダーともtlsを用いたものを中心としている。
現在検討中のtls3が公開されたら、tls2を切り捨て、3のみの対応になる見込み。
・http3で検討中のこと
ALT-SVCフレーム
Websocet over HTTP2
明示的プロキシ機能
日和見暗号化
WEB Pushの拡張(ブラウザ上でアプリが動作しいている時、ブラウザを立ち上げているが、アプリを起動していないとき、ブラウザも立ち上げていないとき、1つのブラウザで複数のインスタンスを立ち上げているとき
・新プロトコルQUIC
googleが独自に開発
UDPレベルでTCP、TLS相当の機能を可能にする。
googleのサービスは実装している。
2015年中にライブラリ化して全国に広める予定。
■Web of Things を実現する技術 - Mozilla が取り組む Web プラットフォームの進化
講師:Mozilla Japan 浅井 智也
日程:2015年1月25日 15:20~16:00
http://www.slideshare.net/dynamis/web-of-technologies
・FirefoxOSを作った理由
WEBとモバイルが分断されたていた。WEBをプラットフォームとしてWEBとクライアントをシームレスにするために作った。
・FirefoxOSの今後
テレビへの搭載は決定
ウェアラブル端末に導入しすべてがインターネットにつながって素晴らしい世界を作りたい。
・ChromecastのFirefoxOS版のHDMI端末Matchstickが2月に発売。
ソフトだけでなく、ハードウェアまですべてオープンにしている。
・OpenWebBoard
KDDIがHDMI端末の組込端末でリモコンの受け側になる。
・APIでアプリ同士がつながるのは当たり前なのでよりハイレベルへ。
・WebGLやasm.js、Emecriptenを導入にインターネットでのゲームに貢献してきた。
ゲームエンジンをWeb対応、移植を予定。
Unityの場合、ネイティブとWebでほぼ差がなくなってきた。特にWebGLの場合は内部動作も一緒の状態になっている。
・ビデオカメラなどで画像認識して、顔認識、翻訳などネイティブとWEBを比べるとWEBが弱く、遅かった。
それの改善を取り組んでいる。
また、バーチャルリアリティを実現することもエンジンは用意されているが、実装はまだされていない。誰かやって・・・(WebVR)
電子書籍・組版技術用技術も実装されている。是非、標準化、商品化を・・・
・LowerLevel
asm.jsはアセンブリのようなJavaScript。
JavaScriptが遅いの型が動的であること。変数をWebkit側で変数を事前を予想・定義すること、C言語の一部の機能を停止することによって、速度をほぼ同じにしている。
■転ばぬ先のエンタープライズWeb開発プランニング
講師:小川 充 株式会社クレスコ
酒巻 瑞穂 グロースエクスパートナーズ株式会社
日程:2015年1月25日 16:20~17:00
・オフライン機能、アクセシビリティを導入するか、どこまで導入するか決めない必要がある。
・パッケージ管理が難しい。バージョンなどがめちゃくちゃになっているケースが多い。
・成長や保守を行うアプリの場合、自動テストを導入しないと本当に苦しい。
自動テストのステップ4
①やらないという決断を下す
作り捨てや止まっても業務に影響の少ないものは誤ればよいのでしない。
②テスト基盤の整備をする。
③カバレッジゼロ/pendingシナリオファイルを準備
スタートとゴールを明確にする。
④カバレッジの上昇とデバックの消化を行う。
・コード品質を上げるためにLintを導入する。各フレームワーク専用で用意されているものもある。
・コード品質のメトリックス評価をする。Plato
ファイル単位での可視化をする。どのファイルに問題が出ているか理解する。
・自動化の可否、結果レポートのフォーマット、運用ルール、テスト自動化の導入プランの決定が必要。
・Single Page Application ではクライアントの操作や状態をトレースできないため、モニタリング、再現できるように環境を整える必要がある。
操作ログ、クラッシュログ、利用環境、パフォーマンス
・パフォーマンスは定期的に取らないと利用しているうちに徐々に遅くなるアプリが多い。
・フロントエンド開発は昔よりもやることが増えたため、Grunt タスクラニングツールを導入しないときつい。
・各ツール連携を検討しないと管理だけで開発ができなくなってしまう。
・人材が非常に不足している。
2015年1月22日木曜日
ツイキャスに「規制回線モード」追加
2015年1月14日付けでツイキャスに規制モードが追加されました。40kbpsまでサポートしているとのこと。
http://www.itmedia.co.jp/news/articles/1501/14/news070.html
これはとてもありがたいことです。
現在、どのキャリアでも規定値を超えると128kbpsになってしまいます。
40kbpsなら速度制限時でも十分に利用できます。
このような対応は他の動画サービスにも対応してもらいたいです。
ライブ配信だけでなくyoutubeなどの動画配信サービスもモバイル向けまたは低画質モードが追加されるとよいなと思います。
世界のトラフィックの6割はyoutubeと言われています。これは明らかに世界のネットワークを圧迫し、多くのリソースを使用しています。
世界のネットワークのリソースが解放されることで電力消費削減など環境への貢献もできると思います。そして、ユーザーの使い勝手も上がり、一石二鳥です。
ユーザーは高品質を求めていると同時に悪ければ悪いで慣れてしまうものです。
世界はよくなりすぎましたから、多少の『仕方ない』を広めることはよいことだと思います。
これはこれからITを導入する後進国のためにも良い技術になりますので是非研究していただきたいです。
http://www.itmedia.co.jp/news/articles/1501/14/news070.html
これはとてもありがたいことです。
現在、どのキャリアでも規定値を超えると128kbpsになってしまいます。
40kbpsなら速度制限時でも十分に利用できます。
このような対応は他の動画サービスにも対応してもらいたいです。
ライブ配信だけでなくyoutubeなどの動画配信サービスもモバイル向けまたは低画質モードが追加されるとよいなと思います。
世界のトラフィックの6割はyoutubeと言われています。これは明らかに世界のネットワークを圧迫し、多くのリソースを使用しています。
世界のネットワークのリソースが解放されることで電力消費削減など環境への貢献もできると思います。そして、ユーザーの使い勝手も上がり、一石二鳥です。
ユーザーは高品質を求めていると同時に悪ければ悪いで慣れてしまうものです。
世界はよくなりすぎましたから、多少の『仕方ない』を広めることはよいことだと思います。
これはこれからITを導入する後進国のためにも良い技術になりますので是非研究していただきたいです。
2015年1月8日木曜日
Azure Media Services のライブ ストリーミングで暗号化が可能に
Azure Media Services のライブ ストリーミングサービスで暗号化が可能になりました。
http://blogs.msdn.com/b/windowsazurej/archive/2015/01/05/announcing-azure-media-services-live-streaming-with-playready-encryption-capability.aspx
ライブストーミングサービスはUstreamを始め世界にいくつもありますが、しかし暗合化できるサービスはありませんでした。
そのため、盗聴される危険性にさらされていました。
理由はいくつもありますが、リアルタイムで暗号化するのはパフォーマンス的に難しかったです。
しかし、今回可能になりました。これはAzureの膨大なリソースとMicrosoftの高度なプログラムのおかげです。
暗号化方式はAESで現在最高の暗号化方法です。さらにPlayReadyも追加されることが決定しました。
http://blogs.msdn.com/b/windowsazurej/archive/2015/01/05/announcing-azure-media-services-live-streaming-with-playready-encryption-capability.aspx
ライブストーミングサービスはUstreamを始め世界にいくつもありますが、しかし暗合化できるサービスはありませんでした。
そのため、盗聴される危険性にさらされていました。
理由はいくつもありますが、リアルタイムで暗号化するのはパフォーマンス的に難しかったです。
しかし、今回可能になりました。これはAzureの膨大なリソースとMicrosoftの高度なプログラムのおかげです。
暗号化方式はAESで現在最高の暗号化方法です。さらにPlayReadyも追加されることが決定しました。
2014年12月31日水曜日
【日本のメディアが放送しないNEWS】1200万台以上のルーターに脆弱性
Allegroが提供しているルーターのファームウェアに脆弱性が発見されました。
https://www.allegrosoft.com/allegro-software-urges-manufacturers-to-maintain-firmware-for-highest-level-of-embedded-device-security/news-press.html
その数は世界で1200万台以上です。
脆弱性の内容はルーターのメモリ破壊が発生し管理者権限が奪われてしまうというもの。
この悪用方法は、 『Misfortune Ccookie』を許可してしまいブラウザからあらゆるデバイスをリモート操作できてしまうというものです。
対象のルーターはファームウェア『Allegro RomPager』のバージョン4.34以前ものが対象です。
脆弱性のルーター候補は以下のリストに載っています。
http://mis.fortunecook.ie/misfortune-cookie-suspected-vulnerable.pdf
見たところ結構日本でも使われているモデルがあるようです。特にZyXELのモデルは日本でも結構使われています。
また、TP-Linkは家庭用でも無線ルーターとして利用されているケースがあるので企業だけでなく個人でも確認した方が良いです。
https://www.allegrosoft.com/allegro-software-urges-manufacturers-to-maintain-firmware-for-highest-level-of-embedded-device-security/news-press.html
その数は世界で1200万台以上です。
脆弱性の内容はルーターのメモリ破壊が発生し管理者権限が奪われてしまうというもの。
この悪用方法は、 『Misfortune Ccookie』を許可してしまいブラウザからあらゆるデバイスをリモート操作できてしまうというものです。
対象のルーターはファームウェア『Allegro RomPager』のバージョン4.34以前ものが対象です。
脆弱性のルーター候補は以下のリストに載っています。
http://mis.fortunecook.ie/misfortune-cookie-suspected-vulnerable.pdf
見たところ結構日本でも使われているモデルがあるようです。特にZyXELのモデルは日本でも結構使われています。
また、TP-Linkは家庭用でも無線ルーターとして利用されているケースがあるので企業だけでなく個人でも確認した方が良いです。
登録:
投稿 (Atom)