공유 Linux 서버를 관리하기엔 참 대단한 한 주였음. 그래도 이번 공개는 핵심을 바로 말해줘서 좋음
그런데 왜 완화 지침에서 다들 stderr를 숨기는지 모르겠음
수정: 이건 copy.fail에서 “영감”을 받아 4월 30일에 보고됐다니, 하루도 안 돼 발견된 건가? 인상적임 꽤 큰 공유 서버에서 sudo 권한을 가진 입장이라, 가능한 한 적은 모듈만 포함해 커널을 직접 컴파일하는 게 좋은 생각인지도 궁금함. 장단점을 깊게 따져보진 않았지만, 이번 주의 두 로컬 권한 상승 취약점 모두를 피할 수 있었을 것 같기도 함
수정2:
* 2. rxrpc path (Ubuntu fallback): if AF_ALG is sandboxed and the ESP
* path can't reach the page cache, fall back to the rxrpc/rxkad
* nullok primitive that patches /etc/passwd's root entry empty.
* PAM nullok then accepts the empty password during `su -`.
오, 이건 setuid가 필요 없네. 포함해줘서 좋음
내가 유지하는 다중 사용자 시스템에서 그렇게 하고 있는데, 이번 주 로컬 root 익스플로잇 두 개를 실제로 피할 수 있었음
실행 중인 시스템에서 로드된 커널 모듈 목록을 가져와 그 시스템의 modprobe 허용 목록으로 설정하는 게 가능하고 합리적일까?
CopyFail과 DirtyFrag 모두 내가 확인한 어떤 시스템에서도 로드되지 않은 커널 모듈을 악용하는 것처럼 보였음. 그렇다면 명백히 필요 없어 보이는 모듈을 막아두면 일부 공격을 사전에 완화할 수 있지 않을까?
2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.
이런 일이 어떻게 허용되는지 모르겠음. 이 정도 규모의 정보가 그렇게 신뢰하기 어려운 환경에 들어 있다는 게 정말 말도 안 되게 느껴짐
여기서 말한 “무관한 제3자가 공개했다”가 이 경우인지는 확실하지 않지만, 참고로 Brad Spengler가 수정 커밋이 먼저 올라온 걸 보고 커밋 메시지가 암시하는 보안 취약점을 알아챘고, 답글에서 누군가가 바이브 코딩으로 익스플로잇을 만들었음
Linux 커밋을 지켜보던 제3자라면 누구든 같은 단서를 잡고 익스플로잇을 만들어냈을 가능성이 있음
“무관한 제3자”라는 표현은 그 버그가 엠바고 중이라는 걸 몰랐다는 뜻처럼 들림
여기서 “신뢰하기 어려운 환경”은 인터넷 전체이고, 사실상 격리라고 할 만한 건 별로 없음. 원래도 그랬지만 지금은 더 분명해졌을 뿐임. Apache httpd 버그가 수정되기 전에 두 번이나 재발견됐다는 Stefan Eissing의 최근 글도 참고할 만함
영향을 받는 모듈이 정말 로드될 수 없는지 테스트하는 방법이 있을까?
CopyFail 때는 처음 완화 조치를 적용하면서 실수했음. /etc/modprobe.d/ 안의 파일명이 .conf로 끝나지 않았는데, https://news.ycombinator.com/item?id=47954159 의 테스트 명령을 실행하기 전까지 알아채지 못했음. esp4/esp6/rxrpc 모듈에도 비슷한 명령이 있을까?
세 모듈 모두 modprobe로 로드해봤고 지난번과 같은 오류가 났음
첨부된 개념 증명 코드도 있긴 한데, 아직 시도해보지는 않았음
Lobste.rs 의견들
공유 Linux 서버를 관리하기엔 참 대단한 한 주였음. 그래도 이번 공개는 핵심을 바로 말해줘서 좋음
그런데 왜 완화 지침에서 다들
stderr를 숨기는지 모르겠음수정: 이건 copy.fail에서 “영감”을 받아 4월 30일에 보고됐다니, 하루도 안 돼 발견된 건가? 인상적임
꽤 큰 공유 서버에서 sudo 권한을 가진 입장이라, 가능한 한 적은 모듈만 포함해 커널을 직접 컴파일하는 게 좋은 생각인지도 궁금함. 장단점을 깊게 따져보진 않았지만, 이번 주의 두 로컬 권한 상승 취약점 모두를 피할 수 있었을 것 같기도 함
수정2:
오, 이건
setuid가 필요 없네. 포함해줘서 좋음실행 중인 시스템에서 로드된 커널 모듈 목록을 가져와 그 시스템의
modprobe허용 목록으로 설정하는 게 가능하고 합리적일까?CopyFail과 DirtyFrag 모두 내가 확인한 어떤 시스템에서도 로드되지 않은 커널 모듈을 악용하는 것처럼 보였음. 그렇다면 명백히 필요 없어 보이는 모듈을 막아두면 일부 공격을 사전에 완화할 수 있지 않을까?
2026-05-07: Detailed information and the exploit for this vulnerability were published publicly by an unrelated third party, breaking the embargo.이런 일이 어떻게 허용되는지 모르겠음. 이 정도 규모의 정보가 그렇게 신뢰하기 어려운 환경에 들어 있다는 게 정말 말도 안 되게 느껴짐
Linux 커밋을 지켜보던 제3자라면 누구든 같은 단서를 잡고 익스플로잇을 만들어냈을 가능성이 있음
여기서 “신뢰하기 어려운 환경”은 인터넷 전체이고, 사실상 격리라고 할 만한 건 별로 없음. 원래도 그랬지만 지금은 더 분명해졌을 뿐임. Apache httpd 버그가 수정되기 전에 두 번이나 재발견됐다는 Stefan Eissing의 최근 글도 참고할 만함
영향을 받는 모듈이 정말 로드될 수 없는지 테스트하는 방법이 있을까?
CopyFail 때는 처음 완화 조치를 적용하면서 실수했음.
/etc/modprobe.d/안의 파일명이.conf로 끝나지 않았는데, https://news.ycombinator.com/item?id=47954159 의 테스트 명령을 실행하기 전까지 알아채지 못했음.esp4/esp6/rxrpc모듈에도 비슷한 명령이 있을까?modprobe로 로드해봤고 지난번과 같은 오류가 났음첨부된 개념 증명 코드도 있긴 한데, 아직 시도해보지는 않았음