Google Chrome (Chromium)を自分でビルドする

いろいろとやる必要があり、Chromiumを手元でコンパイルしたのでその記録。

(2018-06-23) @tzik_tackさんに指摘いただき、一部修正しました。ありがとうございます。

ChromeとChromium

まず、予備知識。

Chromiumはオープンソースプロジェクト名であり、そのプロダクトがChromiumというWebブラウザ。そして、ChromiumをベースにGoogleが固有機能を追加したものが、我々がふだん使っているGoogle Chromeである。

もっとも、Chromiumプロジェクト自体Googleが深く関わっているし、普通にそこでの実装の意思決定もGoogleのエンジニアによるものが多いので、実質どっちもGoogleがやってるという理解でおおむね問題ない。

Google Chrome自体はGoogleの著作物なので、自分でビルドするならばChromiumをビルドする、ということになる。

ビルド準備

基本的には、ドキュメントに書いてある通りにやればいい。ここに私が書いてあることもすぐ陳腐化すると思うので、ドキュメントを読もう。

ビルドには、Ubuntuを使った方が良い。WindowsでもVisual Studio Community 2017でビルドできるけど、Core i5, RAM 8GB, SSDのマシンでsln(プロジェクトファイル)開くだけで1時間、ビルドは10時間かけても終わらなかったので、やめた方がいい。

なおドキュメントには「8GB以上のメモリ（16GB以上を推奨）、100GB以上のディスク空き容量」が必要と書かれているので頑張ろう。私はESXi上の、Ubuntu 16.04.4を使った。

ビルドに必要なパッケージはだいたいソースコード一式に同梱されているので、事前準備としてはpython, build-essential, gitくらいあればいいはず。(最近のChromeはClang使っているが、chromiumリポジトリに同梱されているためclangパッケージは不要）

ビルド手順

depot_tools

はじめに、ビルドに必要なdepot_toolsというリポジトリをcloneする。

$ git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git

この中にある色々なツールを使うので、PATHを通しておくこと。たとえば.bashrcに以下のように加える。

export PATH="$PATH:/home/ozuma/local/depot_tools"

続いて適当な作業ディレクトリ内で、dep_toolsのfetchコマンドでソースコードを取得する。この際、--no-historyを付けて最新版のみ取得すると良い。

$ fetch --nohooks --no-history chromium

ドキュメントのとおり、このfetchには30分ほどかかる。するとsrcディレクトリができるので移動する。

$ cd src

ここまでで、ソースコードのcheckoutができた。続いてUbuntuの場合、依存性を解決してくれるシェルスクリプトが用意されているので実行する。

$ sudo build/install-build-deps.sh

追加パッケージ入手。

$ gclient runhooks

ここまでで、ビルドの準備が整った。

Ninjaビルド

Chromeのビルドは、depot_tools付属のninjaというコマンドで行う。ninjaについては以下。

Ninjaがビルドするためのディレクトリout/Defaultを、depot_tools付属のgnコマンドで作成する。

$ gn gen out/Default

さて、このままビルドしても良いのだが、それだと大変に時間がかかるのでここでいくつかオプションを加える。gnコマンドにargsを付けてオプションを設定する。

$ gn args out/Default

ドキュメントに書いてあるが、まずJumbo buildsという設定をすると早くなる。多くのソースコードがヘッダファイルを共有しているのだから、それらを一緒にコンパイルする……と書いてあるけど、具体的な動きはよく分からない。

また、NaCl(Native Client)をビルドしないようにする。

それから、デバッグ用に使うわけではないの、デバッグシンボルを全部OFFにする。

これらの設定は、上記gn argsコマンドを打つとvimが起動するので、そこに以下のように記述する。実際には、out/Default/args.gnファイルに書かれる。

use_jumbo_build=true
enable_nacl=false
symbol_level=0
remove_webcore_debug_symbols=true
is_debug=false
is_component_build=true

最後に、ninjaコマンドでビルドする。timeコマンドを頭に付けて、どのくらいの時間がかかるか見ておいた方がいい。

ozuma@ubuntu16:~/local/depot_tools/src$ time ninja -C out/Default chrome
ninja: Entering directory `out/Default'
[19686/19686] LINK ./chrome

real    331m41.029s
user    320m3.768s
sys    8m46.260s
ozuma@ubuntu16:~/local/depot_tools/src$

私の手元では、全ビルドに5時間半ほどかかった。Windowsに比べればメチャクチャ早い。

Chromiumの起動

できあがったバイナリはout/Default/chrome。これをたたくと、ちゃんと起動した。

おしまい。

特定のバージョンのビルド

上記の手順では最新のビルド(Canary相当)が入るので、Stableなど古いバージョンを指定してビルドする場合。

上記にやり方が書いてあるが、この通りだとエラーを吐く。

で言われているように、

$ gclient sync --with_branch_heads --with_tags -Rv --disable-syntax-validation

と-Rv --disable-syntax-validationを指定する必要がある。（syntax validation無しでいいのだろうか）

これでタグが持ってこれたので、タグを指定してチェックアウトする。以下のようになる。

$ git checkout -b branch_67.0.3396.87 67.0.3396.87

(Gitでは、コミットIDの代わりにタグ名を指定してcheckoutできる）

なおgclient syncは、checkoutしたあとに依存性の更新をするためにもう一度実行する必要がある。

あとは同じようにビルドする。

$ gclient runhooks
$ gn gen out/67.0.3396.87
$ gn args out/67.0.3396.87
$ time ninja -C out/67.0.3396.87 chrome

個人でEV SSL証明書は取れるのか (1)

それなりにSSL証明書マニアなので、昨日から、「個人でEV SSL証明書を取るにはどうすればいいか」というアホなことを調べている。

まず、認証局が厳密に従っている(はずだよね?)の、CA/Browser Forumのドキュメントを確認した。EV SSL証明書の発行プロセスについては、Baseline Requirementsの方では無く、「About EV SSL」として以下に分かりやすくまとめられている。

ここで発行対象を見ると....

Certification Authorities (CAs) may only issue EV SSL Certificates to Private Organizations, Government Entities, Business Entities and Non-Commercial Entities that satisfy the requirements specified below.

ということで、以下の4つにしかEV SSL証明書は発行できない。

  1. Private Organizations
  2. Government Entities
  3. Business Entities
  4. Non-Commercial Entities

うん。個人ではやっぱダメだね。私は政府組織関係ないから(2)はダメだ。というわけで方針変更して、個人事業主もしくは、主催している「すみだセキュリティ勉強会」で取れないかを考えてみる。

で、(4)の「Non-Commercial Entities」の条件はキツすぎる。

The Applicant is an International Organization Entity, created under a charter, treaty, convention or equivalent instrument that was signed by, or on behalf of, more than one country’s government.

最後の「more than one country’s government.」が強すぎて、日本ならNPO法人として登録し、さらに複数の国....つまりどこでもいいから別の国でも登録しないといけない。ムリムリムリ。ちなみに日本でNPO法人でEV SSL証明書を取っている例では、JIETというところがあるんだけど、

ここはバンコク支部やソウル支部を持っているので、この条件はクリアしているのだろう……。

というわけで「Private Organizations」。これ、普通の会社では、帝国データバンクのやDUNS(東京商工リサーチ)の登録番号出したり、法務局に行って法人登記簿謄本やら取ってくるんだけど....個人だとあれか、マイナンバーカードならいいのか。あれなら政府お墨付きだから文句は言わせんぞ。

もしくは、個人事業主の開業届も、政府(国税庁)の公文書だからよいのでは。とか屁理屈を考えたけど、comodoもdigicertも「個人事業主はダメ」ってはっきり書いてある。

うーん。次回に続く。（続かないかも）

追記(2018-08-26)

解決しました。

すみだセキュリティ勉強会2018その1を開催しました

長い間のブランクをあけてしまいましたが、主催しているすみだセキュリティ勉強会を久々にやりました。

私のお話は、emoji(絵文字)を使ったパスワードの話です。

前々から日本語もパスワードに許せばいいのにと思っていたのですが、どうせUnicodeなんだったら絵文字も突っ込んじゃえばどうだろ? と思ったのが元ネタです。理屈上は、Unicodeを正しく扱っていれば、日本語だろうがASCII文字だろうが絵文字だろうが単なる「1文字」なので、最近のモダンな環境なら普通に通るはずですね。

なおemojiなどの面0(BMP)以外のUnicode文字は、既知の通りMySQLで多くの地雷が埋まっています。寿司ビール問題くらいならまだいいのですが、INSERT時にemoji以降が切り捨てられるという現象が起こる場合もあります。
これがパスワードで発生すると非常に困った事態になるのですが、少なくともパスワードについてはハッシュ化するなりして捻って格納しているはずですから、切り捨て問題は起きないはず。平文でパスワードを保存していたら知らんけど。

ようやく復活できたので、隔月くらいでまた開催したいなー。

補足

勉強会後に気づきましたが、既にGCP(Google Cloud Platform)で、絵文字をパスワードに使ってもいいんじゃね? 的な話が出てました。

こうした点を踏まえると、ユーザーが使いたいあらゆる文字をパスワードに使用できるようにするべきです。Klingon や Emoji、両端に空白を含む制御文字をパスワードに含めたいユーザーがいたとしても、それを拒む技術的理由はないはずです。

これは、NIST SP 800-63Bを受けてのようです。

5.1.1 Memorized Secrets
For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.

memcachedの開放ポート(11211/tcp, 11211/udp)をサクっと確認する

昨日(2018/02/27)に、JPCERTからmemcached のアクセス制御に関する注意喚起が出ていました。

ということでmemcachedのポート(11211/tcp, 11211/udp)が開放されていないかの確認方法についてメモしておきます。

memcached開放により起きる問題

はじめに、memcachedのポートを外部から接続可能にしてしまうと何が問題か整理しましょう。

内部情報の漏洩

1つはすぐに思い付くことですが、内部情報の漏洩です。memcachedは認証の無いプロトコルであるため(正確にはあるけど、誰も(?)使ってない)、外部から接続できれば即キャッシュ上の値を取得することができます。

たとえばphp.iniで以下のように設定していれば、

session.save_handler = memcached
session.save_path = "localhost:11211”

セッション情報を外部から取得可能となってしまいます。その他、キャッシュに乗っている値を根こそぎ取得できてしまいます。

UDP Reflection Attackの踏み台となる

2018年2月現在は、情報漏洩よりもこちらの被害が問題視されています。

UDPはコネクションレスであり送信元偽装が容易なため、リクエストに対してレスポンスが大きいプロトコルは、偽装した送信元(=攻撃先)への「跳ね返り」によりDDoS攻撃に利用できます。
たとえば数年前には、ntpのmonlist機能でこのようなDDoSが指摘され、攻撃者に利用されてしまいました。(参考:ntpd の monlist 機能を使った DDoS 攻撃に関する注意喚起)

memcachedで「リクエストに対してレスポンスが大きい」ことですぐ思いつくのは、状態表示をおこなうstatsコマンドでしょう。

# printf "stats\r\n" | nc 192.168.2.67 11211
STAT pid 10330
STAT uptime 5559
STAT time 1519825560
STAT version 1.4.15
STAT libevent 2.0.21-stable
STAT pointer_size 64
STAT rusage_user 0.055732
STAT rusage_system 0.057469
STAT curr_connections 10
STAT total_connections 37
STAT connection_structures 11
STAT reserved_fds 20
STAT cmd_get 11
STAT cmd_set 6
...(略)...
END

上記の例のように、statsというコマンドだけで大量のレスポンスが得られます。なおmemcachedはCRLFを改行とみなすので、この例は律儀にprintfで"\r\n"を付けてます。

さらに、(詳しい操作は念のため伏せますが)外部からmemcachedが操作可能ならば、適当なkeyにとても長い値をsetして、送信元を偽装したUDP通信でgetするだけで、大きいレスポンスを偽装先へ送りつけることができます。このため memcachedのUDPポートを外部に開放していると、UDP Reflection AttackによるDDoSへ踏み台として荷担してしまうことになります。

memchacedでUDPをoffにするには、「-U 0」というオプションを付加します。CentOS 7のパッケージならば、以下のように /etc/sysconfig/memcached ファイルの「OPTIONS」に記述します。

PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="64"
OPTIONS="-U 0"

この「-U」は本来はUDPの待ち受けポートを指定するオプションなのですが、manに記載の通り、ゼロを指定するとUDPのLISTEN自体をOFFにします。

ポート開放の確認

memcachedは、TCP・UDPともに11211ポートがデフォルトで利用されます。通常はTCPしか使われないため、UDPは明示的に意識しない限り使うことはないでしょう。

しかしmemcachedデフォルトではTCPだけでなくUDPも開放されるため(memcached 1.5.6からはUDPはデフォルトでは無効らしい)、特にUDPのフィルタは見落としがちです。

ここからは、外部へ本当にポート開放していないかを確認する方法を記述します。なおこちらに書いた手法はポートスキャンに当たるため、必ず自らが管理するホストのみに行い、第三者のホスト・ネットワークをスキャンすることの無いようにしてください。

nmapを利用

ポート確認ならば、まず思いつくのはnmapでしょう。

TCPポートがopenしているか確認するだけならば、SYNスキャン(-sS)するだけで十分です。出力は-oNオプションでテキストに落としておくと良いでしょう。ここでは192.168.2.0/24をスキャンし、オプションには-nを付けて逆引きしないようにしています。

# nmap -n -sS -p11211 -oN output.txt 192.168.2.0/24

出力にはclosedやfilteredのものも混じるので、openを検索します。

...(略)...
Nmap scan report for 192.168.2.65
Host is up (0.000091s latency).

PORT      STATE    SERVICE
11211/tcp filtered memcache
MAC Address: E0:3F:49:XX:XX:XX (Asustek Computer)

Nmap scan report for 192.168.2.67
Host is up (0.00014s latency).

PORT      STATE SERVICE
11211/tcp open  memcache
MAC Address: 00:0C:29:CC:C7:B0 (VMware)

Nmap scan report for 192.168.2.99
Host is up (0.00022s latency).
...(略)...

TCPを1ポートだけのポートスキャンならば、相当広いネットワーク帯であっても数秒〜数分で終わるでしょう。

さて11211/tcpの開放チェックは簡単ですが、UDPとなると少々やっかいです。周知の通り、UDPのポートスキャンは往々にして不正確で、nmapのUDPスキャンオプションである-sUしただけでは次のように「open|filtered」となり見逃してしまいます。

# nmap -n -sU -p11211 192.168.2.67
Starting Nmap 7.60 ( https://nmap.org ) at 2018-02-28 22:58 JST
Nmap scan report for 192.168.2.67
Host is up (0.00018s latency).
PORT      STATE         SERVICE
11211/udp open|filtered memcache
MAC Address: 00:0C:29:CC:C7:B0 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 0.24 seconds

このためnmapによるUDPスキャンの場合は、少々応答時間が増えますが、-sVでバージョン検出を付加すると正しくOpenを判断してくれます。

# nmap -n -sU -sV -p11211 192.168.2.67
Starting Nmap 7.60 ( https://nmap.org ) at 2018-02-28 23:01 JST
Nmap scan report for 192.168.2.67
Host is up (0.00018s latency).
PORT      STATE SERVICE   VERSION
11211/udp open  memcached Memcached 1.4.15
MAC Address: 00:0C:29:CC:C7:B0 (VMware)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.48 seconds

この際、パケットキャプチャしてみると、以下のようにUDP上で「stats」コマンドを打っていることが分かります。

なお、UDPスキャンはとても遅いスキャンです。特に対象UDPポートから応答が無い場合、上記のオプションのままではタイムアウト待ちとなり1分以上かかるのが普通です。現場では次のように、-Pn(ICMPなどによるhost discoveryを行わない)、--host-timeout(何秒であきらめるか)を同時に指定して高速化を図ると良いでしょう。

# nmap -n -Pn --host-timeout 3 -sU -sV -p11211 192.168.2.67

日本語のmanではhost-timeoutの引数は「ミリ秒」と書かれていますが、この記述は古く、現在の単位は「秒」です。3秒というのはアグレッシブすぎる気もしますが、元々memcachedは高速応答しないと意味がないプロトコルのため、こんなもんでしょう。異論は認める。

ちなみにnmapでもっと詳細情報を得たい場合、memcached-infoというnseスクリプトが利用できます。

# nmap -p11211 --script memcached-info 192.168.2.67

Starting Nmap 7.60 ( https://nmap.org ) at 2018-02-28 23:12 JST
Nmap scan report for 192.168.2.67
Host is up (0.00020s latency).

PORT      STATE SERVICE
11211/tcp open  memcache
| memcached-info: 
|   Process ID           10330
|   Uptime               7147 seconds
|   Server time          2018-02-28T14:12:28
|   Architecture         64 bit
|   Used CPU (user)      0.077393
|   Used CPU (system)    0.066839
|   Current connections  10
|   Total connections    42
|   Maximum connections  1024
|   TCP Port             11211
|   UDP Port             11211
|_  Authentication       no
MAC Address: 00:0C:29:CC:C7:B0 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 1.19 seconds
nc(netcat)を利用

本当にちょこっと確認したいだけならば、nc(netcat)が便利です。以下のように11211に接続できるかどうかで、ポート開放を判断できます。

$ nc 192.168.2.67 11211
stats     ← コマンドを打つ
STAT pid 10330     ← 結果が返る
STAT uptime 7382
STAT time 1519827383
STAT version 1.4.15
STAT libevent 2.0.21-stable
...(略)...

なおnc(netcat)にはUDPモードもありますが、コマンドラインからUDPで接続してTCP同様に手でコマンドを打っても正しく動作しません。次のようにstatsコマンドを組み立てる必要があります。

# echo -en "\x00\x00\x00\x00\x00\x01\x00\x00stats\r\n" | nc -u 192.168.2.67 11211

※上記コマンドはCloudflareのブログ記事、Memcrashed - Major amplification attacks from UDP port 11211を参考にさせて頂きました。

その他のツール類

memcached-toolを利用

memcached-toolは、Perlで書かれたmemcached操作ツールです。

単独のスクリプトなので、このファイル1つをダウンロードしてPerlで実行するだけで気軽に試せます。ただし、接続はTCPのみサポートしているため、UDPの確認はできません。

引数なしで実行するとヘルプが出ます。

# perl memcached-tool
Usage: memcached-tool <host[:port] | /path/to/socket> [mode]

       memcached-tool 10.0.0.5:11211 display    # shows slabs
       memcached-tool 10.0.0.5:11211            # same.  (default is display)
       memcached-tool 10.0.0.5:11211 stats      # shows general stats
       memcached-tool 10.0.0.5:11211 settings   # shows settings stats
       memcached-tool 10.0.0.5:11211 sizes      # shows sizes stats
       memcached-tool 10.0.0.5:11211 dump       # dumps keys and values
...(略)...

便利なのは、dumpコマンドです。これを実行すると現在キャッシュされている全てのkeyと値を出力してくれます。

# perl memcached-tool 192.168.2.67:11211 dump
Dumping memcache contents
  Number of buckets: 3
  Number of items  : 3
Dumping bucket 1 - 1 total items
add key1 0 1519820001 3
100
Dumping bucket 12 - 1 total items
add key3 0 1519820001 1000
012345678901234567890...（省略）...0123456789012345678901234567890123456789012345678901234567890123456789
Dumping bucket 4 - 1 total items
add key2 0 1519820001 100
0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
root@kali:~#
shodan

個別のホスト探索にはあまり適しませんが、世界中のホストがどの程度11211/tcpを開放しているかは、shodanで確認できます。


「port:11211」というクエリで検索できます。なおこのクエリはログインしていないと利用できませんが、アカウント作成自体は無料です。

参考文献・リンク