10월 22일 GitLab 19.3.6으로 업그레이드해도 취약점이 해결되지 않았고, 수정은 GitLab 코드가 아니라 공식 패키지에만 적용되는 Ruby 패치에 있었음. 자체 이미지는 표준 Ruby를 써서 패치를 받지 못한 것임. Ruby 정규식 엔진의 버그라 신뢰할 수 없는 입력으로 정규식을 컴파일하는 모든 프로그램이 노출됨.
공격과 패치가 끊이지 않는 지금은 공식 이미지를 자주 갱신하는 쪽보다 소스 빌드나 자체 이미지를 쓰는 쪽에 특히 가혹함. 하루 종일 최신 소식을 지켜보는 것 말고 마땅한 해결책이 떠오르지 않는데, 정말 소모적인 일일 듯함.
이제 자체 호스팅을 한다면 전부 VPN 뒤에 둬야 함. 자체 보안팀과 개발팀을 갖춘 기업만 서비스를 공개 인터넷에 노출해야 함.
2026년에 이런 대응은 정말 좋지 않아 보임. https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-fo...에서는 이번 수정에 대해 Ruby 측 CVE 식별자를 아직 요청하지 않았다고 밝힘. Ruby는 원래 신뢰할 수 없는 입력으로 정규식을 컴파일하고 사용하는 일을 안전하지 않다고 봄. 다만 CVE-2022-28738에서는 종합 검토 끝에 정규식 컴파일 중 이중 해제를 취약점으로 취급했고, CVE-2024-27282에서도 같은 처리를 했다고 함.
산업화 초기에는 증기 보일러 사고가 잦았지만, 규제와 관련 기관들의 도움으로 통제하게 됐고 그중 일부 기관은 지금도 존재함. 공격과 패치가 끊이지 않는 시대는 정상이 아니며 계속돼서도 안 됨. 지금은 끝없는 쫓고 쫓기는 싸움이지만, 반드시 그래야 하는 것은 아님.
레거시 PHP 앱을 여러 개 유지보수하는 입장에서 PHP2Shell은 돈도 많이 벌게 해줬지만 정말 진이 빠지는 일이었음.
세상이 달라졌지만, 15년 전에는 빌드·배포 과정에서 $internetsite.probablytrusted.org의 $latest를 무턱대고 받아 쓰는 일을 완전히 제정신이 아닌 행동으로 여겼음.
결국 어느 C 데이터 처리 라이브러리, 구체적으로는 정규식 라이브러리의 정수 오버플로가 원격 코드 실행으로 이어진 버그임. 이번 주 들어 C 라이브러리에 질린 사람이 또 있는지?
오래전부터 이걸 지적해 왔지만, 유능한 개발자가 C를 쓰면 괜찮고 우리가 쓰는 C 소프트웨어는 실전에서 충분히 검증돼 대체로 안전하다는 답을 반복해서 들었음. 이제 그 안전성 주장이 사실이 아니었음이 드러나고 있음.
Xe Iaso가 C(++)를 풍자하는 블로그 연재, ‘이런 일이 늘 일어나는 유일한 언어의 사용자들이 “막을 방법이 없다”고 함’에 이번 달 유독 소재가 많아졌음. C를 없애는 것만으로 만사가 해결되지는 않음. Ubuntu도 sudo와 coreutils를 Rust로 재작성하는 데 힘쓰고 있지만 그 과정에서 버그가 많이 나왔음. 그래도 C 프로젝트들이 선제적으로 퍼징을 하고, fil-C를 실행하거나 기존 코드를 위한 새로운 안전장치를 만들기 바람.
Rust는 여기서 어떻게 도움이 되는지? 내가 알기로 정수 오버플로는 디버그 빌드에서는 패닉을 일으키지만 릴리스 빌드에서는 값이 순환하는데, 개인적으로 좋지 않은 선택이라고 봄. 특히 공격의 코드 실행 단계에서 도움이 되는 것인지?
안내에 따르면 10월 27일 게시된 alpinelinux/gitlab:19.3.6에는 Ruby 3.3.13이 들어 있지만, 그 전에 받은 같은 태그의 이미지와 모든 이전 태그는 취약함. 그렇다면 수정된 19.3.6을 다시 배포할 게 아니라 새 버전 태그를 붙여야 하지 않을까?
이미지 태그는 버전이 아니며, 그렇게 취급해서도 안 됨. 19.3.6은 변경되지 않은 GitLab 버전을 가리킴. 그래서 이미지를 특정 SHA로 고정하고 변경 알림을 받을 절차를 마련해야 함.
보안 사고를 아주 잘 정리한 글임. 이런 사고에는 거의 언제나 알 수 없는 부분이 있는데, 불확실성을 명시한 점이 좋음. 특히 공격이 성공했다면 무엇이 유출됐을지 정리한 부분이 마음에 들었고, 사용한 해시 종류도 포함하면 좋겠음.
Alpine이 보안을 그렇게 중시한다면 GitLab을 쓰지 않는 편이 나을 듯함. 공격 표면이 너무 넓고, 유지보수가 주 업무인 전담 인력 없이는 안전성과 최신 상태를 완전히 유지하기 어려움.
차라리 Forgejo 소스를 철저히 감사한 뒤 직접 운영하면 됨.
GitLab 사용자에게 Forgejo가 현실적인 대체재라고 보는 건 무리임. Forgejo 사용자에게 cgit을 쓰라고 하는 것과 비슷함. Alpine이 cgit도 쓴다는 건 알고 있음.
eMudhra 사태에서는 Go가 인증서를 직접 배포하지 않는데도, 아직 대응하지 못한 의존성을 보호하려고 해당 인증서를 차단하는 긴급 릴리스를 냈음. 이번에도 GitLab이 해당 CVE에 취약한 Ruby 런타임을 차단하는 편이 더 책임 있는 대응 아닐까?
공격이 성공하지 않았을 가능성이 크다고 보면서도 재구축과 철저한 대응 절차를 진행한 점이 좋음. 증거가 없다고 아무 일도 없었다는 뜻은 아니므로, 나중에 후회하기보다 안전한 쪽을 택한 훌륭한 대응임.
지원 종료된 Ruby 중 어느 버전이 영향받는지 확실히 아는 사람이 있는지? 내가 파악하기로는 취약점 4개 중 3개가 이번 보안 패치를 받지 못하는 구버전에도 영향을 줌. Ruby를 업데이트해야 함!
다만 이중 해제 취약점인 CVE-2026-89078은 Ruby 3.3.11 이상에만 해당할 수도 있음. Ruby 3.4/4에 https://github.com/ruby/ruby/commit/8cd295ecf0로 도입된 버그가 https://github.com/ruby/ruby/commit/e02c892ade를 통해 3.3.11/12에 백포트된 데서 비롯되며, 실수로 들어갔을 가능성도 있음. 따라서 이 취약점은 영향받는 모든 Ruby 버전에서 패치되는 셈임.
잘 유지보수되는 기존 패키지를 신뢰하지 않고 직접 다시 작성하면 이런 일이 생김. Onigmo는 존재하지 말았어야 함. Linux에도 외부에서 만든 것을 꺼리는 똑같이 불편한 성향이 있어서, 좋은 기능을 직접 재작성하다 더 나쁘게 만들곤 함.
제목이 사태를 축소하는 느낌임. ‘시도된’ 공격이라고 하면 실패했다는 뜻으로 읽히지, 완전히 성공했을 수도 있다는 뜻으로는 읽히지 않음.