Linux Kernel CVE-2018-12232 の Poc を書いて検証・観察した

表題の通り CVE-2018-12232 の PoC を書いてどのような影響があるのを検証・観察した

CVE の Description

CVE-2018-12232 は Linux Kernel に付いた CVE です

In net/socket.c in the Linux kernel through 4.17.1, there is a race condition between fchownat and close in cases where they target the same socket file descriptor, related to the sock_close and sockfs_setattr functions. fchownat does not increment the file descriptor reference count, which allows close to set the socket to NULL during fchownat's execution, leading to a NULL pointer dereference and system crash.

net/socket.c in のレースコンディションで NULL ポインタ参照が起きてカーネルパニックします

修正パッチ

From 6d8c50dcb029872b298eea68cc6209c866fd3e14 Mon Sep 17 00:00:00 2001
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 7 Jun 2018 13:39:49 -0700
Subject: socket: close race condition between sock_close() and
 sockfs_setattr()

fchownat() doesn't even hold refcnt of fd until it figures out
fd is really needed (otherwise is ignored) and releases it after
it resolves the path. This means sock_close() could race with
sockfs_setattr(), which leads to a NULL pointer dereference
since typically we set sock->sk to NULL in ->release().

As pointed out by Al, this is unique to sockfs. So we can fix this
in socket layer by acquiring inode_lock in sock_close() and
checking against NULL in sockfs_setattr().

sock_release() is called in many places, only the sock_close()
path matters here. And fortunately, this should not affect normal
sock_close() as it is only called when the last fd refcnt is gone.
It only affects sock_close() with a parallel sockfs_setattr() in
progress, which is not common.

Fixes: 86741ec25462 ("net: core: Add a UID field to struct sock.")
Reported-by: shankarapailoor <shankarapailoor@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 net/socket.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/net/socket.c b/net/socket.c
index af57d85bcb48..8a109012608a 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -541,7 +541,10 @@ static int sockfs_setattr(struct dentry *dentry, struct iattr *iattr)
    if (!err && (iattr->ia_valid & ATTR_UID)) {
        struct socket *sock = SOCKET_I(d_inode(dentry));

-      sock->sk->sk_uid = iattr->ia_uid;
+       if (sock->sk)
+           sock->sk->sk_uid = iattr->ia_uid;
+       else
+           err = -ENOENT;
    }

    return err;
@@ -590,12 +593,16 @@ EXPORT_SYMBOL(sock_alloc);
  * an inode not a file.
  */

-void sock_release(struct socket *sock)
+static void __sock_release(struct socket *sock, struct inode *inode)
 {
    if (sock->ops) {
        struct module *owner = sock->ops->owner;

+       if (inode)
+           inode_lock(inode);
        sock->ops->release(sock);
+       if (inode)
+           inode_unlock(inode);
        sock->ops = NULL;
        module_put(owner);
    }
@@ -609,6 +616,11 @@ void sock_release(struct socket *sock)
    }
    sock->file = NULL;
 }
+
+void sock_release(struct socket *sock)
+{
+   __sock_release(sock, NULL);
+}
 EXPORT_SYMBOL(sock_release);

 void __sock_tx_timestamp(__u16 tsflags, __u8 *tx_flags)
@@ -1171,7 +1183,7 @@ static int sock_mmap(struct file *file, struct vm_area_struct *vma)

 static int sock_close(struct inode *inode, struct file *filp)
 {
-  sock_release(SOCKET_I(inode));
+   __sock_release(SOCKET_I(inode), inode);
    return 0;
 }

--
cgit 1.2-0.3.lf.el7

分析 🔎

PoC を書く場合はパッチで修正された箇所のコードを実行するように Attack Surface を選び出して適切なパラメータを送り込めばよい

一言でいえばそうなのだが、 sockfs_setattr() を呼び出すのが難しく 自力では全然思い付けなかった。通常のファイルシステムと違い socket を扱うための sockfs はディレクトリをつくれないので、 Attack Surface となるシステムコールから呼び出すのに一工夫が必要なのである。脆弱性情報に記載されたリンクを眺めていって、ヒントを得てから解決することができた。

ローカルからの攻撃でしか発火しないので、一般的な構成の Web アプリケーションを動かすホストでは影響しないだろう

PoC のソース

悪いことに exploit されると大変なので非公開です。もったいぶってるわけではないですよ。

再現 🔥

脆弱性を抱えたカーネルをインストールして VirtualBox 上で再現をとった

f:id:hiboma:20180918144308p:plain

  • Attack Surface となるシステムコールやファイルはよく使うものなので、seccomp や Apparmor 等での緩和策では通常のアプリケーションの動作に支障をきたす可能性がありそうです。もし問題があるカーネルがあるならば、素直にカーネルアップデートするのが確実
  • PoC 実行後、数秒で再現が取れる。レースコンディションの条件としてはさほど複雑でないようだ

感想

  • CVE やパッチから PoC を書くのはテストケースを書くのにも似たところがある。修正パッチを見て、問題となっている箇所のコードカバレッジを 100 % にするように Attack Surface を選択してコードを書いてから、更にパラメータを調整していくのがポイントなのだ ... ! と肌感でわかってきた
  • PoC を書くにあたって必然的に man や周辺のカーネルソースを読み解いていくことになるので、 システムコールインタフェースや Linux カーネルの勉強にもなっている。問題を再現しながら学習を深めるのは自分に向いてる感じがする
  • 再現できると「やったー」という気分になるが、うっかり PoC をどこかに晒さないよう倫理観が必要だなぁ