GitLab 주요 보안 릴리스 16.7.2, 16.6.4, 16.5.6

Grace

Technical Writer

2024년 1월 19일 · 약 16분

GitLab Community Edition(CE)과 Enterprise Edition(EE)용 버전 16.7.2, 16.6.4, 16.5.6이 출시됐습니다.

이 버전은 중요한 보안 업데이트를 포함하므로, 모든 GitLab 설치를 이 버전 중 하나로 즉시 업그레이드할 것을 권장합니다. GitLab.com은 이미 패치 버전을 사용하고 있습니다.

GitLab은 보안 릴리스에서 보안 취약점의 수정 사항을 공개했습니다. 자세한 내용은 보안 FAQ를 참조하세요. 일반, 보안 릴리스 블로그 글은 여기서 확인할 수 있습니다. 각 취약점을 자세히 설명하는 이슈는 패치가 적용된 릴리스 30일 후 이슈 트래커에 공개됩니다.

GitLab은 고객에게 노출되거나 고객 데이터를 호스팅하는 GitLab의 모든 측면이 최고의 보안 표준을 준수하도록 최선을 다하고 있습니다. 모든 고객은 지원되는 버전의 최신 보안 릴리스로 업그레이드할 것을 권장합니다. GitLab 인스턴스 보안과 관련해 더 많은 모범 사례는 GitLab 블로그에서 볼 수 있습니다.

권장 조치

아래에 설명된 문제의 영향을 받는 버전을 실행하는 모든 설치를 가능한 한 빨리 최신 버전으로 업그레이드할 것을 권장합니다. 아직 업그레이드하지 않았다면, 최근에 발견된 DB 마이그레이션 문제의 추가 수정 사항을 포함한 최신 패치가 있다는 점을 유의하세요. 마이그레이션 문제를 방지하려면 16.7.3, 16.6.5, 16.5.7 이상으로 업그레이드하세요.

제품의 특정 배포 유형(옴니버스, 소스 코드, Helm 차트 등)이 언급되지 않으면, 모든 유형이 영향을 받는다는 의미입니다.

보안 조치 사항

사용자 상호작용 없이 비밀번호 재설정을 통한 계정 탈취

16.1부터 16.1.6 전까지, 16.2부터 16.2.9 전까지, 16.3부터 16.3.7 전까지, 16.4부터 16.4.5 전까지, 16.5부터 16.5.6 전까지, 16.6부터 16.6.4 전까지, 16.7부터 16.7.2 전까지 사용자 계정 비밀번호 재설정 이메일이 확인되지 않은 이메일 주소로 전달될 수 있는 문제가 GitLab CE/EE에서 발견되었습니다. 이는 심각도가 매우 높은(Critical) 문제입니다(CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, 10.0). 이 문제는 최신 릴리스에서 완화되었으며 CVE-2023-7028로 할당되었습니다.

이 보안 수정은 16.5.6, 16.6.4, 16.7.2 외에도 GitLab 버전과 16.1.6, 16.2.9, 16.3.7, 16.4.5에 백포트되었습니다.

FAQ

Q.내 GitLab 인스턴스가 위험하다고 생각하면 어떻게 해야 하나요?

인시던트 대응 계획을 따르는 것 외에도

1.Critical Security Release를 GitLab 인스턴스에 적용하세요.

2.모든 GitLab 계정에 2단계 인증(2FA)을 활성화합니다.

3.GitLab에 저장된 모든 Secret을 교체하세요:

1)GitLab 계정 비밀번호를 포함한 모든 자격 증명

2)API 토큰

3)모든 인증서

4)기타 모든 Secret

4.여기서 인시던트 대응 가이드의 단계를 따르세요.

Q.누가 영향을 받나요?

다음 영향을 받는 버전을 사용하는 GitLab 자체 관리형 인스턴스:

16.1 ~ 16.1.5
16.2 ~ 16.2.8
16.3 ~ 16.3.6
16.4 ~ 16.4.4
16.5 ~ 16.5.5
16.6 - 16.6.3
16.7 ~ 16.7.1

이러한 버전에서는 모든 인증 메커니즘이 영향을 받습니다. 또한 2단계 인증을 활성화한 사용자는 로그인할 때 두 번째 인증 요소가 필요하므로 비밀번호 재설정에는 취약하지만 계정 탈취에는 취약하지 않습니다.

Q.어떤 조치를 취해야 하나요?

업그레이드 경로에 따라 자체 관리형 인스턴스를 패치 버전으로 업그레이드하세요. 업그레이드 중지를 건너뛰면 불안정해질 수 있으므로 건너뛰지 마세요.
- 참고: 16.3.x는 GitLab 업그레이드 경로에서 필수 업그레이드 중지 단계입니다.
특히 관리자 계정과 같이 높은 권한이 있는 사용자는 모든 GitLab 계정에 2단계 인증(2FA)을 사용하도록 설정하세요.

Q.취약점이 해결되었나요?

이 취약점은 이번 보안 릴리스에서 해결되었습니다.

Q.이 취약점으로 인해 실제로 위협받은 계정이 있나요?

GitLab.com과 GitLab Dedicated 인스턴스를 포함하여 GitLab에서 관리하는 플랫폼에서 이 취약점을 악용한 사례는 탐지되지 않았습니다. 자체 관리형 고객은 로그를 검토하여 이 취약점을 악용하려는 시도가 있는지 확인할 수 있습니다:

여러 이메일 주소가 포함된 JSON 배열로 구성된 params.value.email이 포함된 /users/password 경로에 HTTP 요청이 있는지 gitlab-rails/production_json.log에서 확인합니다.
여러 이메일 주소가 포함된 JSON 배열로 구성된 PasswordsController#create 와 target_details의 meta.caller_id가 포함된 항목을 gitlab-rails/audit_json.log에서 확인합니다.

Q.이 취약점은 언제 도입되었나요?

이 취약점은 2023년 5월 1일 16.1.0에 도입되었습니다.

Q.이 취약점은 어떻게 발견되었나요?

이 취약점은 Bug Bounty 프로그램을 통해 책임감 있게 보고되었습니다.

Q.이러한 취약점을 방지하기 위해 어떤 보안 조치를 취하고 있나요?

유사한 취약점을 방지하기 위해 비밀번호 재설정 로직 전반, 특히 제공된 이메일 처리, 이메일 생성, 콘텐츠의 유효성을 검사하는 여러 테스트를 추가했습니다.
보안 검토는 개발자가 반드시 완료해야 하는 MR 체크리스트의 필수 항목입니다.
변경 사항과 관련해 여러 번 승인을 받아야 하는 코드 리뷰 프로세스가 있습니다.
이와 같은 취약점을 예방하는 방법을 포함한 포괄적인 후속 조치 목록을 결정하기 위해 근본 원인 분석 프로세스를 시작했습니다.
2단계 인증 기능을 활성화하면 이러한 취약점을 방지하는 기능이 있습니다. 이 기능은 현재 모든 GitLab 팀원에게 활성화되었습니다.
앞으로 이 영역에서 작업하는 엔지니어가 구현과 보안 고려 사항을 확인하도록 코드 베이스에 개발자 문서를 추가했습니다.
재설정 링크에 여러 개의 이메일 주소를 제출하는 걸 지원하지 않도록 구현 로직을 수정했습니다.

Q.어떻게 이런 일이 발생했나요?

사용자가 보조 이메일 주소를 통해 비밀번호를 재설정하도록 16.1.0에서 변경되었습니다. 이 취약점은 이메일 인증 프로세스의 버그 때문에 발생했습니다. 이 패치를 통해 버그가 수정되었으며, 위에서 언급한 바와 같이 고객을 보호하기 위해 여러 예방적 보안 조치를 시행하였습니다.

Q.Okta 또는 Azure AD와 같은 Identity Provider를 사용하면 이 문제가 영향을 주나요?

SSO가 적용되지 않은 사용자는 취약합니다. 구성에서 SSO 옵션 외에 사용자 이름과 비밀번호를 허용하면 영향을 받습니다. 로그인 제한 설정을 통해 모든 비밀번호 인증 옵션을 비활성화하면 외부 Identity Provider를 구성한 자체 관리형 고객은 비밀번호 재설정 기능을 사용할 수 없으므로 취약점이 완화됩니다.

Q.2단계 인증을 적용하면 이 취약점의 영향을 받나요?

2단계 인증을 활성화하면 공격자는 계정을 탈취할 수 없습니다. 공격자는 비밀번호를 재설정할 수는 있지만 2단계 인증 방법에는 액세스할 수 없습니다. 갑자기 로그인에 리디렉션되거나 트리거된 재설정 이메일을 확인하면, 비밀번호를 재설정하세요.

Q.이 취약점이 GitLab Runner에 영향을 주나요?

아니요, 이 취약점은 GitLab Runner에 영향을 미치지 않습니다. 이 취약점은 영향을 받는 GitLab 자체 버전의 GitLab Rails 코드베이스에 영향을 미쳤습니다. GitLab Runner에는 영향을 받지 않는 별도의 코드 베이스가 있습니다.

우회 CODEOWNER 승인 제거

15.3부터 16.5.5 전까지, 16.6부터 16.6.4 전까지, 16.7부터 16.7.2 전까지 영향을 미치는 문제가 GitLab에서 발견되었습니다. 이전에 승인된 Merge Request에 변경 사항을 추가하여 필요한 CODEOWNER 승인을 우회할 수 있습니다. 이는 심각도가 높은(High) 문제입니다(CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:H/A:N, 7.6). 이 문제는 최신 릴리스에서 완화되었으며 CVE-2023-4812로 할당되었습니다.

공격자가 Slack/Mattermost 통합을 악용하여 다른 사용자로 슬래시 명령을 실행할 수 있습니다.

8.13부터 16.5.6 전까지, 16.6부터 16.6.4 전까지, 16.7부터 16.7.2 전까지 GitLab CE/EE의 부정확한 인가 확인 때문에 사용자가 Slack/Mattermost 통합을 악용하여 다른 사용자로 슬래시 명령을 실행할 수 있습니다. 이는 심각도가 높은(High) 문제입니다(CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:N, 7.3). 이 문제는 최신 릴리스에서 완화되었으며 CVE-2023-5356으로 할당되었습니다.

다른 루트 네임스페이스에서 Workspaces 생성 가능

16.5.6 이전 버전, 16.6부터 16.6.4 전까지, 16.7부터 16.7.2 전까지 영향을 미치는 부적절한 액세스 제어 취약점이 GitLab Remote Development에 존재합니다. 이 조건 때문에 공격자는 한 그룹에서 다른 그룹의 에이전트와 관련된 Workspace를 만들 수 있습니다. 이는 심각도가 중간인(Medium) 문제입니다(CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:N, 6.6). 이 문제는 현재 최신 릴리스에서 완화되었으며, CVE-2023-6955로 할당되었습니다.

커밋 서명 유효성 검사에서 서명 후 헤더를 무시합니다

공격자가 서명된 커밋의 메타데이터를 잠재적으로 수정할 수 있는 문제가 12.2부터 16.5.6 전까지, 16.6부터 16.6.4 전까지, 16.7부터 16.7.2 전까지 GitLab CE/EE에서 발견되었습니다. 이는 심각도가 낮은(Low) 문제입니다(CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N, 3.5). 이 문제는 최신 릴리스에서 완화되었으며 CVE-2023-2030으로 할당되었습니다.