  |
はてなキーワード: WebLogicとは
それも開発したのは俗に言うスーパーハッカーとかスタープログラマとかではなく、当時全く無名だった大学院生。
だから開発の目的だって、勉強のためかお遊びなのかもよくわからない話だったり。
そこに来て、型落ちロースペックPCでも動かせるフリーのUNIXライクOSとなると、今だったら
みたいに冷笑されかねない話だ。
実際リリースされて間もない1990年代後半から2000年前後辺りまでは
「流行の追っかけしか能がない、ワナビーのクソガキ共が使うおもちゃ」
くらいの立ち位置だった。
当時流行っていたネットスラングに類似する煽り方をするなら「アンチMS厨御用達」みたいな感じだろうか。
「そんな事があったんだー」
で終わるくらい、Linuxは誰でも、どこでも使うOSになっているのは御存知の通り。
UNIX系OSで最もメジャーと言うだけではなく、システム開発やサーバ構築でWindowsサーバとともにほぼ必ず選択肢に挙げられるようになって久しい。
更に直近の10年で、気がつけば世界中で使われているスマホの殆どがLinuxベース(Android)になっている。
つまり誕生からの四半世紀で爆発的に発展・普及したというわけだ。
本当にLinuxを使うなんて今どき普通すぎて、特に取り立てて言うことではない。
一方でLinuxよりもずっとフリーUNIXとしての歴史があり、かつては定番だったBSD系なんて、今やAppleのお陰で辛うじて延命している状態なのだから、これまた隔世の感がある。
とはいえ気になるのは、何をどうやったらここまで信じがたい躍進をしたのか？という事情。
ホビー用途とビジネス用途では要求される信頼性のレベルが異なるので、誰かがそこに手を入れないとこのような発展は望めない。
そこでは大企業がきちんと専門家を入れる形で関わるならなお良い。
そうなるとやはり、まずIBMが白羽の矢を立て、次いでGoogleが積極的にコミットするようになった流れが大きいのだろうか。
このうちGoogleは「弊社はオープンソースにフリーライドしているわけではない」アピールや自社サービスのコストダウン、更にはモバイル分野への進出という諸々の目的に好都合だったのだと思う。
何しろ元々IBMはAIXという自社製UNIXを売ってる会社であり、これを用いた各種サーバ構築はお家芸だったわけで。
更にこのAIXにDB2やWebSphereを組み合わせる方式は、2000年代くらいまではエンタープライズアーキテクチャの2大巨頭だった。
(もう1つはSolaris+Oracle+WebLogic)
そんな会社がLinuxに手を出して、一体何の得があるんだ？という話なわけ。
一つ考えられるとすれば、AIXもDB2もWASも買えない貧乏人もとい中小規模の顧客から、せめて構築と運用の手数料だけでも取るためとか？
まあ確かに一時期流行ったLAMP(Linux+Apache+MySQL+PHP)なら、ライセンス料なしでハードも安価なPCサーバになるので、導入のハードルは低い。
というわけでLinuxの草創期を知ってる人間からしたら、今の状況は世の中が変わりすぎなくらい変わったという感覚が強い。
Androidの不具合がスマホのメーカー依存or機種依存だったり、そもそもLinuxのデスクトップ用途が未だに少数派なのは今後も変わらないだろうけど、逆に変わらないのは多分それくらい。
あとUbuntuは嫌い。
２０１９年６月を持ちまして、大学新卒入社後約７年勤務した会社を退職しました。
良い機会なので記録に残したいと思います。
地方国立大学の工学部情報科卒。保有資格は基本情報、応用情報技術者。
日立製作所の子会社としてシステム開発、運用、保守、構築を担う会社。
社員数は２～３０００人。
入社してから運用、構築業務を行い、開発は未経験。担当したシステムの分類は公共系のみ。
基本的には「客先常駐」で、システムが安定稼働に入った段階で別のプロジェクトに参画し、構築を行った。
サーバ構築（オンプレミス）業務としてOS、MWの導入に携わることで、構築に必要な知識を得られた。
ちょっと残念だったのが日立製品（JP1、uCosminexus Application Server）に携わる期間が長かったこと。
他社のAPサーバ（Weblogic、Jboss等）も触れ、インフラ屋さんとしての価値を高めたかった。
力不足ではあったが５年目ごろから小さいチームのリーダになり、進捗管理、顧客調整等を行った。
協力会社のメンバーは全員年上で、コミュニケーションにおいて苦労した部分もあったが、
人に恵まれ、大きな問題なくプロジェクトを遂行できた。若いうちにリーダーを経験できたことはとても良かったと思う。
最終年度で約５６０万。
◆内訳
・基本給 ：２６万
・賞与 ：約６０万（年２回で業績により若干増減あり）
そのため、仕事がないのに残業するという所謂「生活残業」をする人も少なからずいる。
また、最近は働き方改革で定時退社を励行しているため、残業についてはかなり厳しくなっている。
昇給は若干ではあるが、たぶん毎年した。
昇格については、早い人で８年目から主任、１５年目くらいで課長になる。
主任の年収が６００～８００万（残業による）、課長の年収が９００～１０００万。
主任まではある程度の実績とポイント（資格等）があれば誰でもなれる（はず）。
ただ、課長以上になると「上が詰まっている」＆「製作所から下ってくる」ため、相当優秀でない限りはハードルが高いと思う。
劇的に仕事が増えて部＆課が新しく作られれば話は別だが。
プロジェクトに合わせる形になるが、フレックスのため勤務体系が自由。
上述の通り、残業についても働き方改革で定時退社を励行しており、男性の育休取得も推進している。
環境についてはシンクラ端末が一人一台支給され、インターネットがつながる場所であればどこでも仕事ができるという状態。
どこでも仕事ができてしまうため、公私のバランスがとりずらいという方もいるかもしれないが、私にとっては最高でした。
これさえあれば在宅勤務も可能なので、娘が熱を出し保育園に行けないときは重宝した。
また、複数拠点にサテライトオフィスがあり、社員証があれば使用できるため、打合せで移動が多い日はよく利用した。
働きやすい環境作りにはかなり投資されているため、恵まれた環境で仕事ができたと思う。
・残業しないと給料低い。また、担当レベルだと成果を出した人とそうでない人で給与の差がほとんど付かない。
・新しい技術に関する感度が低い。
・意識低い系がそこそこ多い。そしてその人たちは決して辞めない。優秀な若手はどんどん辞めていく。
・SIerあるあるかもだが、協力会社に丸投げのプロジェクトがけっこうある。
転職先は事業会社のIT企画部です。次が身の丈があった環境かどうか不安もありますが、新たな環境にワクワクしています。
原文：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 にセキュリティアラートを発行しています：
