1仕様書無しさん2014/04/08(火) 22:52:56.23
いくらお前らでも対策できないよな
2仕様書無しさん2014/04/08(火) 23:07:00.99
￣￣￣￣￣￣￣l/￣￣￣￣￣￣￣￣￣￣￣
∧＿∧
( ´･ω･`) ∧＿∧
／ ＼ （ ）何言ってんだこいつ
.＿＿| | .| |＿ / ヽ
||＼ ￣￣￣￣ ／ .| | |
||＼..∧＿∧ (⌒＼|_＿./ ./
||. （ ） ~＼___＿_ノ| ∧＿∧
/ ヽ 空気読めよ ＼| （ ）
| ヽ ＼/ ヽ. ｵﾏｴ馬鹿だろ
| |ヽ、二⌒) ／ .| | |
.| ヽ ＼∧＿∧ (⌒＼|_＿./ /
3仕様書無しさん2014/04/08(火) 23:07:17.71
1.0.1なんて新しいバージョン使ってないし
4仕様書無しさん2014/04/09(水) 01:07:30.38
影響あるのはフリーソフト使ってる奴らだけだろ？
プロプライエタリな俺らには関係ないよ
5仕様書無しさん2014/04/09(水) 01:18:18.83
アプリケーションサーバのSSL実装独自でやってるところあるんだ
6仕様書無しさん2014/04/09(水) 01:22:19.19
Openと名前のつくものは関わらないほうがいい
7仕様書無しさん2014/04/09(水) 01:51:12.27
オープン系(死語)
8仕様書無しさん2014/04/09(水) 22:41:14.91
いや、今まさに対応してきたんだが
9仕様書無しさん2014/04/10(木) 04:44:36.27
>>6
Open XMLフォーマットを採用してるMS Office使えないじゃん 10仕様書無しさん2014/04/11(金) 01:43:51.84
Open XMLフォーマットを使わなければよい
11仕様書無しさん2014/04/11(金) 03:24:51.20
>>10
でもソフトがOpen XMLに対応している 12仕様書無しさん2014/04/11(金) 18:35:00.89
OpenSSLの脆弱性を含んだライブラリーを使った市販の製品もあるから、
クライアント側では、それらも対策しないといけないな。
13仕様書無しさん2014/04/12(土) 07:38:09.78
Windows Server無双
14仕様書無しさん2014/04/12(土) 13:40:21.26
15仕様書無しさん2014/04/12(土) 16:08:49.06
>>1
いくらってｗｗ
もともとレゴブロックのように部品をくっつけるしかできないやつが９９％だよｗｗ
部品開発すら出来ない連中なんだからｗｗ 16仕様書無しさん2014/04/12(土) 16:27:21.96
Open-GLはいずこへ。
17仕様書無しさん2014/04/12(土) 18:06:36.61
OpenGL ESなら普通にスマートフォンで使われてるらしい
18仕様書無しさん2014/04/16(水) 21:38:06.54
>>1
ハートビート機構のところの
サイズチェックとメモリの確保のところをいじるだけだぞ・・・・ 19仕様書無しさん2014/04/18(金) 01:55:49.18
20仕様書無しさん2014/04/19(土) 09:34:47.11
OpenSSLに限らずOpenBSDは遅くても良いから脆弱性を起こさない事を目標にしています。
http://slashdot.jp/story/05/08/25/0917258/OpenBSD%E3%80%81malloc3-%E3%... [slashdot.jp]
投稿からリンクされていますが、このmallocの変更は死ぬ程遅くなるはずです。
しかし、それでもOpenBSDは採用します。
もちろん、速度が欲しい場合もあると思いますが、
必要に応じて選べるのが良いと思います。
速度が必要ならオリジナルのOpenSSLを、SSLで通信しているのを覗かれたくない人はOpenOpenSSLを、と選べるようになってくれた方が嬉しいです。
あなたが覗かれても良いならどうぞOpenSSLを使ってください。
私は覗かれて欲しくないので、良いCPUのマシンとOpenOpenSSLを使います。 21仕様書無しさん2014/04/19(土) 21:02:21.40
結局、自分が対象になってるかはどうやって確認したらいいの？
それとどういう対策が必要？
22仕様書無しさん2014/04/19(土) 21:12:16.72
>>21
確認方法は、opensslのバージョンを確認すること。
主要なディストリならもう更新が来てるはず。パッケージ更新しておけば大丈夫だろ。 23仕様書無しさん2014/04/21(月) 09:03:27.16
24仕様書無しさん2014/04/22(火) 19:08:28.42
>>23
これつかって他所のサイトを調べたら攻撃と見なされて逮捕とかならないの？ 25仕様書無しさん2014/04/23(水) 00:34:06.99
26仕様書無しさん2014/04/23(水) 00:38:29.87
いやこの場合はビードで合ってるだろ。頭悪いのか？
27仕様書無しさん2014/04/23(水) 00:39:51.06
HeartBleedが意図した動作しちゃダメだろ
28仕様書無しさん2014/04/23(水) 00:47:45.91
これがマ板のレベルですよ皆さんｗ
29仕様書無しさん2014/04/23(水) 00:57:58.44
一昨日のＷＢＳで簡単な説明があったな。
クラッカー側が、セッションを始める時点でのやりとりを利用してるとか。
一機にたくさんのリクエストを出すと、つい机の中にある
秘密情報も送ってしまうとか．．．どんだけアホなんだよ。
先生に宿題の状態をせかされて、彼女の「クパ〜♪」画像を
間違って送ってしまい、先生に彼女の股がパイパンだと知られて
しまったみたいな事らしいわ。
30仕様書無しさん2014/04/23(水) 01:26:16.34
>>29
簡単に言うと、OpenSSL 1.0.1 で搭載された生存監視 (Heart Beat = 心臓の鼓動確認) のバグ。
OpenSSL 1.0.1 は、クライアントから報告された生存監視メッセージの文字数分だけメモリを
確保して、その後に送られてくるメッセージを格納し、最後にそのメモリの内容をクライアント
に返している。
----
期待する動作：
クライアント「これから５文字のメッセージを送るから生きてたらそのまま返してね」
「こんにちわ」
サーバー 「こんにちわ」
クライアント（サーバーとはちゃんと通信できるんだ）
----
期待する動作：
クライアント「これから５文字のメッセージを送るから生きてたらそのまま返してね」
「こんにちわ」
サーバー 「こん＠＃？」
クライアント（あれ？サーバーとちゃんと通信できないぞ）
----
実際に送るメッセージよりも多い文字数を宣言すると…：
クラッカー 「これから64000文字のメッセージを送るから生きてたらそのまま返してね」
「こんにちわ」
サーバー 「こんにちわPASSWORD=12345&注文番号=12,34ユーザID=984521...」
最初の５文字は生存監視メッセージだけど、残りの63995文字は、直前まで使われていて
クリアされていないメモリの内容。SSL通信の内容や、SSL通信の暗号鍵とかが入ってる 31仕様書無しさん2014/04/23(水) 01:28:01.87
こんなもんよく今まで誰も気付かなかったなとそちらに驚く
32仕様書無しさん2014/04/23(水) 02:23:12.47
OpenSSLの脆弱性の露呈で、沢山の目にソースが見られているから欠陥がすぐ
わかる、問題は修正される、だから安全というオープンソース安全神話は完全に崩れたよな。
33仕様書無しさん2014/04/23(水) 04:08:39.61
>>30
すげーわかりやすいな
多分ドキュメント作るセンスあるな 34仕様書無しさん2014/04/23(水) 08:11:57.92
35仕様書無しさん2014/04/23(水) 11:41:43.84
>>28
偏差値４５くらいだろプログラマの平均偏差値ってｗ 36仕様書無しさん2014/04/23(水) 11:44:12.74
>>33
どこがだ？
ここはプログラマ板だぞ。
はしょったプログラムのせれば十分だろ 37仕様書無しさん2014/04/23(水) 13:00:28.47
>>35
偏差値ではかれない能力を持ってるのが俺らだろ 38仕様書無しさん2014/04/23(水) 15:59:37.16
>>36
いや、俺は上手い文章だと思うけど。
お客への説明に使えるし
マ板だからって全部プログラムで
書く必要も無いんじゃね？ 39仕様書無しさん2014/04/24(木) 01:02:39.13
>>38
とてもわかりやすいよな
これにケチつけるひねくれた性格が、この業界に性格の腐った奴が多いと思われる原因 40仕様書無しさん2014/04/24(木) 21:51:18.47
>>38
いや、うまい文章のまえに、ソースみてみろ。そのままだから。
ソース見たほうが圧倒的に早い。 41仕様書無しさん2014/04/25(金) 01:27:43.62
42仕様書無しさん2014/04/25(金) 04:17:48.28
ソース見たら分かるというのは詭弁
43仕様書無しさん2014/04/25(金) 04:21:02.34
オープンソースが安全っていう神話は崩れたな
44仕様書無しさん2014/04/25(金) 06:42:23.07
本当のことじゃないから神話なんじゃないの？
45仕様書無しさん2014/04/25(金) 08:27:03.63
いつまでも古いシステムを人が変わってまでサポートし続けるくらいなら
新しく作りなおしたほうがいいわ
46仕様書無しさん2014/04/25(金) 09:33:00.92
クローズドソースのほうが安全ですという奴は一生WinXP使ってろ
47仕様書無しさん2014/04/25(金) 10:21:12.44
>>46
最新のWindowsはオープンソースなのか？ 48仕様書無しさん2014/04/25(金) 10:55:22.73
論理学的には最新のWindowsがオープンソースだろうがなかろうが
WinXPの安全性の真偽の命題には関係ないね。はい次の人どうぞ。
49仕様書無しさん2014/04/25(金) 11:36:20.55
50仕様書無しさん2014/04/25(金) 14:20:25.54
XPとだけ比べて欲しいから。
XPとなら勝てる（それ以降では負ける）と
思っているから。
51仕様書無しさん2014/04/25(金) 15:00:20.33
クローズドソースなら安心という人はXPなんとかして下さいよ
52仕様書無しさん2014/04/25(金) 15:02:30.36
何とかする＝新しいOSにアップグレードする。
どうせLinuxだって新しいOSにアップグレードするだろ？
でGUIとか変えられちまうだろ？
なんもかわらん。
53仕様書無しさん2014/04/25(金) 15:51:56.04
やはり最強は北朝鮮が制作したRedStarLinuxだな
54仕様書無しさん2014/04/25(金) 20:30:16.06
OSSが悪いんじゃなくて
OSSなんかにかぶれてしまう奴の作るものは品質が落ちるだけ。
OSSだから直せない奴が悪いと逃げ続けテストを怠る。
大体、テストなんてつまらんことは、クローズドな環境で
業務に人生がかかってる社畜に無理矢理やらせないとまともにやるわけないだろ。
55仕様書無しさん2014/04/25(金) 21:08:34.26
オープンだろうがクローズだろうが
規模が大きくなれば同じ事。
56仕様書無しさん2014/04/26(土) 03:17:33.58
>>51
バカなの？それとも詭弁を弄してるつもりなの？ 57仕様書無しさん2014/04/26(土) 23:05:13.41
58仕様書無しさん2014/04/27(日) 05:41:42.00
俺33だが30とは赤の他人だぞ
59仕様書無しさん2014/04/27(日) 10:36:43.97
やっぱオープンソースって開発元がまともにテストしてないし
利用者側もまともにテストしない
こうやって実際の事故からフィードバックしていくから長い目でみれば強固になっていくけど
ユーザーが人柱になっていくという考え方は企業ユース、特にインフラ系には馴染まないのではないだろうか
60仕様書無しさん2014/04/27(日) 12:50:29.96
ドッグフードを食べるって知っているか？
割とよく知られるようになったのは戦うプログラマーあたりからだけど、
テストは万能じゃないから結局使いながらしかないってことなんだけどね。
61仕様書無しさん2014/04/27(日) 13:26:55.51
よくハード屋がソフト屋の品質に対する態度、特に後からネットでアップデートを配信すような行為を嘲笑するけど
ハード屋のミスは自動車会社で言えばリコールなどが起きれば大騒ぎなわけで、
いかにして隠蔽するかという動機がより強く働くようになる。
62仕様書無しさん2014/04/27(日) 20:37:20.96
ドッグフードの話ってのはテストの有効性というより、もっと精神論的な、
自分で使えないようなものは本当に力を入れては作らない（だから使うべきだ）
ということじゃないの？
オプソ信者ってのはやっぱオープンイコール良い事、バグがすくなるなる、
みたいなこと根拠も無いのに言い過ぎたんだと思うよ。
金を取る商品だから、セキュリティ対策は万全にする。どこの馬の骨とも
知れぬやつがレベルの低いコードを混入させる恐れが少ないからセキュリティ
の問題が起きにくいのだ、といっても（その真偽は別として）理屈としては
通るでしょ。
それと同じような実証や調査を経ていない幻想だったんだよ。
オープンソース安全神話。
63仕様書無しさん2014/04/27(日) 21:31:06.42
>>60
テストが万能じゃないからって、テストを放棄していいわけじゃない
そして>>59はオープンソースはドッグフードを食べてないって話をしてるんだよ
そもそもドッグフードを食べる話だってWindowsの事じゃないか 64仕様書無しさん2014/04/27(日) 22:04:15.83
不具合なんかテストで見つけるもんであって
ソース読んで探すものじゃないからな
65仕様書無しさん2014/04/27(日) 22:47:25.39
その後見つかった不具合は
ソース読んで直すんだからな。
66仕様書無しさん2014/04/27(日) 22:48:10.95
脆弱性（不具合）を見つけるとき
ハッカーはソース読むんだからな。
67仕様書無しさん2014/04/27(日) 22:50:49.33
おまえら何の話してんの？
68仕様書無しさん2014/04/29(火) 00:07:37.48
お前ら、ドッグフードにソースかけて食うのか？
69仕様書無しさん2014/04/29(火) 00:38:45.54
おまえらが食ってるのはタコの足だよ
70仕様書無しさん2014/05/14(水) 10:02:20.24
71仕様書無しさん2014/05/14(水) 14:51:38.72
どんなに時が早く過ぎてもふたりだけはこのままでいようと誓った
72仕様書無しさん2014/05/16(金) 20:21:26.85
>>32
そんなものはとっくの昔に無いと思う。
>>38
こないだの IE のセキュリティホール騒ぎに比べたら断然説明しやすいわな。 73仕様書無しさん2014/05/20(火) 20:36:56.03
>>72
> >>32
> そんなものはとっくの昔に無いと思う。
ESRの伽藍とバザールもそんなこと言ってないがね。
だから「神話」なんだろうが。 74仕様書無しさん2014/05/24(土) 18:45:46.04
しかしきたねーわかりにくいソースだなぁ
75仕様書無しさん2014/05/25(日) 21:58:14.01
だかそれがいい。
76仕様書無しさん2014/06/06(金) 21:02:51.94
また脆弱性きたです
77仕様書無しさん2014/06/07(土) 00:04:51.95
うわー月曜行きたくねえ。
78仕様書無しさん2014/06/17(火) 09:19:15.39
果たしてTheoは救世主となるか?
79仕様書無しさん2014/06/17(火) 09:48:36.39
TheOpenSSL 2.0まだー？
80仕様書無しさん2014/06/29(日) 22:53:31.82
>>66
半分間違い。
実際にそれをよくやってる俺に言わせてみれば、コードを読んで「これ、バグだろ」って思うことは絶対にない。
動作をさせてみて、変な動作に気が付いて、デバッガでプロセスにアタッチしながらソースを見る。
そうやって、データの変化を見て、あれ？ここの処理？？みたいな感じで発見に至る。 81仕様書無しさん2014/06/30(月) 02:08:21.43
82仕様書無しさん2014/06/30(月) 02:31:43.98
83仕様書無しさん2014/06/30(月) 02:56:52.79
84仕様書無しさん2014/06/30(月) 03:00:32.80
652 ：名無しさん＠お腹いっぱい。：2014/06/29(日) 03:18:05.44 ID:mldN4Sgm
(略)Heartbleedはサーバ側のバグであって (略)
654 ：名無しさん＠お腹いっぱい。：2014/06/29(日) 04:32:12.49 ID:HzuQuOzg
>>652
(略)Heartbleedバグはクライアント側でも発症するバグだから理解が足りてないよ。 (略)
655 ：名無しさん＠お腹いっぱい。：2014/06/29(日) 06:24:45.46 ID:cWXGt/QO
>>654
(略)もう一度言うけどサーバ側のバグだからね
バグのあるサーバを悪用すればクライアントから情報を引き出すこともできるので
新しい鍵に更新してくださいって話だよ
>Heartbleedバグはクライアント側でも発症するバグだから
クライアント側でどのようなバグが発症するの？
具体的にどうぞ
660 ：名無しさん＠お腹いっぱい。：2014/06/29(日) 06:57:59.11 ID:HzuQuOzg
>>655 (略)
> クライアント側でどのようなバグが発症するの？
指摘されてんだからちゃんと調べてから反論しろよアホ。サーバ側で起きるのと全く同じ現象が起きる。
Heartbleedは細工されたHeartbeatメッセージを受けとったOpenSSLライブラリが隠しておくべきデータを返すバグ。
Heartbeatはサーバクライアント双方が送信できるメッセージだからクライアント側のデータもしっかりと盗まれる。
攻撃側がサーバになるから攻撃サーバに接続させるための攻撃手順が必要になるし、
盗まれうるデータもサーバの場合よりマシな事が多いからあまり言及されていないだけ。(略) 85仕様書無しさん2014/06/30(月) 03:01:03.25
86仕様書無しさん2014/06/30(月) 03:13:49.01
683 ：名無しさん＠お腹いっぱい。：2014/06/30(月) 01:02:29.94 ID:b1Gb7HOS
>>675
つまりサーバに「攻撃用クライアントからの不正な要求を受けた際にメモリを漏らすバグ」があるのと同様に、
クライアントにも「攻撃用サーバからの不正な要求を受けた際にメモリを漏らすバグ」があるんだよな？
言ってることが180度変わってるんだけど頭大丈夫か？
689 ：名無しさん＠お腹いっぱい。：2014/06/30(月) 02:33:13.82 ID:GqSdja6D
>>683
> クライアントにも「攻撃用サーバからの不正な要求を受けた際にメモリを漏らすバグ」があるんだよな？
いやいや全く違う
クライアント側は要求に対して正しく応答しているだけ
サーバ側は攻撃者が正式な鍵を使用せず不正な要求をしてきた場合
接続を維持した状態で要求を無視するのが正しい動作だが、
クライアント側はサーバ側と違い正式な鍵がなければ
攻撃者は接続を維持できないのでサーバ側と同じ動作は本来不要
クライアント側がサーバ側のバグを悪用した攻撃に備えていないのは別にバグではない
メールサーバのフィルタリングがぶっ壊れててウイルスを受信してしまっても
メールソフト側にバグがあることにはならないのと似たようなもん 87仕様書無しさん2014/06/30(月) 03:20:02.24
>>86:689
> 正しく応答しているだけ
返答不能な要求に正しい応答なんてないしましてやメモリ漏らして良いなんて仕様は存在しない。
> クライアント側はサーバ側と違い正式な鍵がなければ攻撃者は接続を維持できない
正式な鍵(正確には証明書)は必ずしも必要ではないし、正式な証明書を用意できるケースが有る。
攻撃側のサーバは予め提示可能なタイプの証明書を持っていないという応答を返すことも出来るし、
自身の正しい証明書を用意できるサーバを攻撃に使用すれば何の問題もなく攻撃に入ることが出来る。
例えば、広告の画像URLを攻撃用に取得したドメイン+証明書+攻撃用擬似TLSサーバにしておけば、
OpenSSLを使って接続してくるWebブラウザに正しい証明書の組み合わせで攻撃を行う事が可能になる。
> クライアント側がサーバ側のバグを悪用した攻撃に備えていないのは別にバグではない
攻撃を被弾するリスクが減少するだけでバグはバグ。
実際にそれが理由でクライアントとしてOpenSSLを使うソフトウェアもアップデートを行った。
そもそも、セキュリティを司るモジュールが認証済みの相手ならば攻撃されても良いなんてポリシーなわけがない。
いい加減あきらめろよ 88仕様書無しさん2014/07/01(火) 19:19:13.55
701 ：名無しさん＠お腹いっぱい。：2014/06/30(月) 22:57:35.98 ID:AXin1lzd
>>692
>返答不能な要求に正しい応答なんてないしましてやメモリ漏らして良いなんて仕様は存在しない。
良いも悪いも、そもそもサーバ側のバグを悪用してクライアント側の
メモリを読まれるような状況は想定されていないし想定するのはおかしい
本来なら接続が維持できずメモリを読み出せずに終わるんだからね
サーバ側のバグを悪用してクライアント側のメモリが盗まれることを想定し
あらかじめクライアント側でそれに備えるということは、サーバ側のバグを
認知して放置していることに他ならず話として矛盾している
>広告の画像URLを攻撃用に取得したドメイン+証明書+攻撃用擬似TLSサーバにしておけば、
>OpenSSLを使って接続してくるWebブラウザに正しい証明書の組み合わせで攻撃を行う事が可能になる。
サーバ側のバグがなければ不可能
しかもWebブラウザとSimejiは関係ない
>実際にそれが理由でクライアントとしてOpenSSLを使うソフトウェアもアップデートを行った。
サーバ側にバグがあったからだろｗ
上に挙げた例で言えば、メールサーバがフィルタするはずの
ウイルスを送ってくるバグがあったから
メールソフト側で弾かざるを得なくなったようなもんで
それまで実装されていなかったのは別にクライアント側のバグではない 89仕様書無しさん2014/07/01(火) 19:19:42.66
701 ：名無しさん＠お腹いっぱい。：2014/06/30(月) 22:57:35.98 ID:AXin1lzd
>>692
>返答不能な要求に正しい応答なんてないしましてやメモリ漏らして良いなんて仕様は存在しない。
良いも悪いも、そもそもサーバ側のバグを悪用してクライアント側の
メモリを読まれるような状況は想定されていないし想定するのはおかしい
本来なら接続が維持できずメモリを読み出せずに終わるんだからね
サーバ側のバグを悪用してクライアント側のメモリが盗まれることを想定し
あらかじめクライアント側でそれに備えるということは、サーバ側のバグを
認知して放置していることに他ならず話として矛盾している
>広告の画像URLを攻撃用に取得したドメイン+証明書+攻撃用擬似TLSサーバにしておけば、
>OpenSSLを使って接続してくるWebブラウザに正しい証明書の組み合わせで攻撃を行う事が可能になる。
サーバ側のバグがなければ不可能
しかもWebブラウザとSimejiは関係ない
>実際にそれが理由でクライアントとしてOpenSSLを使うソフトウェアもアップデートを行った。
サーバ側にバグがあったからだろｗ
上に挙げた例で言えば、メールサーバがフィルタするはずの
ウイルスを送ってくるバグがあったから
メールソフト側で弾かざるを得なくなったようなもんで
それまで実装されていなかったのは別にクライアント側のバグではない 90仕様書無しさん2014/07/01(火) 19:31:05.72
>>88
> サーバ側のバグを悪用して
だからサーバもクライアントもどちらでも起きるバグだって何回言えば分かるんだよ
> 想定されていないし想定するのはおかしい
Webブラウザはセキュリティを意識する必要はないとでも言いたげだな
> サーバ側のバグがなければ不可能
クライアントにも全く同じバグが有るんだから不可能
> しかもWebブラウザとSimejiは関係ない
おまえがソース見れるから全部のバグやバックドア見つけれるなんて超アホなこと言い出したから、
ソースを何十何百と言う人間が見れたにも関わらず年単位で放置されたバグの例を教えただけだよ
> メールサーバがフィルタするはずのウイルスを送ってくるバグ
ちげぇよ。
サーバを相手に攻撃を仕掛けるのはクライアントとして振る舞う攻撃用プログラムで、本来想定されるクライアント用プログラムではないし、
クライアントを相手に攻撃を仕掛けるのはサーバとして振る舞う攻撃用プログラムで、本来想定されるサーバ用プログラムではない。
相手が正しいサーバかどうかをチェックする為のプログラムが、不正なサーバ相手にメモリお漏らしなんて許されるわけねーだろアホ 91仕様書無しさん2014/07/05(土) 08:26:44.87
オープンソースのレビューは
だれも確認してなくても時間が経過すると
OKみたいな不思議な仕組み
92仕様書無しさん2014/07/05(土) 14:44:58.39
不思議でもなんでもない
人的リソースはどこも慢性的に不足してるから
あるかどうかもわからない確認待っていれば何も進まない
93仕様書無しさん2014/09/23(火) 21:38:17.44
この問題、組み込み機器とかの問題もあるしまったく解決してないよね
94仕様書無しさん2014/09/23(火) 21:56:44.89
>>93
古いやつは下手するとサポート切れ扱いで放置(→新しい製品に買い替えろ)なんてことになるのだろうね…。 95仕様書無しさん2016/07/30(土) 21:14:46.65
大阪府三島郡島本町は暴力とイジメの
暴力とイジメのブラックタウンなの？
96仕様書無しさん2017/06/11(日) 13:36:30.64
そうだよ
暴力団やヤクザばかりなのに警察は全く動かない
97仕様書無しさん2017/12/29(金) 21:57:51.45
誰でも簡単にパソコン1台で稼げる方法など
参考までに、
⇒ 『宮本のゴウリエセレレ』 というブログで見ることができるらしいです。
グーグル検索⇒『宮本のゴウリエセレレ』
JQ1HXG0THC
ブックマークへ