「ペイロード」を含む日記

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