Alpine, GitLab 취약점 공격에 거의 뚫릴 뻔해 인스턴스 전면 재구축
GitLab Security Incident: Attempted Exploitation of CVE-2026-97229
Alpine Linux가 10월 20~21일 자사 GitLab 인스턴스를 겨냥한 CVE-2026-97229 공격을 공개했다. 공격자는 Ruby의 정규식 엔진 Onigmo 결함을 노려 워커 프로세스를 8번이나 다운시켰고, 4번은 익스플로잇 중간 단계까지 도달했다. 코드 실행 여부를 확인할 증거가 사라진 탓에 Alpine은 인스턴스를 침해된 것으로 간주하고 처음부터 재구축했으며, 모든 비밀번호를 초기화했다. 패키지와 릴리스에는 변조 흔적이 발견되지 않았다.
익스플로잇이 성공했다면 크래시도, 웹 로그의 흔적도 남지 않았을 것이다. 공격 당일의 일부 로그는 이미 사라졌고, 우리는 외부로 나가는 네트워크 연결을 기록하지 않았으며 호스팅 제공업체도 기록을 보관하지 않는다.
HN 토론
64- JLO64
10월 22일에 GitLab 19.3.6으로 업그레이드해도 취약점이 해결되지 않았습니다. 수정은 GitLab 자체 코드가 아니라 Ruby 패치에 있는데, GitLab은 공식 패키지에서만 이 패치를 적용합니다. 우리 이미지는 표준 Ruby를 사용했기 때문에 패치가 적용되지 않았습니다.
버그는 Ruby의 정규식 엔진에 있으므로, 신뢰할 수 없는 입력으로 정규식을 컴파일하는 모든 프로그램이 노출됩니다. GitLab만 그런 게 아닙니다.
소스에서 빌드하거나 직접 이미지를 만드는 사람들에게는 이렇게 끊임없이 터지고 패치되는 시대가 제공된 이미지를 믿고 자주 업그레이드하는 사람들에 비해 정말 안 좋은 것 같아요. 그런 사람들에게는 최신 뉴스를 24시간 내내 챙기는 것 말고는 딱히 좋은 해결책이 떠오르지 않는데, 정말 안타깝고 분명히 지치는 일일 겁니다...
- akersten
alpinelinux/gitlab 컨테이너 이미지를 사용한다면 alpinelinux/gitlab:19.3.6을 다시 pull하세요. 10월 27일에 게시된 이미지에는 Ruby 3.3.13이 들어 있습니다. 10월 27일 이전에 pull한 19.3.6 이미지와 모든 이전 태그는 취약합니다.
이전 19.3.6이 취약하다면, 수정된 19.3.6을 재배포하는 대신 새 버전으로 태그를 붙여야 하지 않나요?
- rurban
이건 이미 잘 유지 관리되는 패키지를 신뢰하지 않고 직접 다시 작성할 때 벌어지는 일입니다. Onigmo는 존재하지 말았어야 합니다.
Linux도 좋은 기능을 직접 다시 작성해서 더 나쁘게 만드는, 아주 똑같이 불편한 NIH(여기서 발명되지 않음) 증후군을 앓고 있습니다.
- cowlevel
이 버그는 무작위의 C 데이터 처리 라이브러리(구체적으로는 정규식)에서 발생한 정수 오버플로로 인한 RCE입니다.
이번 주 이후로 C 라이브러리에 지친 사람 또 있나요?
- jtchang
이건 보안 사고에 관한 정말 훌륭한 글입니다. 이런 사고는 거의 항상 미지의 요소가 있기 마련이죠. 그걸 명시적으로 밝힌 점이 좋습니다. 특히 공격자가 성공했을 경우 무엇이 유출됐을지 설명한 부분이 마음에 들었습니다. 어떤 유형의 해시가 사용됐는지도 포함할 수 있었을 텐데요.