Overbuffを見れば自分が平均程度のパフォーマンスを出せているかどうかはわかる。ただこの数字はブロンズ～グラマスまですべての数字の平均なので必ずしも参考になるとは限らないが、戦績を公開しているアカウントのみが対象で、レートが低いほど戦績を公開している人が少ないというのが実感であり、それを考慮するとレートが高めの人の情報が多いと考えている。よって平均程度であれば、このレート帯に対してで言うならそこそこ良いパフォーマンスを出せているのではないかと思う。まあ上のレート帯の対戦にブチ込まれたら自分のパフォーマンスは相対的に落ちるから、絶対的な指標にはなりえないことは理解しておく必要がある。

ただし、これからの話はゲーム中に数字を見ながら実感するべき内容なので、あとからOverbuffを見てもあまり意味がないと思われる。

当然の話だが状況が画一ではないので、これから述べる話は絶対的な話ではない。参考程度に。

・ダメージとキルが比例しない

ダメージは十分とっているはずなのにキルが伸びない時は、敵ヒーラーが上手いか味方のフォーカスが合わずに十分なキルがとれていない。

ということはヒーラーを優先してキルするか、フォーカスを合わせれば良い。

キャラにもよるが、一人で一人を殺しきれると考えない方がベター。

これを考えることができるのは、このゲーム特有のファイナルブロウのみがキルにカウントされるわけではないシステムが良い方向に作用している。

・デスが多い

タンク……ラウンド１あたり１０を超えると明らかに多い。６くらいでおさめられるのが理想だが、そのほとんどを味方ヒーラーに依存することになるため、早い段階でヒーラーの力量を見極める必要がある。ヒールが薄い場合は壁を利用し、パックを利用し、生き残りたい。前に出られない場合はヒーラーに手厚くしてもらえるようにお願いするのが良いが、応えてくれる人ばかりではないので、ヒールの有無による各マップの生存方法を研究すること。回復が欲しいと思う時間がある時点でヒールが不足しているか、被弾しすぎなので立ち回りを見直すこと。前線にいる関係上難しいが、味方サポートの射線を常に意識すること。

ダメージ……キル、ダメージ、デス、すべての兼ね合いがあるのでなんとも言えないが、当然デスは少ない方が良い。K/Dが良くても仕事ができているとは限らず、例えばダメージ一人が死んでもヒラタン二人を救えるなら大きな意味がある場合も多いので、数字にこだわらず状況を重視したい。

サポート……０を目指すべき。よっぽどの状況でなければ多少ヒールを捨ててでも生存を目指したいが、死なないことを重視するあまりヒールが届かないのも困りもの。頻繁に死ぬようであれば立ち位置を見直すか、優先的に狙っているフランカーがいるはずなのでピックを変える必要がある。とくにWaveの一番最初に死ぬ場合は立ち位置が間違っている可能性が高い。キャラにもよるがK/Dは３を超えていれば優秀なのではないかと思われる。デスが２桁になってくると明らかに死に過ぎ。

・目標貢献キルが多い

　勘違いしやすい数字。マップにもよるが、基本的に少ない方が良い数字となる。

　ロールや展開によってはまったく増えない数字なので実感できるとは限らないが、この数字が大きいほど接戦になっていると考えられる。

　コントロール……ルール的に状況５分であるので、この数字から傾向を推測するのは困難。

　エスコート（攻撃）……ラウンドあたり５程度ならかなりスムーズに進んでいるはず。多くなるほどペイロードに近寄られすぎている。目標貢献キルが発生している＝車を止められているということなので、もっと前方で食い止められるようにしたい。チョークポイントを理解し、立ち位置を先取りすることを目指せば自然と減ると思われる。

　エスコート（防衛）……防衛になっても多すぎるとギリギリの戦いをしていることになるので、やはり少ない方が良い。車を盾として利用しながら戦いたいのはお互い様だが、攻撃側には回復できるというメリットがあるので、近寄られる前に止められる方が当然楽に試合を運べる。攻撃時にも言えることだが、車の位置によってチョークポイントが変化することをよく理解したい。

　アサルト（攻撃）……Aは敵がチョークポイントを守る高台にいるため目標貢献キルになりにくいが、Bはだいたいポイント上あるいはポイントに即座に入れる地点で守ることになるため、増える傾向にある。Aで２～３、Bで５程度であればかなりすんなり取れているはずだ。目標貢献キルとデスが多い（同程度）場合は一人で突出している可能性が高いので立ち回りを見直すこと。デスばかり多い場合は言うまでもない。

　アサルト（防衛）……先述の通りAの防衛においては基本的にポイントより前で止めているはずなので、増えないことが理想。増えるようであれば、チョークポイントを簡単に抜けられているということなので、立ち位置かピックを見直したい。Bにおいても増え続けているようであれば、相手の攻め筋を読み切れていないと言える。ただ、ポイントを踏まれると音がなるため、数字よりもその音を気にした方が良いと思われる。

　ハイブリッド（攻・防）……King‘s Row、EichenwaldeとNumbaniで事情が異なる。前者は基本的にアサルトAポイントと同じ考え方で、後者はBポイントの考え方になる。ポイントを取ったあとはペイロードと同じ。

・回復量について

ゼニヤッタ以外を想定して話を進める。

１Waveあたり１０００回復しているとかなり多いのではないかと思われる。競り勝てたら当然それで良いのだが、負けているようならば前線の被弾が多すぎる可能性が高い。スムーズに勝てた場合はヒール量は６００程度のことが多い。

ほとんどが味方の動向に依存する数字なので、その多少によって働きを測ることはできないが、１Wave目で競り負けてヒール量が５００を切っているようなら全くヒールできていないだろう。ヒールできていない理由は、あなたが味方に意識を割いていないか、さっさと死んでしまったかのどちらかになると思う。前者ならばそもそもロールへの理解度が低いし、後者なら立ち位置が悪かったと言える。

盾の向こうに毎回つっこんでいくハルトがいるんですという場合もあると思うが、そういう手合いはさっさと諦めて退場時間を増やしてもらった方が良い展開になりやすい。助けるべき人を助けていれば突破できるし、ヒール量的にも５００を割り込むことはないはずだ。

Permalink | 記事への反応(0) | 11:07

2019-02-19

■anond:20190219193134

買い物するだけならわざわざ人間様が移動するよりも、ドローンに期待すべきではありませんか??

ググると近頃のドローンはもうペイロードが5kg以上になっているらしいです。

5kgもあれば結構なものが運べますよね!?

たかが買い物で1t以上ある自動車を持ち出すとか、そろそろ大げさすぎる気がするのですが……。

1tですよ!?人間の体重が50kgあるとして20人分です。

1人の人間の買い物を代理するなら50kg以下じゃないと駄目でしょう、究極的にはですが……。

Permalink | 記事への反応(1) | 21:04

2019-02-14

■anond:20190214095533

現在のDNS ブロッキングに関しては「パケットを見ない=通信の内容を見ない」で成立できる

パケットフィルタリングではない、ペイロードを見ない、と言いたいの？

パケットを見ないって、あり得ないよね？

Permalink | 記事への反応(1) | 10:08

2018-04-26

■anond:20180426170858

性善説だったり、DNSのように古いプロトコルは再定義してHTTP/2あたりに乗っけてあげるのがよいのかも。

ペイロードのサイズに限界のあるUDPがどれだけの抜け穴とDDoSの元凶になっているかを考えたら、ねえ

Permalink | 記事への反応(1) | 18:57

2016-11-09

■PaladinsのKinessaが弱すぎる

1.役割が少なすぎる

　多くのDamageは同時にFlank的な側面を持っているしまたAOEにより範囲攻撃を可能としている。しかしKinessaはほぼ直線的な攻撃しかできない為その役割は固定砲台＋αで終わってしまい応用力に欠ける。応用力に欠けるとはすなわち活躍できない局面が多く存在するということであり結果として4vs5とも言える状態を定期的に引き起こす。

2.守りが弱い

　スナイパーという性質上戦場に射線が通っておりかつ距離が離れている位置に潜むことが多くなる。その場合位置はある程度相手のFlankに把握されてしまうため簡単に回り込まれKillを取られてしまう。また接近戦においてKinessaの戦闘力は著しく低いため相手はKinessaの撃破後ほぼ無傷のまま自陣の裏側への侵入を完了する。これがVictorやCassieなどであれば同じ状況でも相手の体力を大幅に減らし撤退か低体力での特攻の二択を迫ることが出来る。

3.足並みを合わせられない

　狙撃に適した位置を移動していくためペイロードの位置によっては遠すぎて死角の多い場所に立つ事になったり逆に前に出すぎて相手からの攻撃に晒されすぎることも多い。そのようなときに味方のTankはKinessaを守りきる事や援護を期待することが難しくなる。

とにかくKinessaは弱い。選ばれた段階で試合の負けが決まるとすら言える。その事を分かっているのか多くのまともなプレイヤーはKinessaを選ばない。そして一部のお間抜けなプレイヤーはチームに既にDamageが2人いる状態でも平気でKinessaを選ぶ。このゲームにおいてDamageは1人で十分だ。とはいえDragozなどのFlank的側面が非常に強いDamageがいる場合はもう1人をチームに加えることが可能になる。しかし3人はありえない。なぜならチームにはTank2人とSupport1人が必要だから。少なくともDamgeが2人いるなら残りはTank1人Support1人本職のFlank1人となるべきだろう。そこでKinessaを選ぶプレイヤーがいる。いるのだ。そうなると試合は本当に地獄を見る。あっという間に敗北して終わってしまうのがせめてもの救いだろうか。本当にKinessaは弱い。Kinessaを使うプレイヤーの頭も弱い。

Permalink | 記事への反応(0) | 22:32

2016-11-01

■http://anond.hatelabo.jp/20161031204638

某合衆国の宇宙開発関連部局の人間が、非公式に我が国の外洋沖合に軌道エレベーターを設置したいと打診してきたのだが、予定地は本来理想とされる赤道周辺から緯度が外れ過ぎていてケーブル強度と張力の関係から底部を地上に固定することが難しいため、下端が空中に浮かんだ極超音速スカイフック構造を採用する計画になっている。

軌道エレベーターは本来、地上と軌道上との移動コストを縮めるためのものなのに、外洋の、しかも大気圏よりも高い位置に地上側ステーションを設置する超音速スカイフックでは経済効果が見込めず、我が国としては反対の意思を伝えたのだが、彼の国の機関は聞く耳をもたず、我が国政府の頭越しに国内の某旧財閥系企業と直接交渉を進めている。

日銀や経団連など経済界の主だった面々もはじめは反対していたのだが、某旧財閥系企業が提示したエレベーター外郭施設の建設・整備による経済効果の試算がひどく気に入ったらしく、今ではエレベーターの話ばかりしている。

地上側ステーションを空中に建設した場合、地上からステーションまで別途ロケット等での輸送が必要なので、運用費用も普通の軌道エレベーターに比べて多く掛かるし、そもそもロケットで軌道まで上がればいいじゃないかと思っている。

ロケットなら打ち上げも再突入も任意の地点で可能なため輸送量拡大も余裕であるが、軌道エレベーターはペイロードにも限界があるため将来的な苦しさがある。

（最近は大量輸送に向いている設計も提案されているが、まだまだ実用面でのハードルは高い）

このままでは我が国が次世代宇宙開発計画から蚊帳の外に置かれてしまいそうで、不安ばかりが募る。

Permalink | 記事への反応(0) | 22:22

2016-05-17

■はてブでオスプレイのデマを飛ばすな

はてブにはまともな人が多いと思っていたが、オスプレイに関する限り、とんでもないデマを飛ばす人が圧倒的に多い。関東大震災のときの「朝鮮人が……」というデマにも匹敵する、とんでもないデマだ。

本日の読売新聞に、熊本地震の際、自衛隊のヘリコプター CH-47 が整備中で飛ばなかった、という記事があった。

　　http://www.yomiuri.co.jp/national/20160515-OYT1T50135.html

熊本地震発生の約１週間前、ＣＨ４７の点検で翼を回転させる部分近くに異常が見つかり、飛行を続けると事故が起こる恐れのあることが判明。自衛隊は全機の運用を中止して一斉点検を実施した。熊本地震後、自衛隊はＣＨ４７の出動を決めたが、多くが点検中で、被災地での救助・救援活動には、１０機程度しか稼働できなかったという。

これが、はてブのホッテントリに入った。

　　http://b.hatena.ne.jp/entry/www.yomiuri.co.jp/national/20160515-OYT1T50135.html

はてなーの多くは、「自衛隊ヘリが使えなかったのか。これでオスプレイの有用性がわかっただろう。やっぱりオスプレイは必要なんだ」と思っているようだ。だが、これは勘違いだ。

一部のブコメ（blueboy）でも指摘されているが、上記のネット記事は簡略版にすぎない。元の記事にはもっと情報がある。特に重要な部分を引用しよう。

自衛隊のヘリは、維持整備の予算が不足し、稼働率が低下傾向にある。
（読売新聞朝刊 2016/05/16 ）

つまり、金がないから、維持整備がろくにできなくて、そのせいで、まともな稼働率を上げられないのだ。「翼を回転させる部分近くに異常が見つかり」というのも、1986年ごろから導入されたポンコツの機体には十分な点検や修理が必要なのに、その点検や修理が不十分だから、ポンコツ状態が軽微なうちに発見・修理ができなかったわけだ。

だから、この根源は、自衛隊に金がないことだ。必要な維持整備費さえもないありさまだ。そして、自衛隊がこれほどにもスカンピンになったのは、オスプレイという超高額機を購入するせいだろう。オスプレイを買わなければ、その金で維持整備の費用をまかなえたのに。

つまり、オスプレイを購入するせいで、既存のヘリコプターの大半が使いものにならなくなってしまったわけだ。

さらに、本当ならば、ポンコツの CH-47 や、もっと古くて退役した CH-46 の代替機を購入することが必要だ。それは、AW101 （日本名 MCH-101 ）というかなり新しい機体だ。

　　http://bit.ly/1Xf7sVK 　　（ Wikipedia ）

この機体ならば、21億円^*で買えるので、オスプレイ^**のほぼ 10分の１の価格で済む。オスプレイを少数だけ配備するよりも、AW101 をその 10倍の数で配備する方がずっと有益なのだ。

　　　　^*　21億円という数字は、210億円と誤記していたので、訂正しました。

　　　　^**　ただし、周辺装備込みの調達価格。周辺装備は、減らせる。

　　　*　　　*　　　*　　　*　　　*　　　*　　　*　　　*　　　*

さらに、大切なことがある。熊本の地震で、オスプレイが役立ったという話は、ただのデマだということだ。そのことは、検索すれば、すぐにわかる。理由を知りたければ、下記からわかる。

　　google:オスプレイ　必要なかった

簡単に言うと、こうだ。

(1) オスプレイが運搬したのは、18日の午後になってからで、遅すぎた。

(2) そのときにはすでに道路が開通して、トラックが物資を運搬した。

(3) オスプレイが運んだのは、最後にオスプレイのために取っておいた少量の１回分だけ。

(4) オスプレイが垂直離陸するためには、重たい物資は運べないので、重たい飲料水などは積み込めず、軽量の毛布などを運んだだけだった。

(5) 自衛隊の基地から出た自衛隊ヘリが荷物を軽空母に下ろした。そこで荷物をオスプレイに積み替えて、オスプレイが荷物を軽空母から被災地に運んだ。

(6) しかし、自衛隊のヘリが直接被災地に運べば、途中で積み替えることもなく、１回で済んだのだ。なのに、オスプレイに運んでもらうために、わざわざ積み替えた。これは余計な手間と時間がかかるだけで、まったくの無駄だった。

要するに、オスプレイが運んだ荷物は、ほとんど無意味のものだけだった。単に「オスプレイは役立ちますよ」という宣伝のために、オスプレイを使っただけだった。そして国民の大部分は、そのペテン行為にだまされて、役立たずに終わったオスプレイを「すごく役に立つ」と思い込んだ。こうして、まんまとだまされた。はてなーもだまされて、ブコメにオスプレイ礼賛を書き込んだ。

しかし、そのせいで、ヘリコプターはポンコツの CH-47 ばかりとなり、維持整備費もろくに出ないありさまだ。本来ならば AW101 を大量配備できるはずだったのに、それもできず、やたらと高価格のオスプレイを少数だけ配備することになった。本年度はたったの４機だけだ。

　　http://www.sankei.com/politics/news/151212/plt1512120010-n1.html

つまり、せっかくのヘリ空母のひゅうがなどを配備しても、それに搭載するためのヘリコプターはろくにない、というありさまだ。11機搭載できるヘリ空母に、４機しか搭載していない。うち１機が MCH-101 だ。

　　http://bit.ly/1XuyNUw

ヘリのないヘリ空母。ひどい無駄だ。戦艦大和の再来とも言えるほどの無駄。オスプレイの購入をやめて、 AW101（MCH-101）を大量配備していれば、こういう馬鹿げたことにはならなかったのに。

　──────────────────────────────

※　追記

ものぐさな人が多いから、ちょっとソースを加筆しておく。

　　17日に地上ルート開通　（産経新聞）

　　南ルートは17日に開通。北ルートは18日正午に開通　（NHK）

　　オスプレイの輸送量は少しだけ　（以前のホッテントリ）

　　オスプレイの輸送量はもっと少しだけ　（引用集）

オスプレイは、４機が６日間にわたって運搬したが、それは働いているフリをしているだけ。実際には普通のヘリの１機が３～４回ほど運搬すれば済む分量を、小分けにして、何度も少しずつ運んだだけだ。

（仮に、「働いているフリをした」のでなく、実際に最大限に働いていたのだとすれば、オスプレイの積載可能量は、普通のヘリの１～２割程度しかなかったことになる。無能。精一杯まじめに働いても、他人の１～２割程度しか仕事をしないのだから、無能。つまり、だましたか、無能か、どちらかだ。私は「だました」のが真相だと思うが。）

ブコメに返信しておく。

＞　必要なのは中段の1-6について増田なりの根拠を示すこと。

それをやると、ものすごく長くなるんだよ。本記事の数倍の長さになる。とても増田に書くような話じゃない。

そもそも、私が書かなくても、Google 検索結果のページに同趣旨のことが書いてあるんだから、いちいち私が書く必要はないだろ。リンク先をクリックするだけでわかるんだから、クリックする手間を惜しまないでくれ。そのくらいの手間をものぐさがらないでくれ。

あと、(1)～(3) の事実に対しては、その短文を検索語にしてググるだけでも、該当のページがいくつか見つかる。

(4)～(6)については、下に記してある YouTube の動画（ひゅうが）からわかる。

＞　「google:オスプレイ　必要なかった」をソースにしてるのは流石に笑うところだよね

これはソースではない。ソースをいちいち並べるのは面倒臭いから、ソースを探す方法を示しただけだ。上で検索結果の一覧が出るが、そのあと、各ページを読むと、各ページにソースがたくさん見つかる。そういうこと。つまり、ソースを示しているのではなく、ソースの探し方を示している。

あとね。ソースソースとうるさい人がいるが、ここ一カ月間のマスコミのニュースがソースだ。マスコミの情報ぐらい、自分で探せ。ものぐさがるな。ちょっとググれば、すぐに見つかる。（専門知識と勘違いしていないか？　時事ネタだぞ。）

たとえば、すぐに思いつくが、これを見ろ。

　　google:熊本　不通　開通

＞　金がないのは人件費と装備類がどんどん高くなってるのにいつまでも 1%縛りしてるからでしょ。

オスプレイを買う金なら 3900億円もあるよ。この金を使うべし、という趣旨。ヘリを買う金なら、たっぷりあるんだ。

＞　オスプレイが完成するずっと前からマトモな整備費も代替機も来なかったというのに、時系列が無茶苦茶すぎる。

「オスプレイを買わない。かわりに整備費を増やす」という方針を決めておけば、数年前から、整備費を増やすことができた。そうすれば、今回の問題も発生しなかったはずだ。

オスプレイを買うのは昨年度からだが、方針の決定は数年前からできた。「オスプレイを買おう」と決めたころに、方針変更はできた。

なお、オスプレイの購入費用は、2015年度の予算で支出されている。すでに金は出されてているんだよ。金を出したのは、2015年度。実際の納入は、2018年度。

　　http://www.sankei.com/politics/news/151212/plt1512120010-n1.html

　　http://headlines.yahoo.co.jp/hl?a=20160323-00010001-saga-l41

時系列を正しく認識すべき。「オスプレイはまだ納入されていないから、まだ金も出していない」と思うのは、間違いだと理解すべき。

＞　自衛隊機が軽空母まで運んで積み替えて運んだとか、それこそデマじゃん

ソースを見ろ。検索結果からさらに探せば、次のページが見つかる。

　　https://youtu.be/IyPh2v2enKs

これは「オスプレイの救援物資輸送護衛艦ひゅうが→南阿蘇村」という動画だ。これを見てから文句を言ってくれ。

あと、いちいち私がソースを見せるまでもない。きみがちょっとググるだけでも、ソースはいっぱい見つかるはずだ。

　　google:オスプレイ　ひゅうが

私の示した事実に対して、「ソースがない」と文句を言う前に、自分でちょっとググるぐらいの手間をかけろ。ググる方法がわからないなら、「ググり方を教えくれ」と頼めばいい。

＞　軽空母で積み替えただの、飲料水は重くて運べないだの、お前こそデマ飛ばしてんじゃねーよクソが。

これもすぐ上の動画を見ればわかる。ひゅうがで積み替えている。あと、積み替えが馬鹿馬鹿しいということは、私だけでなく、他の人も指摘している。

「飲料水は重くて運べない」というのはデマではない。オスプレイの最大積載能力を発揮したときには、滑走モードで離陸できるだけで、ヘリモードでは離陸できない。ひゅうがはヘリ空母としての運用が前提だから、オスプレイがひゅうがで勝手に滑走するわけには行かない。

ただ、「飲料水は重くて運べない」というのは、少し表現がまずかった。「まったく運べない」ということはなかった。少しぐらいなら運べた。ま、当り前だが。実際、少しは運んでいる。その意味では、表現は適切でなかった。この点は、お詫びします。（ただし趣旨は間違っていない。搭載燃料などの重量を考えると、積み荷の量はあまり増やせない。）

＞　MCH-101は海上型で調達価格は一機55億。ちなみに三発で稼働率・評判ともによろしくない。

価格は、その通りだけど、それは国内生産だからだろ。輸入したら、MCH-101 でなく AW101 なんだから、 21億円だ。Wikipedia にはその価格が書いてある。一方、オスプレイは国内生産にはならない。なのに、オスプレイを輸入価格で評価して、AW101 を国内生産価格で評価するのは、変だろ。AW101 も輸入価格で評価しろよ。

稼働率が低いのも、国内生産（ノックダウン生産）だからだよ。故障したときの部品が足りなくて、まともに稼働していないありさまだ。

　　http://blog.goo.ne.jp/harunakurama/e/274548f5fb079aac8330d1bc546fbed8

この問題も、国産をやめて、輸入に切り替えることで解決する。（ノックダウンでなく、ライセンス生産でもいい。ただしコストは上昇する。）

なお、ノックダウンが駄目なのは、製造責任が日本のヘリ会社になるからだ。元のヘリ会社が製造責任をもてば、故障したときの部品も入手が楽になる。

＞　人をまともかそうじゃないかって

「まともじゃない」とは言っていないだろ。「まともだ」と言っているだけだ。「あの人はまともな人だ」と褒めるのは、悪いことなのか？　私が人を「まともじゃない」と書いているかのようにブコメするのは、やめてくれ。

【参考情報】

積載量についてググってみたら、面白い話が見つかったので、紹介しておく。

空虚重量
は、通常、航空機の重量の定義の一つとして用いられる、機体構造・エンジン・固定装備などの合計重量のこと。
乗員、ペイロード、燃料を含めない機体自体の自重。
潤滑油、作動油、冷却水、固定バラストなどは含む。

MV22はVTOLだと燃料5ｔと貨物3ｔで行動半径600ｋｍだなｗ　
チヌークはJAなら燃料6ｔと貨物5ｔ積んで行動半径500ｋｍとｗ　
だがチヌークは長距離任務でなけりゃ貨物8ｔや機外懸架10ｔで兵站輸送も可能ｗ　
逆に片道200ｋｍ遠くにかつ倍速で飛べる利点の使い所が実は結構謎なのは秘密ｗ　

出典：http://echo.2ch.net/test/read.cgi/army/1441606513/585-n

Permalink | 記事への反応(7) | 00:30

2015-11-12

■参考訳：拡散したJavaデシリアル化の脆弱性についてApache Commonsの声明

原文：https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread

原題：Apache Commons statement to widespread Java object de-serialisation vulnerability

翻訳日：2015年 11月12日（午後にタイトルを日本語にしました）

－－－－

2015年 11月1日火曜日

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 に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。