요약
GitLab이 로그인 없이 서버에서 코드를 실행할 수 있는 최고 등급 취약점을 긴급 패치했습니다.
GitLab은 10월 21일 19.5.1부터 18.11.13까지 7개 버전의 패치를 냈습니다. 직접 설치해 운영하는 곳은 되도록 빨리 올리라고 권고했고, GitLab.com과 GitLab Dedicated에는 이미 적용했습니다.
왜 중요한가
- 가장 심각한 취약점은 로그인하지 않은 사람도 조작한 정규식으로 서버에서 임의 코드를 실행하게 합니다.
- 심각도 점수(CVSS)는 만점인 10.0이고, 7.0 이후 패치 전의 모든 버전이 영향을 받습니다.
핵심 내용
- 치명적 취약점(CVE-2026-110264)은 정규식 컴파일러의 정수 오버플로(숫자가 표현 범위를 넘쳐 엉뚱한 값이 되는 오류)입니다.
- 이 취약점은 HackerOne에서 활동하는 연구자 joaxcar가 찾았습니다.
- 고위험 2건은 SAML·LDAP 자동 연결을 함께 켰을 때의 계정 탈취와 OAuth/OIDC 정보 캐시 오염 문제입니다.
- 공격 흔적을 찾도록 Onigmo 워커 충돌과 Org mode 렌더링 오류 급증을 잡는 탐지 규칙 두 가지를 공개했습니다.
- 19.4.3과 19.3.6에는 데이터베이스 마이그레이션이 있어, 서버가 한 대인 곳은 업그레이드 중 서비스가 멈춥니다.
HN 반응
- 공지가 간략해 GitLab 문제인지 Ruby 정규식 엔진 문제인지 묻는 댓글이 많았고, 일부는 Ruby가 4월에 고친 버그라고 짚었습니다.
- 같은 날 큰 보안 소식이 잇따르자 AI 탓에 보안 암흑기가 온다는 걱정과 결국 소프트웨어가 더 단단해질 것이라는 기대가 맞섰습니다.
https://hackerone.com/joaxcar 님의 멋진 발견이네요. 그런데 이 정도로 심각한 버그가 오늘의 가장 큰 보안 취약점이 아니라는 게 좀 무섭기도 해요.
지금은 2020년대라고요. 이 정도면 3위 안에 들어가는 것도 운이 좋은 거죠!
한 시간쯤만 기다려 보세요. 더 큰 게 나올 테니까요.
세부 내용이 너무 빈약해서 더 알아보려면 직접 파헤쳐야 했습니다. 저희는 Gitlab을 쓰지 않지만 Ruby는 쓰기 때문에 영향을 받을까 걱정했습니다.
제가 찾은 것 중 가장 좋은 개요는 이겁니다. https://lilting.ch/en/articles/gitlab-cve-2026-110264-org-mode-rce
결론은 이렇습니다. 이 문제는 Ruby의 정규식 엔진에 있는 결함이고, 4월에 수정되었으며 최근 백포트되었습니다. 1
공격자가 제어하는 입력이 (이스케이프되지 않은 채) Ruby 정규식에 흘러 들어갈 수 있는 애플리케이션을 운영하는 사람은 누구나 원격 코드 실행에 취약합니다.
그러니까 문제가 Ruby 자체에 있다는 건가요? onigmo나 oniguruma가 아니라요? Ruby만 업데이트하면 해결된다면... GitLab이 Ruby 런타임을 같이 넣어서 배포하는 건가요? 아니면 Ruby가 아직 이 수정을 배포하지 않은 건가요?
… 아니면 GitLab/onigmo 버그가 정규식 입력을 이스케이프하지 않는 문제라는 건가요?
GitLab을 어떻게 설치하느냐에 따라 달라요. Kubernetes 같은 곳에서 GitLab 컨테이너를 그냥 돌린다면, 네, 그쪽에서 Ruby를 같이 패키징해서 제공하는 거예요.
지난 몇 주 사이에 GitLab에서 정규식 관련 CVE가 적어도 두 번째네요. 인증 없이 접근되는 엔드포인트라니 끔찍하지만, 악용 시도가 있었는지 로그로 확인하는 방법을 안내해 준 건 다행이에요.
제가 보기엔 GitLab이 악성 org-mode 파일을 렌더링하도록 만들어야 하는 것 같은데요. 인증하고 파일을 올리지 않고서 그렇게 만들 방법이 안 보이거든요. 제가 놓친 게 있나요?
그러니 공개 프로젝트가 하나도 없다면, 즉 셀프 호스팅 환경에서 모든 것에 인증을 요구하는 모드라면 아마 취약하지 않을 겁니다.
"담을 수 있는"이라니요? 공격자에게 공개 저장소에 대한 푸시 권한이 필요하다는 뜻인가요?
역대 최악의 보안 뉴스의 날이 되어 가고 있네요. 몇몇 발견에 AI가 한 역할을 보면, 이게 IT 보안의 암흑기가 시작되는 신호는 아닌지 생각하게 돼요.
저는 오히려 황금기의 시작이라고 봐요. 모든 소프트웨어에 에이전트 기반 자동 보안 스캔을 도입하는 투자가 모든 기업으로 퍼지고 있잖아요. 소프트웨어와 인프라는 그 어느 때보다 안전해질 거예요.
저도 황금기가 오길 바라요. 하지만 손쉬운 취약점들이 전부 털리고 시스템이 훨씬 단단해지기까지는, 몇 달 혹은 몇 년은 꽤 험난하게 지낼 수밖에 없을 거예요.
돼지 시대가 전속력으로 달려오고 있네요.
자동화된 에이전트가 허술한 코드를 찍어내는 데에도 투자가 더 늘어나면, 어떤 스캔 용량도 따라잡을 수 없을 만큼 빨리 쏟아질 텐데 왜 더 안전해진다는 거죠?
"모든" 보안 문제를 잡아내는 게 가능해진다면 균형은 공격자보다 프로젝트 쪽으로 기울겠죠.
거대한 악성 조직들은 늘 이 분야에 평범한 오픈소스 프로젝트보다 훨씬 많이 투자해 왔으니까요.
비현실적인 가정이 있어야 한다면, 균형은 바뀌지 않는다는 데 동의하시는 거죠?
이제 프로그램은 완벽해야 해요. 이론상으로라도 공용 네트워크에 닿을 수 있는 건 전부 곧 형식 검증을 거쳐야 할 거예요.
사실 이건 몇 달째 계속되고 있고, 끝이 보이지 않아요.
제가 현장 깊숙이 있지 않아서 덜 느끼는 걸 수도 있지만, 지난 몇 달은 "이걸 어떻게 못 잡았지" 싶은 익스플로잇이 훨씬 느리게 찔끔찔끔 나오는 느낌이었어요. 그런데 지금은 훨씬 큰 코드베이스를 대상으로 훨씬 정교한(그래도 실전에서 쓸 수 있는) 익스플로잇 체인이 나오고 있죠.
지난 몇 달은 상황이 훨씬 통제되고 있었어요. 프런티어 연구소들도 "Mythos급 모델이 모든 사람 손에 들어가면 어떻게 될까"를 경고하는 쪽이었지, 그게 실제로 벌어지고 있지는 않았고요. 이제는 정말로 현실이 되어 가는 것 같아요.
새로 생기는 버그의 순증가 속도와 발견되어 수정되는 버그의 속도 중 어느 쪽이 빠르냐에 달렸죠. AI가 새로 생기는 버그보다 더 빨리 버그를 찾아내 주길 바랍니다.
문제는 버그를 고치는 것, 그것도 코드만 고치는 게 아니라 그 수정을 업무를 멈추지 않으면서 제때 프로덕션에 적용하는 거예요.
이거 GitLab 버그인가요, Ruby 버그인가요? 보고서와 패치만 봐서는 알기 어렵네요...
https://github.com/ruby/ruby/pull/16801 의 백포트일 가능성이 있어요.
그 diff에 나오는 모듈 이름이 "onig"인 건 꽤 불운하네요. 에러 코드가 비하 표현처럼 보이거든요.
아니면 Rails일 수도 있고요...
여러 노드를 패치하는 중이라면
gitlab-rake gitlab:env:info로 노드별 정확한 버전을 알 수 있어요. omnibus 패키지 이름으로 짐작하는 것보다 빠르죠.Perl 5.8 이하 시절에는 정규식 엔진이 C 함수 단위로 재귀하는 방식이어서, 큰 문자열을 주면 스택 오버플로를 일으킬 수 있었습니다.
이것도 비슷한 경우일까요?
그런데 GitLab이 왜 자체 정규식 컴파일러를 갖고 있는지 궁금합니다. 아니면 하위 라이브러리나 프로그래밍 언어의 취약점인가요?
GitLab이 Ruby의 Onigmo 정규식 엔진을 포크한 자체 사본을 함께 배포하는 것 같아요.
왜죠? Ruby가 취약했던 건가요?