本日のセキュリティ寄りだけど、そうじゃないのも混じってるニュースだよ。
セキュリティコード含むクレカ情報流出の可能性 – 家具販売サイト
http://www.security-next.com/076794
カゴヤ・ジャパンもそうだったけど、自分とこのDBにクレカ情報持ってるところって少なくないんだな。決済代行サービスやってる会社に投げつけて、自分では持たないようにしないとダメだよ。
NTTドコモからマイナンバーカード対応Androidスマホが登場
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/121600736/?ST=security&itp_list_theme
さすがAndroidは小回りがきくなあ、ってなところですが、マイナンバーを日常的に使うようになるまでは使おうと思えないな…。証券口座作るのに１週間かかっても別にいいよ。微妙すぎる利便性に比べて、リスクの方がよっぽど気になってしまう。
ロシア、中国とのネット提携が進む。GFW技術の輸出も ほか～2016年11月
http://internet.watch.impress.co.jp/docs/column/m_china/1035905.html
赤いネットが金盾実装。見方を変えれば、ロシアと中国が脆弱性を共有したことになる。どちらかでほころびが見つかれば、そのほころびを突いた攻撃が両方で発生しうる。このことが今後どう影響するか…。
ランサム被害者の15％が支払に応じる – 5万円以上が3割超
http://www.security-next.com/076728
この題名不正確じゃないか？ 10万円以上はほぼゼロだぞ。4割が1万円以下って方がニュースのような気がするし。こんなのでも生計成り立つのかねえ？
↓インターネット利用者数がこれなので…
http://www.soumu.go.jp/joho_tsusin/kids/internet/statistics/internet_02.html
試しに計算してみると、
(1億46万人 × 4.5％ × 15.2％) × (\500×23.5% ＋ \5,000×17.6% ＋ \30,000×17.6% ＋ \75,000×35.3% ＋ \?×6.0%)
＝687,147人 × (\32,753 ＋ \?×6.0%)
＝\22,505,762,466 ＋ (\?×41,229人)
ということで、市場規模は225億円以上。日本だけでね。この金額はと言うと、単純にググって出てきたのが以下。ほう…、基地局向けってマニアックだなｗ。
▼携帯基地局向け部材市場、2015年度は225億円 – ケータイ Watch Watch
http://k-tai.watch.impress.co.jp/docs/column/mca/751143.html
他には200億円台だと、水素水とか男性肌ケアとか。微妙だけど、決して小さくもないぐらいの規模ですね。
「Dirty COW」にあらたな攻撃手法 – 直接メモリにコードを追加可能
http://www.security-next.com/076618
脱！なるほど分からん！ ということで、もっと掘り下げてみましょう。
↓カーネルの脆弱性
https://rhn.redhat.com/errata/RHSA-2016-2124.html
REHL6や7のところには書かれてなくて、REHL5のところにしか記載がないけどこれで合ってるのかな？ Google先生の通訳を交えてバグの原因を探ってみる。
- ジャーナルモード ‘ordered’を実行しているときに、カーネルクラッシュまたはファイルシステムの破損が発生する。
- カーネルクラッシュは、2つのジャーナル関数間の競合状態によるヌルポインタ逆参照によって引き起こされる。
- ファイルシステムの破損は、do_get_write_access（）関数とバッファ書き込みの間の競合状態のために発生する。
⇒まず、ジャーナルモードってなんじゃい！ということで、ファイルシステムのお勉強から。
▼CentOS ext4ファイルシステム
http://www.unix-power.net/linux/ext4.html
書き込む本体データと、そのメタデータをどう記録するかの設定らしい。んで、デフォルトがorderedモード。それなりに処理が速くて、状況によって書き込みに失敗することがあるモードとのこと。その失敗するパターンをうまいこと悪用して、カネールクラッシュさせたりファイルシステムを壊したりしたよ、ってことか。
- ファイルのタイムスタンプ処理に問題があったため、一部のGFS2（Global File System 2）ファイルのタイムスタンプ値が正しくない状態になっていた。問題の処理は以下の2つ。
- GFS2ファイルにアクセスした実際の時刻よりも、前の時刻に終了した場合のatimeタイムスタンプに関する処理。
- GFS2ファイルが1つのノードから書き込まれ、別のノードから読み書きされたときに失われたmtimeおよびctimeタイムスタンプの更新に関する処理。
⇒通常ではありえない時刻の更新によって想定外の動きをしちゃいました、ってことか。
うーん、本題と結びついてないような気が…。メモリ関係ないじゃん。単にREHL5だけのバグなのかな。カーネル作ってる人たちのコミュニティとかに入れば、もっと具体的なことが見えてくるのかな？