링크된 글의 작성자인 Sam James는 Gentoo 개발자임
어쨌든 이건 재앙에 가깝고, 배포판들이 수정본을 배포하기 전에 exploit을 공개한 건 매우 무책임했음
이걸로 얼마나 많은 shared hosting 업체가 해킹됐을지 알 수 없음
또한 kernel security team과 배포판 maintainer 사이에 소통이 없어 보인다는 점도 걱정됨
전자가 후자에게 알릴 거라고 기대하게 되지만, 실제로는 취약점을 찾은 사람이 책임져야 하는 구조처럼 보임
보고한 대상에 패치가 들어간 뒤 30일 후 공개하는 것 자체에는 문제가 없다고 봄
참고로 Google Project Zero도 비슷하게 “90+30” 정책을 씀: https://projectzero.google/vulnerability-disclosure-policy.h...
진짜 문제는 kernel security team과 배포판 maintainer 사이에 소통 채널이 없다는 점임
취약점을 발견한 사람이 모든 downstream에 따로 보고할 책임을 져서는 안 됨
kernel 팀이 배포판 보안 담당자 목록에 패치의 중요도와 30일 뒤 공개 일정을 알려야 했음
이번 공개는 보안보다 마케팅에 가까웠음
공개 페이지에도 “Is your software AI-era safe?”, “Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem”, “[Try Xint Code]” 같은 문구가 있음
혼란이 커질수록 제품이 더 매력적으로 보이게 만드는 방식임
사용자이자 관리자로서는 “매우 무책임했다”는 데 동의하지 않음 Responsible Disclosure라는 표현은 “Secure Boot”처럼 언어적으로 잘 설계된 표현이고, 실제로는 내 컴퓨터와 나 사이에 있는 기업·재단 중간 조직들의 평판 관리를 위한 것처럼 보임
그들은 내 개별 컴퓨터가 취약한지보다 “RHEL이 취약하다”, “Ubuntu가 취약하다”는 말을 못 하게 하는 데 관심이 있음
취약점은 어차피 존재하므로, 조용히 수정되기만 기다리기보다 위험을 알고 줄일 기회가 있는 편이 낫다고 봄
즉각적인 공개만이 무책임하지 않은 선택이라고 생각함
공개 절차 자체에 대한 입장을 떠나, 이걸로 해킹당한 hosting provider라면 이미 질 수밖에 없는 구조였음
서로 신뢰하지 않는 tenant workload를 단일 shared kernel 아래에서 돌리는 건 괜찮지 않음
Kernel LPE는 드문 일이 아니고, 이번 건 특히 단순하고 이식성이 좋았을 뿐이며 원시 capability 자체는 CNE commodity에 가까움
Linux kernel은 보안 경계로 쓰기에 적합하지 않음
shared hosting을 하면서 해킹당하지 않으려면 gVisor나 Firecracker VM 같은 다른 수단을 써야 함
이를 보안 경계로 쓰는 중요한 시스템은 Android 정도인데, APK 설치에 사용자 승인, 엄격한 SELinux와 seccomp 정책, GrapheneOS hardening이 있어 완화됨
이번 경우에도 완화가 성공했음: https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...
“Linux kernel 취약점의 경우 reporter가 linux-distros ML에 직접 가져가지 않는 한 배포판에 사전 알림이 없다”는 식으로 말하는 이유가 이해되지 않음
reporter가 배포판들과 직접 조율해야 한다는 건 Linux 프로젝트에 대한 높은 수준의 지식을 전제로 함
취약점 제보자가 Linux kernel의 모든 downstream 소비자와 직접 일할 책임을 져서는 안 됨
그렇게 따지면 Linux를 장비에 쓰는 모든 제조사에도 직접 연락해야 하나 싶음
제보자는 Linux에 책임 있게 공개하고 패치가 들어갈 때까지 기다린 것만으로도 충분히 했다고 봄
Linux 프로젝트 내부에 보안 취약점에 대한 권한과 책임을 가진 사람들이 있어야 하고, downstream distro에 알리는 일도 그들이 해야 한다고 생각함
특히 reporter에게 배포판 팀에 먼저 알리지 말라고 명시적으로 요청한다는 점에서 더 그렇다 https://docs.kernel.org/process/security-bugs.html As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.
reporter가 자기 웹사이트에서 Ubuntu/RHEL/SUSE 같은 특정 배포판을 확인해 언급할 시간은 있었음
적어도 그 배포판들의 보안팀에는 알리는 게 책임 있는 행동이었을 것 같음
reporter가 Ubuntu, RedHat, Amazon, SUSE를 명시적으로 지목하는 웹사이트를 만들고도 그들에게 알리지 않은 게 합리적이라고 보기는 어려움
그 배포판들이 kernel 팀의 downstream이라는 걸 몰랐을 리도 없어 보임
필수 요건은 아닐 수 있지만, reporter들이 안전한 remediation보다 유명세에 더 관심이 있었기 때문에 모두가 더 고통받게 됐다고 봄
reporter 탓을 그만하고 kernel 프로세스를 고치라고 요구해야 함
Linux kernel은 더 이상 장난감 프로젝트가 아니고, 여러 회사에 고용된 full-time 직원들이 있음
배포판에 알리는 일은 임의의 개인이 아니라 그들이 처리했어야 함
발표용, 사실상 마케팅용 블로그 글에서 특정 distro들을 affected로 이름까지 찍었다면, 공개 전에 heads-up을 주는 게 적절하고 기대되는 행동이라고 봄
RHEL 14 같은 언급을 그렇게 넣지 않았다면 이렇게까지 비난받지는 않았을 것 같음
이건 개인 보안 연구자나 학계가 아니라, 전문적인 커뮤니케이션 부서를 둔 보안 회사가 distro maintainer를 겨냥해 손가락질한 상황임
배포판과 kernel 개발자들이 high severity 패치에 대해 소통하고 빠르게 움직여야 하는 건 맞음
하지만 reporter가 그 일이 일어나기를 기다리지 않았기 때문에 실제 사람들이 피해를 입었을 수 있고, 그 책임은 reporter에게 있음
취약점을 보고하는 것과, 아무나 가져다 쓸 수 있는 강력한 exploit을 공개하는 건 전혀 다른 문제임
주요 distro에 먼저 알리지 않고 세상에 풀어놓은 건 무책임했음
nosuid와 아마 nodev는 기본 filesystem mount option이어야 한다고 봄 /dev는 이미 특수한 devtmpfs이고, initrd의 최소 /dev는 필요하다면 initrd tmpfs rootfs를 dev와 suid로 명시적으로 mount하면 됨
SUID binary가 아무 데나 “존재”할 수 있게 두는 건 큰 보안 위험임
외부 저장매체를 mount했을 때 그 block device 안의 SUID binary들이 악성인지 어떻게 검증할 수 있나 싶음
게다가 이 exploit은 SUID binary를 실행하는 사용자가 그 binary를 읽을 수도 있어야 동작하는 것으로 보임
non-root 사용자가 SUID binary에 read 권한을 가질 이유는 없음 NixOS는 이걸 올바르게 처리함
일반 패키지 설치 디렉터리인 /nix/store에는 SUID가 없고, 패키지가 그 밖으로 새지 않기 때문에 다른 mountpoint에는 안전하게 nosuid를 쓸 수 있음
예외는 executable-only SUID wrapper만 안전하게 담는 단일 목적의 /run/wrappers.$hash 디렉터리뿐임
나도 suid를 싫어하지만, 여기서 suid가 본질적인 문제는 아님
exploit되는 버그는 사실상 임의의 page cache poisoning을 가능하게 함
그 시점이면 이미 게임이 끝난 상태이고, suid 프로그램을 patch하는 건 root shell을 얻는 가장 쉬운 방법일 수는 있어도 유일한 방법은 아님
proof of concept exploit은 말 그대로 한 가지 공격 벡터를 보여주기 위한 것일 뿐임
다른 방법은 많음
개념 증명 exploit만 막는 것이 목표라면 blacklist 같은 더 쉬운 방법도 있지만, 그게 더 안전하게 만들어 주지는 않음
이 취약점으로는 page cache를 조작할 수 있음 ld.so를 조작해 임의 system call에 hook을 걸거나, uid를 0으로 바꾸거나, 그 외 여러 방식으로 권한 상승이 가능함
mount point는 이 문제와 관련이 없음
물론 사용자 쓰기 가능 영역에서 suid를 막고 suid 파일 읽기를 막는 건 늘 좋은 생각이지만, 그건 다른 이유 때문임
NixOS도 이 취약점을 고치지 못하며 다른 배포판과 마찬가지로 취약함
read 권한이 없으면 binary를 실행할 수 없고, 그건 말이 되지 않음
binary를 실행하려면 디스크에서 읽어 메모리에 로드해야 함
실제로 특정 binary에 read 권한은 있지만 executable 권한이 없다면 linker를 직접 호출해 실행할 수도 있음
예를 들어 /bin/ld.so.1 /path/to/binary처럼 호출하면 linker가 binary를 읽고 로드한 뒤 exec() 호출 없이 entry point로 점프함
이 workaround는 영향받은 코드가 모듈로 컴파일된 kernel에만 적용됨
RHEL, Fedora, Gentoo는 모두 이 코드를 kernel에 직접 빌드하도록 설정되어 있음
패치나 config 변경이 없으면, Sam이 Gentoo에서 암시했듯이 해당 배포판들은 계속 취약함
RedHat과 그 파생 배포판에서는 영향받은 코드가 모듈이 아니라 static으로 컴파일되어 있어서 이 대응책이 동작하지 않음
Hacker News 의견들
링크된 글의 작성자인 Sam James는 Gentoo 개발자임
어쨌든 이건 재앙에 가깝고, 배포판들이 수정본을 배포하기 전에 exploit을 공개한 건 매우 무책임했음
이걸로 얼마나 많은 shared hosting 업체가 해킹됐을지 알 수 없음
또한 kernel security team과 배포판 maintainer 사이에 소통이 없어 보인다는 점도 걱정됨
전자가 후자에게 알릴 거라고 기대하게 되지만, 실제로는 취약점을 찾은 사람이 책임져야 하는 구조처럼 보임
참고로 Google Project Zero도 비슷하게 “90+30” 정책을 씀: https://projectzero.google/vulnerability-disclosure-policy.h...
진짜 문제는 kernel security team과 배포판 maintainer 사이에 소통 채널이 없다는 점임
취약점을 발견한 사람이 모든 downstream에 따로 보고할 책임을 져서는 안 됨
kernel 팀이 배포판 보안 담당자 목록에 패치의 중요도와 30일 뒤 공개 일정을 알려야 했음
공개 페이지에도 “Is your software AI-era safe?”, “Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem”, “[Try Xint Code]” 같은 문구가 있음
혼란이 커질수록 제품이 더 매력적으로 보이게 만드는 방식임
Responsible Disclosure라는 표현은 “Secure Boot”처럼 언어적으로 잘 설계된 표현이고, 실제로는 내 컴퓨터와 나 사이에 있는 기업·재단 중간 조직들의 평판 관리를 위한 것처럼 보임
그들은 내 개별 컴퓨터가 취약한지보다 “RHEL이 취약하다”, “Ubuntu가 취약하다”는 말을 못 하게 하는 데 관심이 있음
취약점은 어차피 존재하므로, 조용히 수정되기만 기다리기보다 위험을 알고 줄일 기회가 있는 편이 낫다고 봄
즉각적인 공개만이 무책임하지 않은 선택이라고 생각함
서로 신뢰하지 않는 tenant workload를 단일 shared kernel 아래에서 돌리는 건 괜찮지 않음
Kernel LPE는 드문 일이 아니고, 이번 건 특히 단순하고 이식성이 좋았을 뿐이며 원시 capability 자체는 CNE commodity에 가까움
shared hosting을 하면서 해킹당하지 않으려면 gVisor나 Firecracker VM 같은 다른 수단을 써야 함
이를 보안 경계로 쓰는 중요한 시스템은 Android 정도인데, APK 설치에 사용자 승인, 엄격한 SELinux와 seccomp 정책, GrapheneOS hardening이 있어 완화됨
이번 경우에도 완화가 성공했음: https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...
“Linux kernel 취약점의 경우 reporter가 linux-distros ML에 직접 가져가지 않는 한 배포판에 사전 알림이 없다”는 식으로 말하는 이유가 이해되지 않음
reporter가 배포판들과 직접 조율해야 한다는 건 Linux 프로젝트에 대한 높은 수준의 지식을 전제로 함
취약점 제보자가 Linux kernel의 모든 downstream 소비자와 직접 일할 책임을 져서는 안 됨
그렇게 따지면 Linux를 장비에 쓰는 모든 제조사에도 직접 연락해야 하나 싶음
제보자는 Linux에 책임 있게 공개하고 패치가 들어갈 때까지 기다린 것만으로도 충분히 했다고 봄
Linux 프로젝트 내부에 보안 취약점에 대한 권한과 책임을 가진 사람들이 있어야 하고, downstream distro에 알리는 일도 그들이 해야 한다고 생각함
https://docs.kernel.org/process/security-bugs.html
As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.적어도 그 배포판들의 보안팀에는 알리는 게 책임 있는 행동이었을 것 같음
그 배포판들이 kernel 팀의 downstream이라는 걸 몰랐을 리도 없어 보임
Google 검색만 해도 나옴: https://share.google/aimode/eihDKXZJy94Z5lC1p
이걸 생각하지 않고 모두를 exploit에 노출시키는 건 이해하기 어렵고, 일부 법역에서는 중범죄여도 이상하지 않다고 봄
disclosure와 관련해 가장 흥미로운 교환은 이 링크에 있음
https://www.openwall.com/lists/oss-security/2026/05/01/3
“우리는 누구에게도 사전에 알릴 수 없다. 그러면 모든 것에 대해 모두에게 알려야 하기 때문이다. 법률·정부 기관들이 우리가 운영할 수 있도록 동의한 유일한 정책이 그것이라 어쩔 수 없다”는 greg k-h의 답변임
reporter 탓을 그만하고 kernel 프로세스를 고치라고 요구해야 함
Linux kernel은 더 이상 장난감 프로젝트가 아니고, 여러 회사에 고용된 full-time 직원들이 있음
배포판에 알리는 일은 임의의 개인이 아니라 그들이 처리했어야 함
RHEL 14 같은 언급을 그렇게 넣지 않았다면 이렇게까지 비난받지는 않았을 것 같음
이건 개인 보안 연구자나 학계가 아니라, 전문적인 커뮤니케이션 부서를 둔 보안 회사가 distro maintainer를 겨냥해 손가락질한 상황임
하지만 reporter가 그 일이 일어나기를 기다리지 않았기 때문에 실제 사람들이 피해를 입었을 수 있고, 그 책임은 reporter에게 있음
주요 distro에 먼저 알리지 않고 세상에 풀어놓은 건 무책임했음
AF_ALG가 모듈이 아니라 kernel에 직접 링크된 kernel을 쓰는 사람들을 위해 eBPF 기반 workaround를 올렸음: https://github.com/Dabbleam/CVE-2026-31431-mitigation
지금 production에서 돌리고 있고 공격을 완화하며, 지금까지 예상치 못한 부작용은 보이지 않음
nosuid와 아마nodev는 기본 filesystem mount option이어야 한다고 봄/dev는 이미 특수한 devtmpfs이고, initrd의 최소/dev는 필요하다면 initrd tmpfs rootfs를dev와suid로 명시적으로 mount하면 됨SUID binary가 아무 데나 “존재”할 수 있게 두는 건 큰 보안 위험임
외부 저장매체를 mount했을 때 그 block device 안의 SUID binary들이 악성인지 어떻게 검증할 수 있나 싶음
게다가 이 exploit은 SUID binary를 실행하는 사용자가 그 binary를 읽을 수도 있어야 동작하는 것으로 보임
non-root 사용자가 SUID binary에 read 권한을 가질 이유는 없음
NixOS는 이걸 올바르게 처리함
일반 패키지 설치 디렉터리인
/nix/store에는 SUID가 없고, 패키지가 그 밖으로 새지 않기 때문에 다른 mountpoint에는 안전하게nosuid를 쓸 수 있음예외는 executable-only SUID wrapper만 안전하게 담는 단일 목적의
/run/wrappers.$hash디렉터리뿐임exploit되는 버그는 사실상 임의의 page cache poisoning을 가능하게 함
그 시점이면 이미 게임이 끝난 상태이고, suid 프로그램을 patch하는 건 root shell을 얻는 가장 쉬운 방법일 수는 있어도 유일한 방법은 아님
다른 방법은 많음
개념 증명 exploit만 막는 것이 목표라면 blacklist 같은 더 쉬운 방법도 있지만, 그게 더 안전하게 만들어 주지는 않음
이 취약점으로는 page cache를 조작할 수 있음
ld.so를 조작해 임의 system call에 hook을 걸거나, uid를 0으로 바꾸거나, 그 외 여러 방식으로 권한 상승이 가능함mount point는 이 문제와 관련이 없음
물론 사용자 쓰기 가능 영역에서 suid를 막고 suid 파일 읽기를 막는 건 늘 좋은 생각이지만, 그건 다른 이유 때문임
NixOS도 이 취약점을 고치지 못하며 다른 배포판과 마찬가지로 취약함
binary를 실행하려면 디스크에서 읽어 메모리에 로드해야 함
실제로 특정 binary에 read 권한은 있지만 executable 권한이 없다면 linker를 직접 호출해 실행할 수도 있음
예를 들어
/bin/ld.so.1 /path/to/binary처럼 호출하면 linker가 binary를 읽고 로드한 뒤exec()호출 없이 entry point로 점프함아래 Bleeping Computer 링크에 패치가 준비될 때까지의 잠재적 대응책이 나와 있음
https://www.bleepingcomputer.com/news/security/new-linux-cop...
RHEL, Fedora, Gentoo는 모두 이 코드를 kernel에 직접 빌드하도록 설정되어 있음
패치나 config 변경이 없으면, Sam이 Gentoo에서 암시했듯이 해당 배포판들은 계속 취약함
NixOS도 알림을 받지 못했음
https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...
Hyperbola GNU는 정치적 이유와 안정성 때문에 아직 Python 3.8을 쓰고 있어서 안전했음
Ubuntu는 패치를 내놨고, 패치 전후로 테스트도 완료됨