GitLabが重大な脆弱性を公表し，パッチを提供

GitLabは先頃，多数の重要なセキュリティ修正を発表した。重大な権限昇格も含むため，バージョン8.2以降のすべてのGitLabインストレーションに対して，適用が強く推奨される。

GitLabに，管理者を含む別ユーザとしてログインすることが可能な，認証関連の重大な脆弱性が発見された。この脆弱性はバージョン8.2のGitLabにおいて，管理者が他の任意のユーザのログインをシミュレートすることを意図した“偽装”機能に伴って混入したものだ。

今回の脆弱性は，バージョン8.2.0から8.7.0のGitLabに影響する。GitLabのエンジニアであるDouwe Maan氏はこの脆弱性について，同ソフトウェアでは最悪のものかも知れないと説明している。

ソフトウェアのパッチバージョン提供に加えてGitLabでは，稼働中のGitLabインストレーションに対応するために，Webサーバまたはプロキシサーバの構成変更，あるいはRubyファイルのパッチによる修正方法も公開している。例えば，Apache Webサーバを使用したインストレーションの場合ならば，以下のようなアクセスルールを定義することで脆弱性を回避できる。

<LocationMatch "^/admin/users/stop_impersonation">
  Order Deny,Allow
  Deny from all
</LocationMatch>

GitLabの発表には他にも，次のような重要度の低い脆弱性が含まれている。

• notes APIを経由した権限昇格 – アクセス権のないマージリクエストやスニペット，イシューのノートのポストが可能。
• プロジェクトWebフックを経由した権限昇格 – 認証済みのユーザが，個人のプロジェクトからWebフックの読み取りと削除が可能。
• その他，情報開示につながるXSS脆弱性など。

InfoQは，GitLabのエンジニアリング担当副社長であるStan Hu氏から，今回の脆弱性に関する発表と，このような問題に対するGitLubの一般的なアプローチについて話を聞いた。

先日開示されたGitLabの脆弱性について，どのような影響が考えられるのか，簡単に説明して頂けますか？

私たちの知る限りでは，現時点で確認されている影響はありません。今回の脆弱性はすべて，GitLabの社員とセキュリティ研究者のコード監査によって明らかになったものです。

GitLabは脆弱性に関しても，オープンポリシに従って定期的に公開しています。これ自体は素晴らしい事なのですが，GitLabに発見される脆弱性の数の多さや頻度を懸念する声も一部にあります。この件について，コメントをお願いします。

GitLabはこれまでも，これからも，セキュリティの脆弱性についてはオープンであり続けます。セキュリティ問題の修正を最優先として，脆弱性に関する報告には可能な限り迅速に対応するように努めます。有給とボランティア合わせて数百名のコントリビュータが，毎日，私たちのコードに目を光らせているのです。

私たちは毎月，多数の新機能とバグ修正を含んだ新しいリリースを提供しています。 コード全体の品質は一般的に高く，コードのすべての行を確認し，完全なテストを実行するように全力を尽くします。HackerOneなどのサイトでGitLabが運用されていることによって，多くのセキュリティ研究者が潜在的な問題の発見に協力してくれています。プロプライエタリなソフトウェアとは違い，オープンソースプロジェクトである以上，セキュリティの問題についてもオープンでなくてはなりません。

問題の発見からパッチ配布までのプロセス全体について説明して頂けますか？

CVE-2016-4340を発見した時，社内的には，数時間の内に修正が用意されていました。まず最初にGitLab.comにパッチを適用し，その後すぐに，プライベートリポジトリ内のすべての影響を受けるバージョンへのバックポートを開始しました。ユーザや一般の人たちにアップデートの準備時間を確保してもらうために，Eメールやブログを通じて，セキュリティアップデートの提供日(5月2日(月)23:59UTC)を公表しました。ネイティブパッケージメンテナ(DebianやFreeBSDなど)にもパッチの事前通知を行なって，すべてから高い評価を受けました。そして5月2日には，GitLabパッケージのアップデートをリリースすると同時に，アップデートの不可能なユーザに対しては，回避策をブログ記事で公開したのです。CVEの詳細はすべてMTREに提出しました。脆弱性に関連するソースコードと問題の内容はすべて公開されています。