  |
はてなキーワード: 通信プロトコルとは
ヒトをヒトたらしめているのはその “脳の大きさ” に他ならないが、その肥大化した脳は大きくなればなるほど「情報を求め、常にインプットされる情報が多くなるように行動する」というロジックを脳の基本的な機能として組み込んでいった。
そのロジックに従い情報を吸収し続けた結果として脳が肥大化したのか、大きくなったからこそより情報を欲するようになったのかはニワトリ・タマゴと同種の話であろうが、いつの頃からかヒトはこの巨大な脳のために常に情報をインプットし続けるよう行動するという習性が備わった。
そう考えると今、皆がひたすらにスマートホンに顔をうずめている光景も納得がいく。現時点で最も効率良く、場所や時間に縛られずに情報を得られる “窓” がスマートホンだからだ。
コミュニケーション欲求も、とどのつまりは自分の社会的位置情報の取得、あるいは周囲の “ノード” との相関関係の確認作業である。他者との “共感” のやりとりにしても、「分かり合う、分かり合えるかどうか」というのはつまりは情報通信プロトコルの動作確認的な意味合いが強い。相手と“会話”という名の情報通信が可能かどうか。他者との関係性は情報流入のためのインフラそのものであり、インフラの出来によって得られる情報量に大きく差がでるのだ。
ここにおいて情報の中身や質は関係がない。常にインプットし続けることこそが目的であり、それこそが脳の “要求” なのだ。脳への情報インプット効率を高めるためにヒトは “インターネット” を構築しそこを覗くための窓である “スマートホン” を作った。すべてはヒトの脳が欲したものだ。
スマートホンに顔をうずめ常に何かしらの情報を追っている方が、よりヒトの脳が求める要求に忠実なのであり、“より人間らしい” のだ。スマートホンなどに抵抗を感じ「おかしい」と声高に叫んでいるような人間は、古い習慣に囚われ脳の要求を無視する「人間らしくない」生き物だ。ヒトであるならば素直に脳の要求に従い、貪欲に情報を貪り続けなければならない。
ヒトはもうスマートホンを捨てられない。情報によって強化された脳がより強く情報を求め、もうそれを抑制することはできない。まるでクスリによって手に入れたチカラに依存し飲み込まれていった鉄雄のように、ヒトも制御できない情報流入で溺れ壊れていく。その過程の真っ只中に我々はいる。mn3
原文：https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題：Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日：2015年11月12日（午後にタイトルを日本語にしました）
－－－－
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者：Bernd Eckenfels（コミッター）, Gary Gregory（Apache Commons副責任者）
AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときのセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクト・シリアライゼーション（訳注：seriarization／シリアル化／直列化＝ネットワークで送受信できるようにメモリ上のオブジェクトデータをバイト列で吐き出すこと。シリアル化されたJava オブジェクトはRMIなどのリモート通信プロトコルで使用される。）を使用する際に任意のJava関数の実行や操作されたバイトコードの挿入さえもを行う方法の説明です。
Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereやJBoss、Jenkins、WebLogic、OpenNMSといった様々な製品を調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオを記述しています。
両者の調査活動は、開発者がJavaのオブジェクト・シリアライゼーションに信頼を置きすぎていることを示しています。認証前のシリアル化されていないオブジェクトにも。
Javaにおけるオブジェクトのデシリアライゼーション（訳注：de-serialization／非直列化＝ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと）が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効なオブジェクトツリーだけを保証しています。
不幸にも、型のチェックが起こるまでの間に既にプラットホームのコードが生成されて、重要なロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者のコントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまいます。脆弱性のあるアプリケーションのクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は（ローカルのOSのコマンドを実行するRuntime.exec()の呼び出しを含めて）機能を実行することができます。
これに対する最も良い防御は、信頼されていないピア（通信相手）とは複雑なシリアル化プロトコルを使うことを避けることです。ホワイトリストのアプローチ http://www.ibm.com/developerworks/library/se-lookahead/ を実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができます。しかしながら、これは常にできることではなく、フレームワークやアプリケーションサーバがエンドポイントを提供しているような時にはできません。簡単な修正方法がなく、アプリケーションはクライアント・サーバプロトコルとアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。
これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムや Springフレームワーク、 Apache Commons コレクションからのクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン）を見つけています(訳注：provided)。これはこの脆弱性のエクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日、攻撃者が簡単に得られるチェーンです。
(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c
この脆弱性のために利用される(訳注：blamed)ことができない確かな機能を実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的に修正していくことが要求されます。モグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。
Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題に対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています。議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能を提供するかどうかです。
これには前例があります。Oracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャーが定義されているとデシリアライゼーションを拒否します。
これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできます。Apache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャーの存在と独立したこの機能を無効化することを計画しています。
しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンの Apache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。
このブログポストのレビューのために Gabriel Lawrence に感謝したいと思います。
Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラスを提供する Java ライブラリです。InvokerTransformer はコレクションにあるオブジェクトを（特にリフレクション呼び出しを通じてメソッドを呼び出すことで）変換するために使うことができる Transformer ファンクションインターフェースの実装の一つです。
一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]
コメント：
Oracle は Weblogic にセキュリティアラートを発行しています：
真夜中に眠れないほど精神的にめいってしまったから書いた。久方振りに「どうしようもない」ほどの体調不良を経験してるが…涙も治そうという気力も出ないことに危機感を感じてる。本音しか書けなくなってしまったよ
…TMくん（ @tm2501 ）のはてブや発言を読んでいると痛々しいと思うんだが、いわゆる「イタイ人」ではないんだよなーと思ってて、色々考えた結果「精神面リストカッター」というあたりで腑に落ちた。彼の魂はどうすると救われるかなと思ったりする。
一応、振られたから返しておきます。「精神的リストカッター」ってなんぞですか？
あ、言葉自体は私の造語なので…。「肉体ではなく精神（ココロ）に対し自傷行為を繰り返す人」くらいの解釈でおねがいします。ちなみにTMくんに自覚があるかどうかは関係ない。外野から見てそう見えるって話なので。
小学校でたときには少なからず、自覚があったので否定はしません。（詳しくは今日の朝に投稿した記事で）それは歪んだ家庭環境ゆえに仕方ないものだと思ってます。気がついたときに僕が病まずに努力し続ける精神を獲得するためにはこれ以外の方法が当時はなかったと
あ、その行為自体は否定するつもりはないのです。あんまりいい意味に使われない言葉ではあるので申し訳ない。…どっちかというと、今のTMくんがどういう方向に進みたいのか、永遠にリスカし続けることをよしとするのかみたいなのが見えてこないなーと思って。
そこで望みが叶えば、ある種真人間になれるチャンスはあると思うのですが…自分の現状から言えば、劣化版有村悠みたいな末路しか見えないのは認めますね。彼よかコミュ力・社会性はあるが、才能も知識もない。行くも引くも地獄になるのは確かに目に見える話ですね
真人間じゃないとという考えが、凝り固まってるなあと思います。バイリンガルを目指せばいいだけなんだけどね、これって。別にどれか1つのコミュ世界だけじゃないわけだし。それに、才能や知識なんかなくたって、生きていける世界は多々あるんですよ。
言われてみると、昼と夜の顔（公私）を両方ともをちゃんと作ろうとすると、どうしてもひとつの顔につながるようなルートを求めてしまうのがダメなのかもしれませんね。才能や知識のいらぬ世界で大多数の人は生きていくはずだが、それを説明する言葉を僕はもってない
なんとなくだけどオンリーワンでNo.1以外は全部ダメ！思考が見え隠れしてるなあと思います。合わせ技で1本！もありなんだよとかそういう風に考えられるといいかなあと。あと、公私は無理に1つにしなくていいと思う、というのが私自身の経験則。
「オンリーワンでNo.1以外は全部ダメ！思考」真に戦うべきはこの思考なんですよねぇ…。これのおかげでたった一人でブログを大きく出来たけど、これのせいで二つの道を緩やかに成立させることが手抜きに感じてしまう。どちらか一本をすごく真面目にしてしまう
青二才の敵は青二才自身の自意識。 ここに気付いたのはエライ。 あと一歩だ。頑張ろう。
オタクのコミュニケーションは手軽に深いコミュニケーション体験を得られて、麻薬的な快感を味わえてしまうんですよね。それをうっかり10代前半とか半ばに覚えると、なまじ味わってしまっただけに、この感覚を味合わえないコミュニケーションを異様に軽視しだすと思います。オタクのコミュ障の原点は多分ここなんだと思う。、刺激が強いコミュニケーションを求め続けた結果がそれかも……という事で次なる仮説を考えておりますｗそれぞれ味わいは違うけどおいしい、って理解ができればなんとかなるとも思うんですが、ジャンキーなヲタコミュにハマると難しいかもですねぇ。
無分別にオタクな用語をバラまいた結果、それまで築けていた間柄が傷つき、ボロボロになっていく過程こそが、コミュ障への過程そのものなのではないか。まさにどこかのヤマアラシのジレンマではないか。さて。この段階で分別があり、それまで使ってたコミュニケーションも手放さなければ、おそらくコミュ障の症状は軽度で済むと思う。問題は「闇に呑まれよ」ではないが、なんとかしてこのジャンキーな快感を味わえるコミュ方を駆使したい誘惑に抗えなかった人だ。当人は、ただ刺激の強いコミュニケーションをしたいだけなんだけど、周囲から見たら突然コミュニケーションのプロトコルが変わった人は一般的に「奇人」と言われる。親や友人に奇人扱いされるようになったら、いよいよオタクのコミュニティにしか居場所がなくなる。距離感がおかしくなるのは、自分の通信プロトコルが変わった自覚なしに、相手に通じない、刺激的なプロトコルを発し続けた結果なのか。通じればコミュが成立するけど、通じないコミュニケーションはひたすらノイズでうるさいだけだ。けど 「ぼくのかんがえたさいきょうのプロトコル」 が通じないことは二重の苛立ちを生む（素晴らしい物が認められない苛立ちと、通じないことそのものへの苛立ち）けど、自分のプロトコルに酔ってるから捨てられず被害が収束しないのか。本来はバカバカしいし投げ捨てるべき物なんだけど。あと、ここまで来ると多分、通常の汎用的なプロトコルが下に見えてしょうがない。だからこれを採択する気はないし、おそらくこれを使ってる連中を見下してる。とすると余計に殻に籠もって、自分だけの歪なプロトコルに益々酔いしれていくのか。うわあ。本来は相手に通じてナンボのプロトコルなのに、どんどん自分にしか使えない役に立たないプロトコルに入れ込んでいくアンビヴァレンツ。しかも翻訳すら許さない（翻訳はこの役に立たないゴミにあるはずのない品位を貶めることになるため）からゴミ加減が益々ｋｓｋするだけなのに余計に…うわあ。あとはこのサイクルが行くところまで行って煮詰まれば、どこに出しても恥ずかしいコミュ障がいっちょ上がってしまうのか。ぐへえ。やばい。開ける気の無かったパンドラの箱を無用に開けた気分だ。しかも希望がないorz。
この話の元は、まぁ案の定実体験なんですが、10代前半のオタ成り立て（罹患したて）の頃が案の定一番酷くて、「自分の日常会話が全てマンガやアニメのセリフで成立できてる」って信じ切ってた頃があったんですよ。だからプロトコルに酔うというのは実体験なんです。オタク人生２５年、もっと早く気付こうよ。ヒントはいっぱいあったし、多分この話は20年前ぐらいの自分でも理解できるよきっと。
自覚があるので読ませてもらいました。私自身汎用的なプロトコルとの上下関係を明確に定義したことはありません。ただ、私の中でこれで勝たなきゃ本当に母親に幼いときから押されていた「そんなこともできない奴」の烙印で一生涯潰され続ける。その絶望と戦ってたら、こうなりました
多分ここに明確な上下関係を見出す人は少ないと思います。快楽に支配されると、快感にならないものは意識すらしないからです。ただ、使い方によっては確かに武器にも杖にもなると思いますが、頼りすぎると自分に跳ね返ってくるだけです。
そこなんですよね。承認欲求が強すぎる状態を僕の基準地点にしてるから話がずれたり、煽り耐性が落ちてしまったりしてる。問題だとは思うのですが、オタク界隈の悩みゆえ明確な言語化・相談ができにくい内容。ゆえにバランスのいい状態でかつ僕の自己同一性が守られる形をもってない。そういう意味じゃ少し違うのかなぁ…と思うのです。まがいなりにも自分の頭と目で作ってきたモノに評価を受け、オタク的な人だけではなく幅広い層からの支持から得た自信なので、それゆえに過信しすぎていた部分が強かった。（成功体験と認識してしまうとそれを修正するのは難しい）
なるほど。あの鋭い舌鋒の台所を垣間見た気分です。でもこれを明確にコントロールできる人はやはりそういないですよ。タイミングの調節だけなら簡単にできるけど、威力とかキレ味のコントロールは強めることにしか大概の人は興味ないでしょうから、強さだけを求めてしまうと思います。成功体験と結びつくと尚更修正は辛いと思います。自分でつかみ取ったもので構築したとなったらなおさらですわ。壊す必要はないけど、見つめ直すことはオススメします。
全くそのとおりです。昔に比べて、「一般的な思考」よりも、先にエッジの効いた青二才節が先に思いつくようになったため、知らぬ間に相手から失言扱いされるケースが増えました。演じ分けとまで言わなくても、「一般的な思考」と並列できる程度には戻したいですねぇ…。最近、悩んでいるのはその力加減なのです。オタクブロガーのままリア充で真人間になるという路線でここ数箇月書いてきていたが、これがどちらからも不評であり、僕自身が疲れはててしまう事に最近気づいてしまったため、力加減の変えどころが分からず、思案していますね。正しい変化とか、更生とかそういう枠組みに入りたいとは思わないが…自分のやっていること、考えていることに無理や限界があるというのはわかる。そういう時の選択肢が欲しいねぇ…自分で作りこんでしまった自我ゆえに、一般的な処方箋を頭ごなしに押し付けられるのは御免だ。適切なモノを選ばないと
「炎上以外成功してないから、他のEXITを見つけられないから困っている」というところまで自覚があるならもう少し。炎上以外の方法で注目を集められる実力を身につけよう
個人的にはオタクのままリア充になって、自分がいる場所の視野を広げてしまいたいなぁ…と最近は考えるようになりました。それゆえ、オタク同士の座談会にわざと女性（ナース親子）を呼んで、ホモソーシャル的な議論にしないような事をしました。
と思ってたら、どうしてこういう小手先に頼ろうとするかな。 その程度の工夫でなんとかなるような悩みならそんなにひねくれたりしないでしょう。 強がらないでもっと自分の抱えてる悩みを真剣に見つめよう
本人がまとめててワロタｗｗｗ http://togetter.com/li/485119
開発終了といってもずいぶん前から更新は止まっていたわけで、明確に開発終了が宣言されただけで公開終了になるわけではない。
しかし FFFTP といえば FTP クライアントの定番なので、ネット上で様々な意見が飛び交っている。それについて思うままに書き散らかしてみる。
みんなが「ホームページ」なるものを持ち始めたころ、ファイルをアップロードするのに使ったなつかしい思い出がある。BlogやWikiのようにオンラインで編集できる時代になったことへの感慨も含むのか。
もちろんFTPがプロトコルとしてセキュアでないことは言うまでもないが、いまだに業務で使わざるを得ないことがある。LAN内の転送なら速度は最強かもしれないし、FTPのミラーサーバは世の中にごまんとある。短絡的に「オワコン」の一言で片付けられる問題ではないだろう。
ほとんどのユーザはお客さん気分であることを再確認し、「FreeBSD への貢献」をたたき込んだ自分とは違う人種だと思った。
もともとFTP以外の通信プロトコルを想定して設計していないだろうから難しいように思う。ただ、ユーザは動いているプログラムの中のことなど考えない。
モチベーションが低下する理由ってたくさんあるなぁと。長続きしているオープンソースプロジェクトはすごい。
ゲームを作りたい C言語の基礎を学ぶ それだけじゃゲームが作れないことが判明
win32apiを学ぶ 多すぎて？状態で挫折
ゲーム作るのはあきらめよう！チートだ！ アセンブリが面倒で挫折
向き不向きってあるよね・・・。もう勉強したくない・・・。
俺には向いてないんだろな。だってwin32apiでGUI作りで投げ出したくなったもん
俺の読んだ本
明快C言語 ダイテルC言語（例題飛ばしたのでほとんど意味なし） やさしいC 独習C
windowsゲームプログラミング（最後のテトリスとブロック崩しが面倒で飛ばした）
独習java（ガベージあたりで挫折） windows32api徹底理解 ホームページ作成の本（名前失念）
アセンブリ言語の教科書（100ページあたりでソースを読み解くのが・・・以下略）
何のために勉強しているかわからなかった・・・たぶんC言語の基礎すら身についてないと思う
じゃあweb関連や初心者用言語（php,ruby,pythonとか）学べばいいじゃんってネットで指摘されたんだけどさ
そうじゃないんだよ問題なのは。ライブラリの使い方がわからないし必要な技術がそれだけじゃないだろうし
今roboformのようなもの作りたいんだけどどうつくったらいいんだろ（guiは無理なのでコンソールで）
perlとかruby,phpで記述して通信プロトコルの勉強すればできるんだと思うんだけど俺にはもう体力が残ってない
あまりにも無駄な遠回りをしてきた。でも願望だけが空回りしてる。ライブラリもごまんとあるうえに通信プロトコルも勉強しないといけないんでしょ。甘えっていわれてもかまわない誰か助けて
