Reddit

Several Linux Kernel Vulnerabilities Accidentally Posted To Public Kernel Mailing List

리눅스 커널 취약점 여러 건, 공개 메일링 리스트에 잘못 게시

Trend Micro 산하 Zero Day Initiative가 비공개 보안 메일링 리스트 대신 공개 Linux 커널 메일링 리스트(LKML)에 취약점 보고 여러 건을 보냈습니다. SMB Direct와 ksmbd의 원격 코드 실행 취약점 등 세부 내용이 공개됐으며, 일부는 패치가 준비 중이거나 곧 게시될 예정입니다.

에디터 노트

취약점 세부 내용이 패치 배포 전에 공개되면 공격자와 방어자가 동시에 움직이게 된다는 반론은 이 사례에 직접 맞닿아 있습니다. 댓글에서는 수정과 검증, 배포에 걸리는 시간보다 공격자가 악용 코드를 만드는 시간이 짧을 수 있다고 지적합니다. 반면 공개를 늦추는 책임 공개 관행이 이용자보다 업계를 보호한다는 비판도 나옵니다. 이번 보도는 보고가 공개 리스트에 올라온 경위와 취약점 목록을 전하지만, 각 취약점의 악용 여부나 영향을 받는 커널 버전, 패치 배포 일정은 설명하지 않습니다. SMB Direct 취약점에는 Linux 7.5용 브랜치 패치가 있고, skb_zerocopy 문제는 다른 경로로도 보고돼 패치가 곧 게시될 예정이라고 구분합니다. 공개 게시가 실제 위험을 얼마나 키웠는지는 이 정보만으로 판단하기 어렵고, 게시 오류와 책임 공개 논쟁을 같은 주장으로 취급해서도 안 됩니다.

AI 요약

Trend Micro 산하 Zero Day Initiative(ZDI)가 Linux 커널 취약점 보고 여러 건을 비공개 보안 메일링 리스트가 아닌 공개 Linux 커널 메일링 리스트(LKML)에 보냈습니다. 보도에 따르면 Linux 커널 개발자 Greg Kroah-Hartman은 각 보고에 공개 리스트로 제출한 이유를 물었습니다.

공개된 취약점

  • ZDI-CAN-33549는 정수 언더플로(integer underflow)로 발생하는 SMB Direct 원격 코드 실행 취약점입니다. CVSS 점수는 9.0이며, Linux 7.5용 코드 브랜치에 패치가 있습니다. 보도는 패치가 메인라인에 더 빨리 반영될 것으로 예상합니다.
  • ZDI-CAN-33774는 ksmbd의 경쟁 상태(race condition)로 원격 코드 실행이 가능합니다. CVSS 점수는 9.0입니다.
  • ZDI-CAN-33367은 네트워크 코드의 skbuff skb_zerocopy 취약점으로, 로컬 권한 상승으로 이어질 수 있습니다. 개발자들은 지난주 다른 경로로 같은 문제를 보고받았고, 패치가 곧 게시될 예정입니다.
  • ZDI-CAN-34068은 VMware 그래픽 드라이버 VMWGFX의 범위 밖 쓰기(out-of-bounds write) 취약점으로 로컬 권한 상승을 초래할 수 있습니다.
  • ZDI-CAN-34076은 NVMET 코드의 초기화되지 않은 리소스로 정보가 노출될 수 있습니다.
  • ZDI-CAN-32005는 검색 도메인 TCP 질의 처리의 스택 버퍼 오버플로 취약점으로 로컬 권한 상승을 일으킬 수 있습니다. 이 보고는 하루 앞서 메일링 리스트에 게시됐습니다.

보도는 AI 활용이 늘어나는 환경에서 버그와 보안 보고가 계속 들어온다고 덧붙였지만, 각 취약점과 AI의 직접적인 연관성이나 보고 건수 변화에 관한 수치는 제시하지 않습니다.

Reddit 반응

  • @u/Cronos993 — 정말 다사다난한 한 주네요.
    • @u/Single-Virus4935 — 새로운 표준이네요. while sleep 60; do apt-get update && apt-get upgrade -y && reboot-if-needed; done
  • @u/qwesx — 재부팅이 끝나면 다음 재부팅이 기다립니다.
    • @u/AmusingVegetable — 업데이트가 GRUB를 망가뜨리면 그렇지 않죠.
  • @u/ARandomGuy_OnTheWeb — 참 좋네요...
  • @u/zeeblefritz — 적어도 이번엔 금요일은 아니네요. ::/
  • @u/mrlinkwii — "실수로"라니, 네에에에에에.
  • @u/evolutionxtinct — PHP 때문에 이미 바닥에 누워 있는데 Linux가 배까지 걷어차네요. 이제 우리도 Rocky 사건이 필요합니다!
  • @u/granadesnhorseshoes — 제약 회사가 소프트웨어 업계처럼 움직인다고 상상해 보세요. 연구자가 흔한 혈압약에 비소가 섞였다는 사실을 알아내면 제조사에 조용히 알려 고치게 하는 게 유일하게 "책임 있는" 행동이겠네요. 대중이 당황해 약을 끊으면 안 되니까요. 무너질 다리를 발견하면 사람들이 우회해 교통 문제가 생기지 않도록 시공사에만 알리면 되겠네요. 이번엔 Linux라서 비밀도 아니었고 보기만 안 좋았을 뿐입니다. 그래도 책임 있는 공개라는 개념은 이용자를 보호하기보다 업계를 보호하려는 헛소리입니다.
    • @u/noneedtoprogram — 그렇지 않습니다. 악의적인 행위자에게 취약점이 널리 알려지기 전에 수정하고 배포할 시간을 주려는 것입니다. 보안 문제를 공개 메일링 리스트에 올리면 해당 코드에 의존하는 사람과 관리자가 수정하고, 시험하고, 다른 중요한 기능을 깨뜨리지 않는지 확인하고, 배포하고, 영향을 받는 모든 시스템을 재부팅하는 동안 공격자가 효과적인 공격을 만드는 경쟁이 시작됩니다. 놀랍지도 않게 공격자가 훨씬 빨리 움직이므로 가능한 경우 수정 사항이 배포될 때까지 취약점 세부 정보를 제한하는 편이 중요합니다. 의료 사례와 달리 누군가가 약에 비소가 있다는 사실을 듣고 모든 사람의 뇌를 장악하러 나서지는 않습니다.
    • @u/Aquacephale — 당신이 든 사례도 대부분 실제로 그렇게 처리됩니다. 소프트웨어 업계와 다른 점은 누구나 취약점을 악용하기가 훨씬 쉽다는 것입니다. 제 생각에는 수정 사항이 준비된 뒤에만 취약점을 공개적으로 문서화하는 방식이 옳습니다.
    • @u/Kartonrealista — 어리석은 비교입니다. 혈압약에 비소가 있으면 언제나 해롭습니다. 취약점이 있는 코드가 위험해지는 건 누군가 악용할 때입니다. 사람들이 알기 전에 취약점을 고치는 건 좋은 일입니다. 나쁜 코드에 감염되는 사람은 없습니다.
    • @u/Furdiburd10 — 발전소의 출입문 자물쇠가 허술한데 정비 담당자에게 고치라고 알리는 대신 광장에서 발전소에 침입할 수 있다고 외치는 것과 비슷합니다.
원문 보기 ↗토론 보기 ↗