This service is available only in Japanese-language.

Column & Tips

wpa_supplicant:fix WPA2 key relay security bug


BlackHatでの発表が予告されたWPA2の脆弱性ですが、gitで取得する分に関してYocto2.1以降は本日(10/17 7:00)頃
セキュリティFixがcommitされています。
(追記) 10/17 20:17[日本時間] に、Yocto2.0(jethro)向けのパッチリリースがMLに投稿されています。

Yocto2.3(pyro) http://lists.openembedded.org/pipermail/openembedded-core/2017-October/1...
Yocto2.2(morty) http://lists.openembedded.org/pipermail/openembedded-core/2017-October/1...
Yocto2.1(krogoth) http://lists.openembedded.org/pipermail/openembedded-core/2017-October/1...
Yocto2.0(jethro) http://lists.openembedded.org/pipermail/openembedded-core/2017-October/1...

ブランチ名を指定してgitで取得する場合は、最新のものに置き換えることで対応可能ですが、ベンダー提供のBSPに良くある
commit id を指定してgitで取得する場合は、以下の方法でbbappendを作成して、自前で対応することも可能です。

1)  独自のレイヤーを作成する。
   yocto-layer create <レイヤー名>
で作成すると簡単に作成できます。

2) 作成したイヤーに以下のディレクトリを作成する。
   recipes-connectivity/wpa-supplicant/wpa-supplicant

3) 作成したディレクトリに、key-replay-cve-multiple.patch という名称のファイルを作成する。
  上記の該当するブランチに対するパッチのメールを張り付ける。

4) パッチファイルの不要な部分を削除
  4-1 パッチファイルの先頭まで削除
  --- /dev/null
  +++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/key-replay-cve-multiple.patch
   の行まで削除する。

  4-2 パッチファイルの最終行以降の削除
  diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.5.bb b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.5.bb
  といった行以降を削除する。(jethro は2.4、krogoth及びmortyは、2.5、pyroは2.6)(削除は、この行も含みます)

  4-3 各行の先頭の+を削除

  上記手順で、パッチファイルの作成は完了です。

5) bbappendファイルの作成
  パッチを作成したディレクトリから一つ上のディレクトリに、jethorpはwpa-supplicant_2.4.bbappend 、krogoth及びmortyはwpa-supplicant_2.5.bbappend
pyroはwpa-supplicant_2.6.bbappend を作成します。
  ファイルの内容は
  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
  SRC_URI += " file://key-replay-cve-multiple.patch "

6) wpa-supplicntのbuildの実行
  bitbake-layers add-layer 等を実行して、conf/bblayers.conf に1)で作成したレイヤーを追加したのち
  bitbake wpa-suppllicant を実行する。
  パッチが本当に適応されているか不安な場合は、tmp/work/xxxxx/wpa-supplicant/バージョン名/wpa-supplicant-バージョン/ 以下で
  実際に変更されているか確認する。

上記の手順で、今回発見された脆弱性に対して、ターゲット側の対応は完了となります。

なお、ベンダーから提供されるBSPに脆弱性への対応が入った場合は、今回作成したbbappendは不要となります。
  

SMARTを使用したパッケージ管理


Yocto2.2 まで、ターゲットマシン上で実行するパッケージマネージャーとして、smartが提供されていました。

ターゲットボードのrootfsで足りないコマンドがあった場合に、rootfsを更新することなく、パッケージの
追加削除が可能となり、開発段階で色々試行するのに便利に使用できます。

過去形で記述しているのは、python2ベースのツールであったため、次のYocto2.3ではDNFに置き換えられています。
ですが、今現在の各ベンダーから提供されているBSPは、最新版でもYocto2.2を採用している場合が多いため、簡単
な使用方法を説明します。

1. build マシンの設定

1.1 httpdの設定
任意のhttpdをインストールします。
  超実践講座で紹介する場合は、lighttpdを使用しています。
  /var/www/ 以下から、rpmのパッケージが格納されているディレクトリへのリンクを張り、 
http://hostname/beaglebone/
とアクセスした際に
  build/tmp/deploy/rpm
が参照できるように、シンボリックリンクを作成します。

1.2 conf/local.conf への記述追加
  EXTRA_IMAGE_FEATURES にpackage-manegement を追加。

1.3 package-indexの作成
   bitbake package-index を実行して、rpm以下の各ディレクトリ内にrepo データを作成します。

2. ターゲット上での操作

2.1 CHANNELの設定
buildマシンのtmp/deploy/rpm 以下の
all beaglebone cortexa8hf_neon
  ディレクトリをCHANNELとして登録します。

  smart channel -add all type=rpm-md baseurl=“http://hostname/beaglebone/all
  smart channel -add beaglebone type=rpm-md baseurl=“http://hostname/beaglebone/beaglebonel
  smart channel -add cortexa8hf_neon type=rpm-md baseurl=“http://hostname/beaglebone/cortexa8hf_neon

登録完了後 smart channel --list コマンドを実行して、登録状態を確認します。

2.2 キャッシュの更新
  smart update コマンドを実行して、キャッシュのアップデートを行います。

2.3 buildマシンで構築済パッケージの追加
  smart search コマンドを実行して、buildマシン上にパッケージの有無を確認します。
  例として、curlを使用します。
  

# smart search curl
Loading cache...
Updating cache... ######################################## [100%]

curl - Command line tool and library for client-side URL transfers
curl-dbg - Command line tool and library for client-side URL transfers - Debuggs
curl-dev - Command line tool and library for client-side URL transfers - Develos
curl-doc - Command line tool and library for client-side URL transfers - Documes
gstreamer1.0-plugins-bad-curl - GStreamer plugin for curl
libcurl4 - Command line tool and library for client-side URL transfers

#
 

存在が確認できた場合は、smart install パッケージ名
   を使用して、インストールを実行します。

: ~#smart smart install curl
Loading cache...
Updating cache... ######################################## [100%]

Computing transaction...

Installing packages (1):
curl-7.50.1-r0.0@cortexa9hf_neon

100.7kB of package files are needed. 146.8kB will be used.

Confirm changes? (Y/n): y

Fetching packages...
- > http://192.168.201.107/beaglebone/.../curl-7.50.1-r0.0.cortexa9hf_neon.rpm
curl-7.50.1-r0.0.cortexa9hf_n.. ######################################## [100%]

Committing transaction...
Preparing... ######################################## [ 0%]
1:Installing curl ######################################## [100%]

# which curl
/usr/bin/curl
#

3. 新規にbuildマシンでパッケージを追加した場合

3.1 buildd マシンで実行するコマンド
  bitbake package-index
で、indexを更新します。

3.2 ターゲットで実行するコマンド
  smart update
で、パッケージ情報を更新します。
  

bitbake -e でエラーの解析


bitbakeの実行時に、ちょっと不可解な変数の設定が行われる場合があります。
そのような時には、"bitbake -e レシピ名 > 一時ファイル名" を実行してみて下さい。

一時ファイルを追っていくと、どの時点で不可解な変数となってしまっているのか、
見つける手助けになります。

meta-gplv2 が利用可能に


2017年5月12日付けでリリースされたYocto2.3(morty)ですが、yocto projectの
gitserver上でダウンロード可能な互換レイヤーに、meta-gpl2 が追加されています。

以下、リファレンスマニュアルの変更情報へのリンクです。
http://www.yoctoproject.org/docs/2.3/ref-manual/ref-manual.html#migratio...

GPLv3ライセンスに移行してしまったパッケージに関して、GPLv2ライセンスの時代の
ソースコードを使ってbuildを行うためのレシピが含まれています。

アップストリームのメンテナンスが終了しているものもあり、脆弱性への対応に
バックポートが必要など注意すべき点はありますが、使い勝手の良いレイヤーが
誕生したことは歓迎したいと思います。

以下、レイヤーの情報となります。

meta-gplv2
==========

This layer contains a set of recipes corresponding to old, obsolete versions of
software that are GPLv2 licensed where the upstreams have moved to GPLv3 licenses.

These were part of OE-Core until it was realised they are a ticking timebomb
with regard to security updates and general maintenance. By splitting into a separate
layer, it's hoped people realise these may not be the best solution to the
"no GPLv3 problem" and it should also make it clear there is a different quality of
service applied to these recipes.

For now, they do continue to get minimal testing by the Yocto Project but this will
eventually be stopped, with anyone wanting to use them taking up the maintainership.

The current maintainer for the layer is Ross Burton

Where to Send Patches
=====================

For now, patches should be sent to the Yocto mailing list with [meta-gplv2] in the subject
line. Before sending, be sure the patches apply cleanly to the current master branch of the
git repository.

Git repository: http://git.yoctoproject.org/cgit.cgi/meta-gplv2/
Mailing list: yocto@lists.yoctoproject.org

Column Start


コラム形式でYoctoの情報を載せていきたいと思います。