カテゴリー: Uncategorized

投稿日:

JS7オンプレミス環境への自動インストレーション機能記事公開

JS7® JobSchedulerでは各コンポーネント（JOCコックピット・コントローラー・エージェント）のインストレーションスクリプト（js7_install_joc|controller|agent.sh|ps1）を提供していましたが、V.2.6.xではそれらをまとめて自動インストレーションできるデプロイ管理機能が追加されました。
弊社山下が紹介記事を以下に公開しましたのでご覧ください。
JS7® JobScheduler オンプレミスでの自動デプロイ
https://qiita.com/Yoshitami/items/21878c35e5d07b454612

投稿日:

JobScheduler V.1系のバグフィックス終了について

JobScheduler V.1系は、
2022年1月にリリースされたV.1.13.11が一般公開された最終バグフィックス版であり、
LTS（Long Term Support）契約のお客様は、2022年12月に公開されたV.1.13.17が最新バグフィックス版となっています。

後継製品であるJS7 JobScheduler（V.2系）が2021年8月にリリースされましたので2023年8月が２年目にあたり、V.1系のLTSバグフィックスも今年8月に終了となります。

How long will you support the different versions of JobScheduler and YADE?
https://kb.sos-berlin.com/pages/viewpage.action?pageId=3638050

サブスクリプションサポート契約のお客様は、バグフィックス提供以外のQA/障害対応は継続されますが、将来的な機能修正／プラットフォーム対応／脆弱性対応はご提供できなくなりますので
後継製品であるJS7 JobScheduler (最新版はV.2.5.1）への移行をご検討ください。

V.1系のジョブ定義ファイルをV.2系に変換するコンバーターも用意されています。
JS7 - Migration of JobScheduler 1.x Job Configuration
https://kb.sos-berlin.com/display/JS7/JS7+-+Migration+of+JobScheduler+1.x+Job+Configuration

投稿日:

Spring Frameworkの任意のコード実行の脆弱性（CVE-2022-22965）について: CMDBuild

2022/4/1　JPCERT/CCよりSpring Frameworkの任意のコード実行の脆弱性（CVE-2022-22965） 別名: Spring4Shellに関するCyberNewsFlashが発表されています。詳細については、以下をご参照ください。
https://www.jpcert.or.jp/newsflash/2022040101.html

（CyberNewsFlashは、注意喚起とは異なり、発行時点では注意喚起の基準に満たない脆弱性の情報やセキュリティアップデート予告なども含まれます。）

【以下抜粋】

対象となるバージョンは以下の通りです

  • Spring Framework 5.3.0から5.3.17
  • Spring Framework 5.2.0から5.2.19
  • すでにサポート終了した過去のバージョン

VMWareによると、同社に報告された攻撃シナリオにおいては、攻撃が成功するためには次の条件が必要だったとのことです。ただし、本脆弱性の影響を受ける条件は他にも存在する可能性があると示唆されており、今後公開される情報を注視する必要があります。

  • JDK 9以上を使用している
  • Apache Tomcatをサーブレットコンテナーとして使用している
  • WAR形式でデプロイされている
  • プログラムがspring-webmvcあるいはspring-webfluxに依存している

CMDBuild V.3.1以降でJDK11を使用している場合、本脆弱性の影響を受ける可能性があります。

【回避策】

VMwareより、対策の適用が難しい場合の回避策に関する情報が公開されています。詳細および最新の情報については、VMwareが提供する情報を参照ください。
Spring Framework RCE, Early Announcement - Suggested Workarounds
https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement

Tecnoteca社では上記修正を含んだリリース（V.3.4-g）が公開されています。

CMDBuild V.3.4-gにすぐにバージョンアップできない場合は、Tomcat 9.0.62以降に変更することで本脆弱性の対応が可能です。
https://spring.io/blog/2022/04/01/spring-framework-rce-mitigation-alternative

投稿日:

オープンソースチケット管理システム OTRSからOTOBO/Znunyへ

オープンソースのチケット管理システムとしては、ドイツのOTRS AG社が開発するOTRS　(Open-source Ticket Request System)が最も有名でコミュニティも世界的に活発で、日本でも導入事例がたくさんありました。
 
2018年4月、OTRS AG社は製品戦略を変更し、次のバージョンOTRS7から、商用（有償）版を“OTRS”、OSS(無償)版を“((OTRS)) Community Edition”というブランドに変更すると同時に、OSS版は商用版の新版を2年遅れで実装することを発表しました。
ここまでは、いわゆる「コマーシャル・オープンソース」製品としてはよくある話で、OSSのマネタイズ戦略としてはいたしかないことかもしれません。
 
ところが2020年12月23日、OTRS AG社はOSS版のOTRS7のサポートを2021年1月1日から停止すると発表しました。この発表は突然であり、しかも発表から年末年始を挟んで８日後に停止するという暴挙で、サポートベンダーを含むコミュニティから困惑と怒りが巻き起こったようです。
 
そしてOTRS6まではGPLライセンスの元で　ソース公開は続けられていますがダウンロードサイトは終了したため、閉じています。OTRS7以降はプロプライエタリライセンスとなりオープンソース製品ではなくなり、OSS版のユーザーは商用版を購入するか、別製品に切り替えるかを迫られました。
この辺りの事情は、この記事に詳しく書かれています。
 

フォークの登場

OTRS AG社の決定は唐突ではあるものの彼らの経営判断であり、コミュニティでは覆すことはできませんでした。しかし、OSS版OTRS6をフォークし拡張する製品が登場することにより、OSS版のユーザーはもう一つの選択肢を持つことができました。こういうことがあるのがオープンソースの一つの美点だと思います。
2020年7月にOTOBO、2021年1月にZnunyが誕生しました。
 
OTOBOは、2004年に最初の従業員として当時のOTRSGmbH（現在のOTRS AG）に加わり、2011年に退職するまでサポートと内部ITを担当していたStefan Rotherが創業した
ROTHER OSS GmbHによって開発され、有償サポートも提供しています。
特徴は完全に再設計された顧客インターフェースのモダンな外観です。
 
Znunyは、OTRS.orgのファウンダーの一人でありOTRS AG社のCTOであったMartin Edenhoferが2012年に創業したZnuny GmbH社が開発しており、こちらも有償サポートも提供しています。

国内でのサポート状況

国内では最も古くからOTRSをサポートしている株式会社アイオーアーキテクトがOTOBO/Znunyをサポートしており、以下アイオーアーキテクトさんのラボノートから引用します。
 
OTOBO, Znuny共に機能面ではほとんどOTRSと同じです。ただし今後はおそらくそれぞれ独自の進化のほうにシフトしていくと考えられます。
 
一応言及しておくと、OTOBOとZnunyの仲が悪いということはありません。現にOTOBOの一部にはZnuny由来の機能が存在しています。別々にフォークしながらいいところは取り込んでいくといった、OSSらしい良い循環が出来ているように見えます。
 
また、((OTRS)) Community Edition 6からの移行サービスも提供されています。
OTOBO/Znunyの製品紹介は、こちらをご覧ください。
日本語でのインストール手順も公開されていますので、OTOBO、Znunyをご参照ください。
 

ソフトウェアのサポートについて

弊社もオープンソースソフトウェアの商用利用をサポートしている立場として、OTRSのように提供ベンダーの事情によってメンテナンスが止まるリスクは常に考えています。
しかしある程度利用されてコミュニティが成立しているオープンソースでは、プロジェクトの継続ができなくなっても派生プロジェクトが立ち上がることに期待できます。
 
開発会社が買収されて製品をディスコンにすることが日常茶飯事のソフトウェア業界においては、プロプライエタリな商用製品よりオープンソースの方が優位ではないでしょうか？

 

投稿日:

【注意喚起】CVE-2022-21724, CVE-2022-23437, CVE-2022-23221 について（SOS JobScheduler）

JobScheduler 1.13.11以前に以下の脆弱性の対応を公開しました。

CVE-2022-21724　PGJDBC 特権昇格
　この脆弱性は 2022年02月02日ににて 「GHSA-v7wg-cpwc-24m4」として 紹介されました。 
https://change.sos-berlin.com/browse/JOC-1222?src=confmacro

CVE-2022-23437　APACHE XERCES JAVA まで2.12.1 XML PARSER サービス拒否
　この脆弱性は 2022年01月24日ににて 紹介されました。 
https://change.sos-berlin.com/browse/JS-1978?src=confmacro

CVE-2022-23221　H2 CONSOLE 前の2.1.210 JDBC URL PRIVILEGE ESCALATION
　この脆弱性は 2022年01月20日ににて 紹介されました。 
https://change.sos-berlin.com/browse/JS-1977?src=confmacro

対策
回避策については、上記リンクをご確認ください。
尚LTS契約ご契約のお客様については上記フィックスを含んだV.1.13.12がご提供されます。

https://kb.sos-berlin.com/display/PKB/Release+1.13.12

投稿日:

Apache Log4jのRCE（リモートコード実行の脆弱性）（CVE-2021-44832）について（SOS JobScheduler）

2021/12/29

Apache Log4jのRCE（リモートコード実行）の脆弱性について、新たな脆弱性が発見されCVE-2021-44832として公開されています。

Apache Log4j2 バージョン 2.0-beta7 から 2.17.0 (セキュリティフィックスリリース 2.3.2 と 2.12.4 を除く) には、リモートコード実行 (RCE) 攻撃の脆弱性があり、ロギング設定ファイルを変更する権限を持つ攻撃者が、JNDI URI を参照するデータソースを使って JDBC Appender で不正な設定を行い、リモートコードを実行できるようになってしまいます。この問題は、Log4j2 のバージョン 2.17.1, 2.12.4, 2.3.2 において、JNDI データソース名を java プロトコルに制限することで修正されます。

Apache Log4j Security Vulnerabilities
Fixed in Log4j 2.17.1 (Java 8)
https://logging.apache.org/log4j/2.x/security.html#log4j-2.17.1

JobScheduler V.1.13.10, V.2.2.0以降では設定ファイルlog4j2.xmlのデフォルト設定から、JDBC Appenderを使用するよう変更していない限り、CVE-2021-42832の影響を受ける可能性はないと考えていますが、下記が公開されましたのでご確認ください。

Update log4j2 2.17.1 to 2.17.1 due to 3rd party vulnerability issue in log4j2 2.17.0 (CVE-2021-44832)

https://change.sos-berlin.com/browse/JOC-1192?src=confmacro

 

投稿日:

【続々報】Apache Log4jの任意のコード実行の脆弱性（CVE-2021-45105）について（SOS JobScheduler）

2021/12/18

Apache Log4jの任意のコード実行の脆弱性について、新たな脆弱性が発見されCVE-2021-45105として公開されました。

自己参照による制御不能な再帰から保護されていないことに起因し、Log4jの設定によっては影響を受けるサービス運用妨害攻撃の可能性を修正したlog4j 2.17が公開されています。

Apache Log4j Security Vulnerabilities
Fixed in Log4j 2.17.0 (Java 8)
https://logging.apache.org/log4j/2.x/security.html#log4j-2.17.0

JobScheduler V.1.13.10以降では設定ファイルlog4j2.xmlのデフォルト設定を変えていない限り、CVE-2021-45105の影響を受ける可能性は低いと考えていますが、下記対応策が公開されましたのでご確認ください。

JOC-1188　Update log4j2 2.16.0 to 2.17.0 due to 3rd party vulnerability issue in log4j2 2.16.0 (CVE-2021-45105)
 https://change.sos-berlin.com/browse/JOC-1188?jql=text%20~%20%22log4j2%22

対応策：Log4jライブラリを対策済みの2.16/2.17に入れ替える

  • マスター
    • 1.13.3：以下ファイルを削除: 
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.13.0.jar
        • log4j-core-2.13.0.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.13.0.jar
    • 1.13.4 to 1.13.8：以下ファイルを削除:  
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.13.2.jar
        • log4j-core-2.13.2.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.13.2.jar
    •  1.13.9：以下ファイルを削除:  
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.14.0.jar
        • log4j-core-2.14.0.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.14.0.jar
    •  1.13.10：以下ファイルを削除:  
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-core-2.16.0.jar
    • 1.13.3 - 1.13.9：以下ファイルをコピー: 
      •  SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.16.0.jar
        • log4j-core-2.17.0.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.16.0.jar
    • 1.13.10：以下ファイルをコピー: 
      •  SCHEDULER_HOME/lib/3rd-party
        • log4j-core-2.17.0.jar
  • エージェント
    • 1.13.3：以下ファイルを削除:   
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.13.0.jar
        • log4j-core-2.13.0.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.13.0.jar
    • 1.13.4 to 1.13.8：以下ファイルを削除:   
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.13.2.jar
        • log4j-core-2.13.2.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.13.2.jar
    • 1.13.9：以下ファイルを削除:   
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.14.0.jar
        • log4j-core-2.14.0.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.14.0.jar
    • 1.13.10：以下ファイルを削除:   
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-core-2.16.0.jar
    • 1.13.3 - 1.13.9：以下ファイルをコピー:
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-core-2.17.0.jar
        • log4j-api-2.16.0.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.16.0.jar
    • 1.13.10：以下ファイルをコピー:
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-core-2.17.0.jar
  • JOCコックピット
投稿日:

【続報】Apache Log4jの任意のコード実行の脆弱性（CVE-2021-44228）について（SOS JobScheduler）

2021/12/16 更新

JPCERT/CCよりApache Log4jの任意のコード実行の脆弱性（CVE-2021-44228）に関する注意喚起が更新されCVE-2021-45046について追記されました。

特定の構成において不正なJNDI検索パターンを入力値とする場合にサービス運用妨害（DoS）が生じる可能性があることが判明し、Message Lookup機能が削除され、JNDIへのアクセスがデフォルトで無効になりました。この問題にはCVE-2021-45046が採番されています

llog4j 2.15及び下記対策は不完全であり、log4j 2.16へのアップデートが推奨されています。
（1）Log4jを実行するJava仮想マシンを起動時に「log4j2.formatMsgNoLookups」というJVMフラグオプションを「true」に指定する 例: -Dlog4j2.formatMsgNoLookups=true
（2）環境変数「LOG4J_FORMAT_MSG_NO_LOOKUPS」を「true」に設定する。

JobSchedulerの回避策も更新されましたので、以下をご確認ください。
https://change.sos-berlin.com/browse/JOC-1184

https://change.sos-berlin.com/browse/JOC-1186

2021/12/14

SOS社では現在上記修正版を含んだ緊急リリース（V.1.13.10, V.2.2.0）を作成中であり、2021/12/24に公開予定です。
回避策が更新されましたので、以下をご参照ください。
https://change.sos-berlin.com/browse/JOC-1184

2021/12/16 更新

以下の対策は不完全であるため、log4j 2.16へのアップデートが推奨されています。

V.1.13系について回避策には以下の2通りの方法があります。JS7については上記リンクをご参照ください。

（1）Log4jを実行するJava仮想マシンを起動時に「log4j2.formatMsgNoLookups」というJVMフラグオプションを「true」に指定する

例: -Dlog4j2.formatMsgNoLookups=true

  • マスター：SCHEDULER_DATA/config/factory.iniを編集し
[java]
options =に、-Dlog4j2.formatMsgNoLookups=true　を追加してマスター再起動

再起動後にscheduler.logのJava options: に[-Dlog4j2.formatMsgNoLookups=true]が表示されればOK

  • エージェント：一旦停止し、
$ SCHEDULER_HOME/bin/agent_<port>.sh | .cmd　  start -java-options=-Dlog4j2.formatMsgNoLookups=true

で再起動、systemd service などで自動起動設定している場合は、ExecStart=のコマンドに-java-options=-Dlog4j2.formatMsgNoLookups=trueを追加して、サービスリスタート

  • JOCコックピット：
Linuxの場合/etc/default/joc、
Windowsの場合 、レジストリ
HKLM\SOFTWARE\WOW6432Node\Apache Software Foundation\Procrun 2.0\sos_joc\Parameters\Java

を編集し、JAVA_OPTIONS=に-Dlog4j2.formatMsgNoLookups=trueを追加して、サービス再起動

参考：https://kb.sos-berlin.com/display/PKB/JOC+Cockpit+-+Installation#JOCCockpit-Installation-JavaOptionsforJetty

（2）Log4jライブラリを対策済みの2.16に入れ替える

  • マスター
    • 1.13.3
    • 以下ファイルを削除: 
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.13.0.jar
        • log4j-core-2.13.0.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.13.0.jar
    • 1.13.4 to 1.13.8
    • 以下ファイルを削除:  
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.13.2.jar
        • log4j-core-2.13.2.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.13.2.jar
    •  1.13.9
    • 以下ファイルを削除:  
      • CHEDULER_HOME/lib/3rd-party
        • log4j-api-2.14.0.jar
        • log4j-core-2.14.0.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.14.0.jar
    • 全バージョン
    • 以下ファイルをコピー: 
      •  SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.16.0.jar
        • log4j-core-2.16.0.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.16.0.jar
  • エージェント
    • 1.13.3
    • 以下ファイルを削除:   
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.13.0.jar
        • log4j-core-2.13.0.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.13.0.jar
    • 1.13.4 to 1.13.8
    • 以下ファイルを削除:   
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.13.2.jar
        • log4j-core-2.13.2.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.13.2.jar
    • 1.13.9
    • 以下ファイルを削除:   
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.14.0.jar
        • log4j-core-2.14.0.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.14.0.jar
    • 全バージョン
    • 以下ファイルをコピー:
      • SCHEDULER_HOME/lib/3rd-party
        • log4j-api-2.16.0.jar
        • log4j-core-2.16.0.jar
      • SCHEDULER_HOME/lib/log/log4j
        • log4j-slf4j-impl-2.16.0.jar
  • JOCコックピット