2022年10月01日

まもなく Linux 6.0 がリリース。不具合の修正状況は・・・?

syzbot が発見した Linux カーネルの不具合の内、修正されたことが報告された件数が9/15に4000件になりました。

簡単な集計をしてみたところ、 511 人の開発者により 2831 個のパッチが適用され、熊猫は 89 個で第3位のようです。

$ wget -q https://I-love.SAKURA.ne.jp/syzbot-4000.txt
$ awk ' { for (i = 1; i <= NF; i++) if (length($i) == 12) { print $i } }' syzbot-4000.txt | awk '/[0-9a-f]{12}/{ print $0 }' | sort -u > /tmp/patches.txt
$ wc -l /tmp/patches.txt
2831 /tmp/patches.txt
$ for i in `cat /tmp/patches.txt `; do git show $i; done | grep ^Author: > /tmp/authors.txt
$ awk '{ $1 = ""; $NF=""; count[$0]=count[$0]+1 } END { for (key in count) { printf("%4d %s\n", count[key], key) } }' /tmp/authors.txt | sort -nr | wc -l
511
$ awk '{ $1 = ""; $NF=""; count[$0]=count[$0]+1 } END { for (key in count) { printf("%4d %s\n", count[key], key) } }' /tmp/authors.txt | sort -nr | head -n 20
 398  Eric Dumazet
 100  Cong Wang
  89  Tetsuo Handa
  85  Takashi Iwai
  75  Eric Biggers
  71  Pavel Skripkin
  64  Jens Axboe
  56  Florian Westphal
  47  Xin Long
  41  Alan Stern
  40  Johannes Berg
  37  Pavel Begunkov
  35  David Howells
  34  Oliver Neukum
  33  Jan Kara
  28  Paolo Abeni
  27  Daniel Borkmann
  26  Willem de Bruijn
  25  Sean Christopherson
  25  Johan Hovold

修正件数上位10名が作成したパッチについて統計情報を調べてみると、 Eric Dumazet さんと Cong Wang さんと Florian Westphal さんと Xin Long さんはネットワーク関連のパッチを、 Takashi Iwai さんはサウンド関連のパッチを、 Jens Axboe さんはブロック関連のパッチを、 Alan Stern さんはUSB関連のパッチを、熊猫と Eric Biggers さんと Pavel Skripkin さんは様々な分野のパッチを作成しているようです。

$ mkdir /tmp/authors/
$ for commit in `cat /tmp/patches.txt`; do git show $commit | awk ' { if (NR == 2) { $1 = ""; $NF = ""; AUTHOR = $0 } else if (NR > 3) { print $0 >> "/tmp/authors/"AUTHOR } } '; done
$ for author in /tmp/authors/*; do basename "$author"; diffstat -p1 "$author"; echo; done > /tmp/diffstat.txt

syzbot に報告されずに修正された不具合も存在しているため、誰も正確な件数は把握していないのですが、修正されたファイルの数としては、ネットワーク関連が一番多く、ドライバ関連が続くという、予想外の結果になっています。
ネットワーク関連の処理では、不具合を恐れずに適用してみて、不具合が見つかったら修正すればよいという考え方で開発が行われてきたということなのかもしれませんね。

syzbot による不具合探しが始まってから5年以上が経過し、自組織の環境で syzkaller を動作させるなど、不具合の発見と修正に関わるカーネル開発者も増えてきている感じがします。
複数の開発者が同じ不具合を修正するパッチを作成してしまうケースも見られるようになってきており、誰のパッチが採用されるかという一番乗り競争っぽくなってきました。

posted by 熊猫さくら at 16:43| Comment(0) | TrackBack(0) | Linux

2020年11月22日

Tiny File Transmitter 0.11 が公開されました。

4GBよりも大きなファイルを扱えるようにしてほしいという要望がありましたので、およそ17年ぶりにP2P型のファイル転送ツールである Tiny File Transmitter のアップデートを行いました。

前回のリリースは TOMOYO Linux がオープンソース化されるよりも前だったので、コーディングスタイルにいろいろな癖がありましたが、今回のアップデートを行うにあたり、読みやすくするために Linux カーネルの流儀に修正しました。
また、当時はマルチスレッドの知識や経験が無かったので、安全サイドに倒すためにシングルプロセス/シングルスレッドで実装していたのですが、その代償として、長時間かかる処理をGUIのイベント処理ループの中に埋め込むために「 Go To トラベル」・・・じゃなくて「 goto ラベル」の嵐になっています。CUI環境向けのプログラミングではありえないようなスパゲッティ状態です。

結局、互換性を重視してファイルサイズを64ビットで扱うための改修だけに留めましたが、もし最初から作り直すのであればマルチプロセスでHTTP風のプロトコルにしていたと思います。

posted by 熊猫さくら at 14:08| Comment(0) | TrackBack(0) | Windows

2020年10月29日

OSSセキュリティ技術ワークショップ2020で syzbot の話をしました。

今年も相変わらず Linux カーネルのバグ退治をしています。

昨年講演した The SYZBOT CTF の「その後」ですが、1年半前の記事に書いた予想が現実になりつつある気がするので、「 syzbot に追い回される開発者たち?」というタイトルで苦労話を紹介しました。

25年前に追加されたコードに起因した不具合が発見されて、もう誰も使っていないだろうという理由で削除するとか、歴史を感じますね。

posted by 熊猫さくら at 01:04| Comment(0) | TrackBack(0) | Linux

2020年04月11日

Pacemaker で softdog を利用されている方へのお知らせ

kdump の設定をしているのであれば、 softdog カーネルモジュールをロードする際のパラメータに soft_panic=1 という指定を追加していただきますようお願いします。

■お知らせの背景

Pacemaker を使っているシステムが突然再起動したというお問合せは少なくありません。具体的な件数については把握していませんが、仮想化環境での発生事例が多いようです。残念なことに、ログファイルや sar を調査しても手がかりが残っておらず、原因不明のまま諦めざるを得ないという状態が何年も続いてきました。

RHEL6/CentOS6 以降の softdog カーネルモジュールには、タイムアウトの発生時に「システムを再起動させる」代わりに「カーネルパニックを発生させる」ための soft_panic というパラメータが存在しています。このパラメータを kdump の設定と組み合わせることで、タイムアウトの発生時に vmcore を取得することが可能になります。

vmcore にはタイムアウトが発生した時点の情報しか含まれないので、 vmcore を取得できればタイムアウトの原因を必ず突き止められるという訳ではありません。しかし、たくさんの事例を積み重ねることで、傾向を分析して対策を考えることはできるものと考えます。

■分析により見つかった問題点の例

Corosync main process was not scheduled for X ms (threshold is Y ms). Consider token timeout increase. というメッセージは、一般的には「カーネルが corosync プロセスにCPU時間を割り当てできなかった」という解釈/説明がされていますが、必ずしもカーネルやハードウェア側の問題を示唆している訳ではありません。1個のスレッドが様々な処理を行っているという corosync プロセスの構造上、「(カーネルは corosync プロセスにCPU時間を割り当てていたものの、 corosync プロセスが他の処理で忙しかったことにより、)このメッセージを出力するための関数を呼び出せるようになるまでに想定外の時間がかかっただけ」という可能性もあるのです。

このような問題が実際の業務負荷で発生しているのかどうかは、 vmcore を取得して確認してみないと判断できません。サポートセンタでは実際の業務負荷をかけることができないので、利用者の方々に vmcore の取得へのご協力をお願いする必要があります。

■NTT OSSセンタを利用されている方への補足

vmcore を送付できる場合には、サイズが数十GBのファイルであってもそのまま扱える「ファイルアップロード/ダウンロードシステム」をご利用ください。 vmcore を送付できない場合、あるいは、送付にかかる時間が勿体ないので自前で初期解析を行いたい場合には、 crash コマンドを用いて vmcore の初期解析を行う手順をご利用ください。詳細については、(NTT OSSセンタの契約者向けコンテンツである)「ナレッジの泉」を参照してください。

posted by 熊猫さくら at 14:31| Comment(0) | TrackBack(0) | Linux

2020年04月07日

RHEL7/CentOS7 で最新版 clamav のオンアクセススキャン機能を利用する手順について

先月 clamav パッケージが 0.102 にバージョンアップした際に、 RHEL 7 / CentOS 7 で提供されている curl のバージョンが古すぎることが原因で、 RHEL 7 / CentOS 7 向けの clamav におけるオンアクセススキャン機能が「突然」使えなくなってしまいました。

オンアクセススキャン機能を必要としている人は、業務で使っている人が多いと思うので、今すぐ RHEL 8 / CentOS 8 に乗り換えるという選択肢は難しいと思います。なので、既存環境への影響を最小限に抑えながら、 RHEL 7 / CentOS 7 環境でもオンアクセススキャン機能を使えるようにするための手順を作りました。

(1) ビルドに必要なパッケージを開発環境にインストールします。

# yum -y install gcc rpm-build yum-utils wget epel-release

(2) curl の最新版(記事作成時点では 7.69.1 )を開発環境でコンパイルします。

# wget https://curl.haxx.se/download/curl-7.69.1.tar.bz2 \
       https://curl.haxx.se/download/curl-7.69.1.tar.bz2.asc \
       https://daniel.haxx.se/mykey.asc
# gpg --import mykey.asc
# gpg curl-7.69.1.tar.bz2.asc
# tar -xf curl-7.69.1.tar.bz2
# cd curl-7.69.1
# ./configure --prefix=/usr/local/curl-7.69.1
# make
# make install

(3) clamav の最新版(記事作成時点では 0.102.2-4.el7 )を開発環境でコンパイルします。

# cd
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
# yumdownloader --source clamav
# rpm --checksig clamav-0.102.2-4.el7.src.rpm
# rpm -ivh clamav-0.102.2-4.el7.src.rpm
# yum-builddep -y ~/rpmbuild/SPECS/clamav.spec
# patch -d ~/rpmbuild/SPECS/ -p0 << "EOF"
--- clamav.spec
+++ clamav.spec
@@ -4,7 +4,7 @@

 ## Fedora Extras specific customization below...
 # EL7's curl is too old
-%if 0%{?fedora} || 0%{?rhel} >= 8
+%if 0%{?fedora} || 0%{?rhel} >= 7
 %bcond_without  clamonacc
 %else
 %bcond_with     clamonacc
@@ -264,6 +264,7 @@ export have_cv_ipv6=yes
 rm -rf libltdl autom4te.cache Makefile.in
 autoreconf -i
 %configure \
+    --with-libcurl=/usr/local/curl-7.69.1 \
     --enable-milter \
     --disable-clamav \
     --disable-static \
EOF
# rpmbuild -bb ~/rpmbuild/SPECS/clamav.spec

(4) 開発環境で作成したファイルを本番環境にコピーします。なお、開発環境と本番環境が同一の場合は不要です。

# tar -cf ~/curl+clamav.tar /usr/local/curl-7.69.1/ ~/rpmbuild/RPMS/x86_64/clamd-*.rpm \
          ~/rpmbuild/RPMS/x86_64/clamav-*.rpm ~/rpmbuild/RPMS/noarch/clamav-*.rpm
# tar -xf ~/curl+clamav.tar -C /

(5) 本番環境で clamav パッケージをインストールします。

# rpm -ivh ~/rpmbuild/RPMS/x86_64/clamd-0.102.2-4.el7.x86_64.rpm \
           ~/rpmbuild/RPMS/x86_64/clamav-0.102.2-4.el7.x86_64.rpm \
           ~/rpmbuild/RPMS/x86_64/clamav-lib-0.102.2-4.el7.x86_64.rpm \
           ~/rpmbuild/RPMS/noarch/clamav-data-0.102.2-4.el7.noarch.rpm \
           ~/rpmbuild/RPMS/noarch/clamav-filesystem-0.102.2-4.el7.noarch.rpm

(6) clamonacc が開発環境でコンパイルした curl ライブラリを参照する設定になっていることを確認します。

# objdump -p /usr/bin/clamonacc | grep curl
  NEEDED               libcurl.so.4
  RPATH                /usr/local/curl-7.69.1/lib

(7) 本番環境で必要な設定をしてから clamonacc を起動します。

# sed -i -e 's/^#TCP/TCP/' /etc/clamd.d/scan.conf
# systemctl start clamd@scan
# /usr/bin/clamonacc
posted by 熊猫さくら at 13:28| Comment(0) | TrackBack(0) | Linux

2020年01月06日

SECCON CTF 2019 Final での syzbot panic クイズについて

2019年は熊猫にとって syzbot イヤーだったので、CTFの Jeopardy 問題として1問だけ出題させていただきましたが、いや〜、ここまで酷評されるとは思っていませんでしたよ。(笑)

出題したのは以下の問題です。表面的には、目的のページやパッチを如何に効率よく見つけられるかを競う出題なのですが、その裏には気づいて/考えてもらいたい話を含めていました。

Solve 5 questions listed below, and submit concatenated answers in SECCON{$answer_for_Q1+$answer_for_Q2+$answer_for_Q3+$answer_for_Q4+$answer_for_Q5} format.
Hint: Total length of answer string in SECCON{$answer_for_Q1+$answer_for_Q2+$answer_for_Q3+$answer_for_Q4+$answer_for_Q5} format will be 73 characters.

(Q1) What is FQDN (in all lower characters) of a website that manages the state of bugs syzbot has found?

(Q2) What is SHA-1 (only first 10 characters, in lower hexadecimal format) of a commit that explains the following improvement?

syzbot was unable to parse Linux kernel's messages when multiple threads concurrently emitted kernel messages. As a result, many reports had been discarded as "corrupted" indicating that "something went wrong but syzbot could not understand what has happened". After this patch was merged, ability to understand what has happened improved significantly. This patch was written by Tetsuo Handa.

(Q3) What is SHA-1 (only first 10 characters, in lower hexadecimal format) of a commit that fixed the following problem?

A local unprivileged user was able to trigger soft lockup using a reproducer shown below. This patch was written by Linus Torvalds.

----------------------------------------
#define _GNU_SOURCE
#include <stdio.h>
#include <stdint.h>
#include <fcntl.h>
#include <pthread.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <unistd.h>
#include <termios.h>

static void *thr(void *arg)
{
        char c;
        read(*(int *) arg, &c, 1);
        return 0;
}

int main(int argc, char *argv[])
{
        char buf[sizeof(struct termios) + 64] = { };
        int zero = 0;
        int ptyno = 0;
        int fd = open("/dev/ptmx", O_RDONLY);
        int fd2;
        pthread_t th;
        buf[0x9] = 0xfd;
        buf[0xc] = buf[0xd] = buf[0xe] = buf[0xf] = buf[0x10] = 0xff;
        ioctl(fd, TCSETS, buf);
        ioctl(fd, TIOCSPTLCK, &zero);
        ioctl(fd, TCXONC, TCIOFF);
        if (ioctl(fd, TIOCGPTN, &ptyno))
                return -1;
        sprintf(buf, "/dev/pts/%d", ptyno);
        fd2 = open(buf, O_RDONLY);
        pthread_create(&th, 0, thr, &fd2);
        sleep(1);
        ioctl(fd2, FIONREAD, buf);
        return 0;
}
----------------------------------------

(Q4) What is SHA-1 (only first 10 characters, in lower hexadecimal format) of a commit that fixed the following problem?

Since passing arbitrary arguments to system calls as root user causes legitimate problems (e.g. hang up, reboot), fuzzers are currently forced to blacklist some arguments that legitimately damage the target. In April 2018, syzbot generated a report which confused developers because it was believed that arguments which are known to generate this report are blacklisted. But it turned out that syzbot was by error passing arguments which should have been blacklisted during the fuzz testing.

(Q5) What is SHA-1 (only first 10 characters, in lower hexadecimal format) of a commit that explains the following improvement?

Currently, syzbot might by error generate C reproducer programs using incorrect structure definition (e.g. "struct serial_struct"). Therefore, a utility to validate correctness of structure definition was added.

正解は SECCON{syzkaller.appspot.com+15ff2069cb+966031f340+06c33b3af0+64ca0a3711} です。

1問目は、2問目以降を解いていくためのヒントとなるページへの誘導です。 syzbot でググれば一発でヒットするでしょう。

2問目は、ファジングツールにとって悩みの種であった、カーネルメッセージを読みやすくする改善の話題です。1問目で syzbot というキーワードでググった際に syzkaller.appspot.com を見つけて、逃げるsyzbot、追うカーネル開発者たちをスルーしてしまったチームにとっては、目的のパッチを見つけるまでにちょっと回り道してもらうことになったのではないかと思います。
不具合退治の舞台裏に興味を持ってもらいたくて、出題しました。詳細は The SYZBOT CTF を参照いただければと思います。

3問目は、ファジングツールは、 root ユーザの権限が無くてもシステムをダウンさせてしまうことのある不具合を見つける場合があるということを知ってもらう問題です。発見される不具合の多くは root ユーザの権限が無いと遭遇しないのですが、たまに一般ユーザの権限でも遭遇できてしまう不具合が発見されることがあります。そのため、「このシステムでは管理者権限を与えないから、ファジングテストで見つかった不具合を心配しないで大丈夫」と問題を甘く見ないことが求められます。この問題は、 syzbot が見つけたC言語の再現プログラムを、熊猫が単純化して security@kernel.org に投げて、非公開の議論を経て修正されました。

4問目は、ファジングで使うテストケース作成の難しさについて知ってもらう問題です。 root ユーザの権限があれば不具合を攻撃しなくても合法的にシステムを停止させることができてしまうので、合法的にシステムを停止させてしまうような操作は、テストケースから除外するという対処をしています。この問題ではテストケースから除外しているつもりが除外できていなかったという話題を扱いましたが、実際にはテストケースから除外することは容易ではありません。テストケースから除外することなく対処する方法として、テストケースを root ユーザの権限ではなく一般ユーザの権限で動作させるという方法も提案されていますが、多くの不具合を発見できなくなってしまいます。
そのため、ファジングテストのためのカーネルでは、合法的にシステムを停止させてしまうような操作をカーネル側で拒否できるようにするという提案が現在進行中です。

5問目は、ファジングの凄まじさを知ってもらう問題です。 syzbot は、C言語で記述された再現プログラムを提示してくれるのですが、熊猫が問題を解析しようとして再現プログラムの「読める化(ローカル変数や構造体などを用いて書き直す)」作業をしたところ、構造体を用いると問題が再現しなくなるという不思議な現象に遭遇しました。調査したところ、 syzbot が使用している構造体の定義が間違っている(構造体を間違えた状態のままクラッシュさせることが可能なパラメータの組み合わせを見つけてしまった)という予想外の出来事がありました。構造体のメンバの役割を知らずとも動作できるということなんですね。

出題には至りませんでしたが、12月の出来事として、クラッシュ発生回数トップの座に君臨していた不具合である unregister_netdevice: waiting for DEV to become free (2) が open 状態から fix pending 状態に遷移しました。(注:異なる不具合がこの事象として報告されているため、実際にはまだ終わっていません。)
不具合を修正するパッチには、不具合を報告してくれた人へのクレジット(謝意)として、報告者の名前を含めることが期待されるのですが、パッチの作成者は、必ずしも報告者の名前を含めてくれるとは限りません。その結果、 syzbot が発見した不具合が修正済みなのかどうかを追跡することが難しいという問題があります。この不具合の場合、グーグルさんのボットが見つけた不具合なのに、何故かファーウェイさんのボットが見つけたことにされているパッチに対して「誰?」ってツッコミを入れました。こんなところにも、グーグル対ファーウェイの競争が現れているのでしょうか?(笑)

さて、熊猫が扱っている領域って、CTFの攻防戦には不向きなんですよねぇ。いくつ発見できるか不明な未知の不具合を探したり、どれくらい修正が難しいか予想できない不具合を修正するパッチを書いたりしてもらうという出題にすると、誰も回答不能/出題者側も採点不能という状況に陥りかねません。可視化するためには機械的に採点が可能なフラグ文字列を使わざるを得ないのですが、扱う不具合の内容がプロセスの異常終了/ハングアップ/カーネルパニックなどである以上、フラグ文字列を表示させることや、現在誰が占有しているのかを判断することが非常に困難なのです。その結果、今回はパッチを探すという Jeopardy 問題になりました。CTF競技者にとっては、非常につまらない出題だったかと思いますが、 syzbot の世界は、頭がパニックになりそうなくらいに、予想外の出来事の連続なのです。

posted by 熊猫さくら at 19:24| Comment(0) | TrackBack(0) | Linux

2019年08月18日

セキュリティ・キャンプ2019で使用した、熊猫のテキストを公開しました。

熊猫がプログラミングに出会ってから25年となった今年は、不具合を修正できるようにするための試行錯誤について扱いました。

不具合を踏んでクラッシュした場合、メモリダンプを取得して原因を解析することが多いかと思います。しかし、 syzbot を用いたファジングテストでは、メモリダンプを取得することが(現時点では)不可能です。また、ハングアップやストールの場合は、仮にメモリダンプを取得できたとしても、時間経過に伴う状態変化をメモリダンプから知ることはできないという限界があります。そのため、 printf() デバッグに頼らざるを得ない訳ですが、複数のスレッドが同時に printf() を呼んでしまうことで複数のメッセージが混ざってしまい、個々のメッセージを解析できなくなるという問題もあります。

そんな厳しい状況で、問題が発生した時に必要な情報をいかにして取得できるようにするかという、とても複雑で面倒な問題に熊猫は取り組んできました。講義資料は、( Linux カーネルにおける printf() に相当する)printk() を巡る試行錯誤をメインに、メモリ管理サブシステム開発者との大バトルや、ある不具合が修正されたと思ったら別の不具合が発見されたりする沼など、盛りだくさんです。とても4時間では紹介しきれません〜。(笑)

今年は、担当講義の時間以外はZトラックにお邪魔していたため、思わず突っ込む側になってしまいました。熊猫はマルウェアを解析した経験はありませんが、講義の中で strace による動的解析が紹介されていたので、ちゃっかり AKARI による追跡手法を紹介することができました。

posted by 熊猫さくら at 20:10| Comment(0) | TrackBack(0) | Linux

2019年04月27日

Google Open Source Peer Bonus を受賞しました。

サポートセンタに勤務していた時に偶然発見してしまったメモリ管理の闇が原因で、現在でも Linux カーネルのバグハンティングを続けている訳ですが、ここ1年半ほど syzbot が見つけた不具合を退治していたところ、その貢献により Google Open Source Peer Bonus を受賞してしまいました。

受賞理由の1つでもある printk() の改善が来月公開される Linux 5.1 に含まれることから、今年のセキュリティ・キャンプ全国大会では、この体験談を The SYZBOT CTFとして語ることになっています。

3年前のセキュリティ・キャンプ全国大会で語った The OOM CTF では、受講者全員の思考が停止してしまうほどの脳内 Denial of Service 攻撃になってしまいました。
現在、今年の講義で取り上げるトピックを探すためにメールのアーカイブを読み返しているところなのですが、対象範囲がメモリ管理サブシステムだけでなく Linux カーネル全体となっています。そのため、今年は3年前を超える難易度となっており、果たして受講希望者が現れてくれるのかどうか心配しています。まずはキャンプに参加してくれないことには始まりませんので、たくさんの応募をお待ちしております。

posted by 熊猫さくら at 15:57| Comment(2) | TrackBack(0) | Linux

2018年12月30日

SECCON 2018 国際決勝 CTF での Programming Quiz について

先週開催された SECCON 2018 でのCTFで、プログラミング/システム管理に関するクイズを出題しました。一見すると「え?そんなの不可能では?」と思われる内容の詰め合わせです。その際に使用した環境を再構築するための tar ball が公開されていますので、興味のある方はお試しください。ヒントは server5-hints.txt に、想定解法は steps.txt に書いてあります。

SECCON 2015 オンライン CTF のときはガチガチに制限された環境でしたが、今回は King Of the Hill 形式の攻防戦ということで、できるだけ制限の緩い環境で遊んでもらうことにしました。以下が、使用した CaitSith のポリシーです。 strace 等を使うと一瞬で正解できてしまうので、 CaitSith の他に、 ptrace を制限するモジュールも併用しました。

POLICY_VERSION=20120401
quota memory audit 16777216
quota memory query 1048576
quota audit[0] allowed=0 denied=1024 unmatched=0

10 acl execute task.uid=10000-100000
    audit 0
    10 deny path.perm=setuid
    10 deny path.perm=setgid path.gid!=1000-1007
    20 allow

10 acl read path.fsmagic=0x9FA0 task.uid=10000-100000 path.uid=10000-100000 task.uid!=path.uid
    audit 1
    10 deny

10 acl environ task.uid=1000-65535
    audit 0
    10 allow name="_"
    10 allow name="COLLECT_GCC"
    10 allow name="COLLECT_GCC_OPTIONS"
    10 allow name="COLLECT_LTO_WRAPPER"
    10 allow name="COMPILER_PATH"
    10 allow name="HOME"
    10 allow name="LANG"
    10 allow name="LESSOPEN"
    10 allow name="LIBRARY_PATH"
    10 allow name="LOGNAME"
    10 allow name="LS_COLORS"
    10 allow name="MAIL"
    10 allow name="OLDPWD"
    10 allow name="PATH"
    10 allow name="PWD"
    10 allow name="PYTHONINSPECT"
    10 allow name="SHELL"
    10 allow name="SHLVL"
    10 allow name="SSH_CLIENT"
    10 allow name="SSH_CONNECTION"
    10 allow name="SSH_ORIGINAL_COMMAND"
    10 allow name="SSH_TTY"
    10 allow name="TERM"
    10 allow name="USER"
    10 allow name="XDG_RUNTIME_DIR"
    10 allow name="XDG_SESSION_ID"
    10 allow name="LC_CTYPE"
    10 allow name="LC_ALL"
    10 allow name="LC_NUMERIC"
    10 allow name="LC_TIME"
    10 allow name="LC_COLLATE"
    10 allow name="LC_MONETARY"
    10 allow name="LC_MESSAGES"
    10 allow name="LC_PAPER"
    10 allow name="LC_NAME"
    10 allow name="LC_ADDRESS"
    10 allow name="LC_TELEPHONE"
    10 allow name="LC_MEASUREMENT"
    10 allow name="LC_IDENTIFICATION"
    10 allow name="LANGUAGE"
    10 allow name="XMODIFIERS"
    10 allow name="HOSTNAME"
    10 allow name="LINES"
    10 allow name="MAN_NO_LOCALE_WARNING"
    10 allow name="MAN_ORIG_LESS"
    10 allow name="LESSCHARSET"
    10 allow name="COLUMNS"
    10 allow name="MAN_PN"
    10 allow name="GROFF_BIN_PATH"
    10 allow name="HISTSIZE"
    10 allow name="LESS"
    20 deny

さて、1日目の競技が終了した時点で、チームDCUAから「問題サーバにバグがある」という指摘がありました。 /bin/seccon_login を root:seccon で 4710 にしていたのですが、 seccon ユーザのパスワードが既知なので、 su - seccon で再び seccon ユーザになってから環境変数 SSH_CONNECTION を書き換えて /bin/seccon_login を実行することにより、任意のチームとしてログインできてしまうという指摘でした。

なりすましログインにより他チームが解いたクイズの答えを盗み見たり、自チーム以外はじゃんけんに参加しないようにしたりすることができてしまうため、事実上サーバ5を占拠し続けることができてしまうバグです。

普通はセキュアOSをガチガチに固めるために使用するものですが、今回はできるだけユルユルに使うことを目標としていたため、sshログイン以外の方法で seccon ユーザになれるということを見落としていたのです。そのため、2日目の競技開始前に、クイズに不要な setuid / setgid プログラムの実行許可を与えないようにするというポリシー修正(上記の 10 acl execute task.uid=10000-100000 エントリ部分の追加)を行いました。

まぁ、攻防戦としては「気づいたもの勝ち」という点で、なりすましができるままにしておいたほうが面白かったかもしれませんが。

posted by 熊猫さくら at 23:36| Comment(0) | TrackBack(0) | CaitSith

2018年08月21日

セキュリティ・キャンプ2018で使用した、熊猫のテキストを公開しました。

直ちにアップデートを適用するなどの対処を迫られるような影響範囲の大きな脆弱性が増えてきている感触がある昨今、自分が管理している Linux システムの概要を知っておくことは、障害や脆弱性への対処を行う上で有用であると考えます。

そこで、今年のキャンプでは、サポートセンタで故障解析に携わった経験を基に、 Linux システムに関するトラブルをOS視点で調査しながら、スムーズな問題解決を行うために必要なことについて扱いました。演習で使用した仮想マシンイメージ( SHA256: f139fe85117d871ff1e87ab79b9ac891555b097f8bf6976f50a051920a687967 )も公開していますので、実際に手を動かして体験してみてください。

ちなみに、同日に開催されたセキュリティ・コアキャンプ2018の方では、一昨年度の講義で扱ったメモリ管理の闇と、その後の2年間でどこまで進んだのかについて扱いました。振り返ってみると、「しょ〜もないミス」を繰り返しているんだなぁと感じます。

posted by 熊猫さくら at 20:11| Comment(0) | TrackBack(0) | Linux