이건 근본 원인과 악용 방식이 Copy Fail과 매우 비슷함
LLM에 작업을 많이 맡기면 잃기 쉬운 것, 즉 탐색을 잘 보여주는 사례라고 봄. AI로 취약점 연구를 하면 창의성이 꽤 막히는 느낌이 듦. 질문하면 바로 답이 나오는 흐름에서는 주변에 무엇이 있는지 보지 못함. 지니처럼 정확히 요청한 것만 주고 그 이상은 없음
Copy Fail을 발견한 연구자는 수상한 점을 본 뒤 AI에 크게 의존했는데, 직접 많은 코드를 뒤졌다면 이런 쌍둥이 버그를 발견할 기회가 더 많았을 것임. 동시에 프롬프트를 조금 덜 지시적으로 넣었다면 최신 LLM도 이 버그들을 찾아줬을 것 같음. 함께 일했는데 성능이 떨어진, 꽤 특이한 부정적 시너지 사례임
내가 잘못 읽은 게 아니라면 비슷한 게 아니라 같은 근본 원인임. IPsec의 Extended ESN 상위 32비트 == authencesn 모듈/암호 모드 문제임
copy.fail에서는 엉뚱한 것이 고쳐졌고, 사람들이 AF_ALG 탓으로 성급히 돌렸음
[편집: 맞음, 같은 authencesn 문제임. https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... 코드에는 authencesn이 주석에만 나오지만 그래도 같은 문제임]
[편집2: RxRPC 문제는 별개고, 여기서는 ESP 쪽을 말하는 것임]
후속 프롬프트로 “비슷한 종류의 버그를 찾아줘”라고 할 수도 있음. 실제 사례가 정리된 뒤에는 비슷한 버그를 찾는 게 그리 어렵지 않음
창의성 얘기는 이해됨. 어떤 도구든 AI는 시야를 좁힐 수 있음. 워크플로를 완전히 넘기지 않고 보조로만 쓰는 건 어렵다
이해가 안 됨. 애초에 이 버그들을 발견한 게 LLM들임. 그런데 그 발견을 두고 취약점 발견에 LLM이 나쁘다는 신호라고 말하는 것처럼 보임
근거가 있는 얘기인지, 아니면 그냥 즉흥적으로 풀어낸 건지 궁금함
AI가 발견한 것과 비슷하지만 완전히 같지는 않은 근본 취약점을 두고, AI가 탐색하지 못한다는 교훈으로 보기는 매우 어려움
두 취약점이 하나로 같이 공개되는 경우 말고, 어떤 반사실적 상황이면 “충분히 잘 탐색했다”고 볼 수 있는지 궁금함
“엠바고가 깨졌기 때문에 이 취약점들에 대한 패치나 CVE가 없다”
링크: https://github.com/V4bel/dirtyfrag
자세한 분석: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
중요한 부분은 이거임: “Copy Fail은 이 연구를 시작한 동기였다. 특히 Dirty Frag 취약점 체인의 xfrm-ESP Page-Cache Write는 Copy Fail과 같은 sink를 공유한다. 하지만 algif_aead 모듈 사용 가능 여부와 무관하게 트리거된다. 다시 말해 공개된 Copy Fail 완화책인 algif_aead 블랙리스트가 적용된 시스템에서도 Linux는 여전히 Dirty Frag에 취약하다”
완화책은 다음과 같지만, 직접 테스트하거나 검증하지는 않았음: “책임 있는 공개 일정과 엠바고가 깨졌기 때문에 어떤 배포판에도 패치가 없다. 아래 명령으로 취약점이 발생하는 모듈을 제거하라” sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
완화책 관련 대화에서는 재부팅이 필요하거나, 이미 악용된 머신에서는 위 명령 뒤에 다음을 실행해야 한다고 함: sudo echo 3 > /prox/sys/vm/drop_caches
sudo echo 3 > /prox/sys/vm/drop_caches에서 sudo는 효과가 없음. sudo가 echo만 실행하고 실제 쓰기는 하지 않기 때문임
그리고 머신이 이미 악용됐다면 그 정도로는 너무 늦음. 디스크 안의 무엇이든 손상됐을 수 있으니 전체 디스크 이미지를 다시 만들어야 함
비-sudo 셸에서 sudo echo와 리다이렉션을 저렇게 쓸 수는 없음 echo 3 | sudo tee /proc/sys/vm/drop_caches
또는 sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
그리고 /proc 오타도 고쳤음
참고로 echo 1 > ...로도 완화 가능함. 전부 비울 필요는 없고, 1로 페이지 캐시만 지우면 충분함
Ubuntu 26.04에서 로컬 테스트함: 익스플로잇을 실행해 root를 얻었고, 완화책을 설정했으며, 인자 없이 su를 다시 실행하자 즉시 비밀번호 없이 root가 됐음. 이후 페이지 캐시를 비우자 su가 비밀번호를 요구함
화이트리스트에 있는 커널 모듈만 로드되게 보장하는 쉬운 방법이 필요함. 필요도 없는 모듈을 계속 블랙리스트에 넣는 데 지쳤음
다시 묻겠는데, 왜 copy.fail에서 algif_aead가 욕을 다 먹는 거임? 멍청한 건 authencesn임
authencesn은 고쳐지지 않았고, 이제 그 결과가 나온 것임. 평범한 네트워크 소켓을 통해 같은, 아마도 같은 범위 밖 쓰기에 접근할 수 있는 것으로 드러남
이걸 떠올렸으면 좋았겠지만 그러지 못했음
[편집: ESP를 통한 문제를 말하는 것임. RxRPC 문제는 내가 이해하기로는 완전히 별개임]
이게 정말 주요 배포판 전부에서 동작한다면, 메인테이너들이 얼마나 무책임한지 계속 놀라게 됨. 사용자 중 아마 0.1% 미만에게나 유용할 선택적 커널 기능이 기본으로 활성화되어 있다니, 왜 그런가?
1999년 Linux 배포판들이 기본 설치에 인터넷으로 노출된 네트워크 서비스를 수십 개씩 넣어 배포하던 관행처럼 느껴짐. 그런데 지금은 1999년이 아님
배포판 메인테이너가 “너에겐 필요 없을 것(YAGNI)”이라고 판단해 특정 기능을 블랙리스트에 넣는 건 꽤 큰 요구임. 누가 무엇을 쓰는지 알 수 없기 때문임. 사용자가 돌아가서 실제 원하는 것에 맞춰 빌드를 조정하는 건 언제든 가능함
예전 Linux 초창기에 make menuconfig를 돌려 커널에 원하는 기능만 정확히 선택하던 시절이 기억남. 솔직히 그 시절로 돌아가고 싶지는 않음
다만 여기서 쉽게 개선할 수 있는 대상은 RHEL임. RHEL은 많은 모듈을 로드 가능한 모듈로 두지 않고 커널에 직접 컴파일해 넣어서, copy fail 같은 완화책이 불가능했음. 그런 것들을 조금 줄일 수는 있지 않을까 싶음
사용자가 안 쓸 것 같은 구성 요소를 비활성화하면서도 시스템 사용을 엄청 어렵게 만들지 않는 방법은 없음. 이 멍청한 OS를 25년 써온 나도 뭘 하려면 무엇을 켜고 꺼야 하는지 알 방법이 없음
Linux 배포판 메인테이너들은 지구상에서 가장 책임감 있는 소프트웨어 메인테이너들임. 보안 관행은 멍청한 프로그래밍 언어 패키지 관리자들보다 훨씬 낫고, 선별된 패키지 목록을 유지하고, 변경을 검토하고, 버그를 패치하고, 복잡한 패키징 문제를 해결하고, 수정사항을 백포트하고, 단계적 릴리스를 쓰고, 전 세계 미러로 파일을 배포하며, 모든 파일을 암호학적으로 검증함. 게다가 이 모든 걸 무료로 한다는 점도 잊으면 안 됨
기본으로 활성화된 게 아님. 필요할 때 로드되는 선택적 모듈임. 커널의 전체 구조가 사용자에게 필요한 핵심 기능은 컴파일해 넣고, 그 외 거의 모든 것은 필요 시 로드되는 모듈로 제공하도록 되어 있음
여러 면에서 모바일이 아닌 컴퓨터들은 여전히 1999년에 머물러 있음. Android는 훨씬 더 젊고 전체 스택에 강제 접근 제어를 통합할 기회가 있었기 때문에 다른 Linux 시스템보다 훨씬 안전함
이걸 악용하려면 컴퓨터에 직접 접근할 수 있어야 함. 악성 USB 장치이거나, 공급망 공격 또는 사용자가 기꺼이 혹은 자동으로 설치할 알려진 소프트웨어를 악용하는 식이어야 함. 더 나아가 사실상 임의의 터미널 명령을 실행할 수 있어야 하는데, 그 소프트웨어의 격리에서는 이미 엄청난 침해임
공격자가 그걸 다 해냈다면 이미 상황은 나쁨. 이걸로 root로 권한 상승하는 건 그 시점에서 걱정거리 중 작은 축임
아래 다른 사람이 올린 것처럼 https://xkcd.com/1200/
사람들이 겁먹기 전에 이 취약점이 실제로 무엇인지 이해해야 함
오랜 세월 끝에 드디어 “눈이 충분히 많으면 모든 버그는 얕다”는 상태가 됐는데, 좀 별로임. 이제부터 일주일에 몇 번씩 커널 업데이트를 해야 하는 걸까?
누군가 집에 침입해서 어떻게든 기본 인증 정보를 찾아내고 root 접근까지 얻을 거라고 보는 건가?
엠바고가 어떻게 깨졌는지 궁금함. 유출된 건지, 아니면 제3자가 독립적으로 찾은 건지?
애초에 엠바고는 존재하지 않고, 존재할 수도 없음
Linux는 오픈소스라서 보안 버그를 고치는 모든 패치가 즉시 모두에게 보임. 커널 개발 방식상 이를 우회할 방법은 없음. 사람들이 말하는 “엠바고”는, 패치 설명에 “THIS IS A LPE”라고 대놓고 쓰지 않고 입을 다물고 있으면 메일링 리스트에 “공식” 메시지가 나갈 때까지 취약점이 유출되지 않은 척할 수 있다는 꽤 멍청한 발상임
예전에는 이 접근이 어느 정도 변호 가능했을지 몰라도, LLM 시대에는 메일링 리스트의 diff를 자동 파이프라인으로 최신 모델에 넣고 보안 이슈를 고친 패치인지 식별하게 만들 수 있으므로 멍청할 뿐 아니라 위험함
Debian이 취약한지 아는 사람 있나? Debian 12와 Debian 13 머신에서 익스플로잇을 시도했지만 직접 재현하지는 못했음
Debian 13, 즉 Trixie의 6.12.57+deb13-amd64 커널에서는 재현했지만, Debian 12 Bookworm의 6.1.0-42-amd64 커널에서는 재현하지 못했음
Bookworm에서 Debian 패키지 보안 스트림을 쓰지 않는 사람에게는 6.1.0-42-amd64 커널이 실제로 copy.fail에 면역임. dirtyfrag에도 면역처럼 보이는 건 놀라움. 보안 스트림에서 아직 패치하지 않았다면 commit 2b8bbc64b5c2를 유지한 커널 버전을 고를 수 있음. 같은 커밋이 일부 Debian 12 커널 버전을 dirtyfrag로부터 우연히 안전하게 만들고 있을지도 모른다고 생각함
DigitalOcean의 새 Debian 13 droplet에서 익스플로잇을 막 시도했는데 동작했음
완전히 최신 상태의 Debian 13에서 테스트했고 익스플로잇이 동작함. 완화책도 동작하는 것을 확인했음
ubuntu:latest 컨테이너에서 새 기본 사용자로 실행함 git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp
결과: dirtyfrag: failed (rc=3)
좋은 소식임!
컨테이너 안에서 실행했을 때는 같은 결과가 나왔지만, 호스트에서 직접 실행하니 셸을 얻었음. 이건 익스플로잇이 컨테이너 안에서는 동작하지 않는다는 것만 보여줌. 따라서 컨테이너가 취약하지 않거나, 스크립트가 컨테이너에서 동작하려면 조정이 필요함
copy fail은 컨테이너 탈출에 쓸 수 있으므로(https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), 익스플로잇에 약간의 변경만 필요할 것으로 추측함
컨테이너를 이 테스트의 신뢰할 만한 플랫폼으로 보기는 어려움. 정상적인 것이든 아니든, 컨테이너에서는 실패하는 것들이 많음
Hacker News 의견들
이건 근본 원인과 악용 방식이 Copy Fail과 매우 비슷함
LLM에 작업을 많이 맡기면 잃기 쉬운 것, 즉 탐색을 잘 보여주는 사례라고 봄. AI로 취약점 연구를 하면 창의성이 꽤 막히는 느낌이 듦. 질문하면 바로 답이 나오는 흐름에서는 주변에 무엇이 있는지 보지 못함. 지니처럼 정확히 요청한 것만 주고 그 이상은 없음
Copy Fail을 발견한 연구자는 수상한 점을 본 뒤 AI에 크게 의존했는데, 직접 많은 코드를 뒤졌다면 이런 쌍둥이 버그를 발견할 기회가 더 많았을 것임. 동시에 프롬프트를 조금 덜 지시적으로 넣었다면 최신 LLM도 이 버그들을 찾아줬을 것 같음. 함께 일했는데 성능이 떨어진, 꽤 특이한 부정적 시너지 사례임
copy.fail에서는 엉뚱한 것이 고쳐졌고, 사람들이 AF_ALG 탓으로 성급히 돌렸음
[편집: 맞음, 같은 authencesn 문제임. https://github.com/V4bel/dirtyfrag/blob/892d9a31d391b7f0fccb... 코드에는 authencesn이 주석에만 나오지만 그래도 같은 문제임]
[편집2: RxRPC 문제는 별개고, 여기서는 ESP 쪽을 말하는 것임]
창의성 얘기는 이해됨. 어떤 도구든 AI는 시야를 좁힐 수 있음. 워크플로를 완전히 넘기지 않고 보조로만 쓰는 건 어렵다
두 취약점이 하나로 같이 공개되는 경우 말고, 어떤 반사실적 상황이면 “충분히 잘 탐색했다”고 볼 수 있는지 궁금함
“엠바고가 깨졌기 때문에 이 취약점들에 대한 패치나 CVE가 없다”
링크: https://github.com/V4bel/dirtyfrag
자세한 분석: https://github.com/V4bel/dirtyfrag/blob/master/assets/write-...
중요한 부분은 이거임: “Copy Fail은 이 연구를 시작한 동기였다. 특히 Dirty Frag 취약점 체인의 xfrm-ESP Page-Cache Write는 Copy Fail과 같은 sink를 공유한다. 하지만 algif_aead 모듈 사용 가능 여부와 무관하게 트리거된다. 다시 말해 공개된 Copy Fail 완화책인 algif_aead 블랙리스트가 적용된 시스템에서도 Linux는 여전히 Dirty Frag에 취약하다”
완화책은 다음과 같지만, 직접 테스트하거나 검증하지는 않았음: “책임 있는 공개 일정과 엠바고가 깨졌기 때문에 어떤 배포판에도 패치가 없다. 아래 명령으로 취약점이 발생하는 모듈을 제거하라”
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"완화책 관련 대화에서는 재부팅이 필요하거나, 이미 악용된 머신에서는 위 명령 뒤에 다음을 실행해야 한다고 함:
sudo echo 3 > /prox/sys/vm/drop_cachessudo echo 3 > /prox/sys/vm/drop_caches에서 sudo는 효과가 없음. sudo가 echo만 실행하고 실제 쓰기는 하지 않기 때문임그리고 머신이 이미 악용됐다면 그 정도로는 너무 늦음. 디스크 안의 무엇이든 손상됐을 수 있으니 전체 디스크 이미지를 다시 만들어야 함
sudo echo와 리다이렉션을 저렇게 쓸 수는 없음echo 3 | sudo tee /proc/sys/vm/drop_caches또는
sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'그리고
/proc오타도 고쳤음echo 1 > ...로도 완화 가능함. 전부 비울 필요는 없고,1로 페이지 캐시만 지우면 충분함Ubuntu 26.04에서 로컬 테스트함: 익스플로잇을 실행해 root를 얻었고, 완화책을 설정했으며, 인자 없이
su를 다시 실행하자 즉시 비밀번호 없이 root가 됐음. 이후 페이지 캐시를 비우자su가 비밀번호를 요구함화이트리스트에 있는 커널 모듈만 로드되게 보장하는 쉬운 방법이 필요함. 필요도 없는 모듈을 계속 블랙리스트에 넣는 데 지쳤음
다시 묻겠는데, 왜 copy.fail에서 algif_aead가 욕을 다 먹는 거임? 멍청한 건 authencesn임
authencesn은 고쳐지지 않았고, 이제 그 결과가 나온 것임. 평범한 네트워크 소켓을 통해 같은, 아마도 같은 범위 밖 쓰기에 접근할 수 있는 것으로 드러남
이걸 떠올렸으면 좋았겠지만 그러지 못했음
[편집: ESP를 통한 문제를 말하는 것임. RxRPC 문제는 내가 이해하기로는 완전히 별개임]
이게 정말 주요 배포판 전부에서 동작한다면, 메인테이너들이 얼마나 무책임한지 계속 놀라게 됨. 사용자 중 아마 0.1% 미만에게나 유용할 선택적 커널 기능이 기본으로 활성화되어 있다니, 왜 그런가?
1999년 Linux 배포판들이 기본 설치에 인터넷으로 노출된 네트워크 서비스를 수십 개씩 넣어 배포하던 관행처럼 느껴짐. 그런데 지금은 1999년이 아님
예전 Linux 초창기에
make menuconfig를 돌려 커널에 원하는 기능만 정확히 선택하던 시절이 기억남. 솔직히 그 시절로 돌아가고 싶지는 않음다만 여기서 쉽게 개선할 수 있는 대상은 RHEL임. RHEL은 많은 모듈을 로드 가능한 모듈로 두지 않고 커널에 직접 컴파일해 넣어서, copy fail 같은 완화책이 불가능했음. 그런 것들을 조금 줄일 수는 있지 않을까 싶음
Linux 배포판 메인테이너들은 지구상에서 가장 책임감 있는 소프트웨어 메인테이너들임. 보안 관행은 멍청한 프로그래밍 언어 패키지 관리자들보다 훨씬 낫고, 선별된 패키지 목록을 유지하고, 변경을 검토하고, 버그를 패치하고, 복잡한 패키징 문제를 해결하고, 수정사항을 백포트하고, 단계적 릴리스를 쓰고, 전 세계 미러로 파일을 배포하며, 모든 파일을 암호학적으로 검증함. 게다가 이 모든 걸 무료로 한다는 점도 잊으면 안 됨
공격자가 그걸 다 해냈다면 이미 상황은 나쁨. 이걸로 root로 권한 상승하는 건 그 시점에서 걱정거리 중 작은 축임
아래 다른 사람이 올린 것처럼 https://xkcd.com/1200/
사람들이 겁먹기 전에 이 취약점이 실제로 무엇인지 이해해야 함
오랜 세월 끝에 드디어 “눈이 충분히 많으면 모든 버그는 얕다”는 상태가 됐는데, 좀 별로임. 이제부터 일주일에 몇 번씩 커널 업데이트를 해야 하는 걸까?
엠바고가 어떻게 깨졌는지 궁금함. 유출된 건지, 아니면 제3자가 독립적으로 찾은 건지?
Linux는 오픈소스라서 보안 버그를 고치는 모든 패치가 즉시 모두에게 보임. 커널 개발 방식상 이를 우회할 방법은 없음. 사람들이 말하는 “엠바고”는, 패치 설명에 “THIS IS A LPE”라고 대놓고 쓰지 않고 입을 다물고 있으면 메일링 리스트에 “공식” 메시지가 나갈 때까지 취약점이 유출되지 않은 척할 수 있다는 꽤 멍청한 발상임
예전에는 이 접근이 어느 정도 변호 가능했을지 몰라도, LLM 시대에는 메일링 리스트의 diff를 자동 파이프라인으로 최신 모델에 넣고 보안 이슈를 고친 패치인지 식별하게 만들 수 있으므로 멍청할 뿐 아니라 위험함
https://x.com/encrypted_past/status/2052409822998392962
Debian이 취약한지 아는 사람 있나? Debian 12와 Debian 13 머신에서 익스플로잇을 시도했지만 직접 재현하지는 못했음
Bookworm에서 Debian 패키지 보안 스트림을 쓰지 않는 사람에게는 6.1.0-42-amd64 커널이 실제로 copy.fail에 면역임. dirtyfrag에도 면역처럼 보이는 건 놀라움. 보안 스트림에서 아직 패치하지 않았다면 commit 2b8bbc64b5c2를 유지한 커널 버전을 고를 수 있음. 같은 커밋이 일부 Debian 12 커널 버전을 dirtyfrag로부터 우연히 안전하게 만들고 있을지도 모른다고 생각함
ubuntu:latest컨테이너에서 새 기본 사용자로 실행함git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp결과:
dirtyfrag: failed (rc=3)좋은 소식임!
copy fail은 컨테이너 탈출에 쓸 수 있으므로(https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...), 익스플로잇에 약간의 변경만 필요할 것으로 추측함