Boot Hole 취약점-GRUB 2 부트 로더-CVE-2020-10713

요약

Red Hat은 현재 Red Hat Enterprise Linux를 포함하여 당사 제품에 영향을 주는 GRUB 2 부트 로더의 취약점에 대응하고 있습니다. 이 취약점을 악용하여 시스템에 이미 존재하는 공격자가 부팅 프로세스를 탈취하여 시스템 시작 중에 악성 코드를 실행할 수 있습니다. UEFI Secure Boot는 컴퓨터를 부팅하는데 사용되는 소프트웨어를 확인하고 시스템을 보호하는 기능을 하지만 이 취약점을 악용하여 UEFI Secure Boot 메커니즘을 우회할 수 있습니다. 이 문제는 CVE-2020-10713로 지정되어 있으며 심각도 등급 보통의 보안 영향을 미치는 것으로 평가하고 있습니다. 영향을 받는 버전을 사용하는 Red Hat 고객은 해당 업데이트를 적용하는 것이 좋습니다. 또한 컨테이너 호스트 시스템의 최신 이미지 및 최신 버전으로 업데이트할 것을 권장합니다.

영향을 받는 Red Hat 제품 버전은 다음과 같습니다.

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 8

• Red Hat Atomic Host 

• OpenShift Container Platform 4 (RHEL CoreOS)

현재 사용 중인 시스템에 보안 취약점이 있는지 확인하려면 아래의 “진단” 섹션을 참조하십시오. 또한 아래 제공된 Ansible Playbook을 사용하여 이러한 문제를 자동으로 해결할 수 있습니다.

기술 요약

CVE-2020-10713에서 공격자는 GRUB 2 취약점을 악용하여 GRUB 확인 프로세스를 탈취하여 변조할 수 있습니다. 또한 이러한 취약점을 악용하여 Secure Boot 보호 기능을 우회할 수 있습니다. 신뢰할 수 없거나 수정된 커널을 로드하기 위해 먼저 공격자는 시스템에 액세스해야합니다. 이를 위해 물리적 액세스 권한, pxe-boot 네트워크 변경 권한 또는 root 권한을 통한 네트워크 시스템에 원격 액세스 권한 등이 필요합니다. 이러한 액세스 권한을 얻은 공격자는 GRUB 내에서 임의의 코드를 실행시키는 악성 페이로드를 주입하여 버퍼 오버플로우를 유발하는 문자열을 만들 수 있습니다. 

로드된 커널의 Secure Boot 보호 기능이 안정적으로 작동하고 시작시 시스템이 신뢰할 수 없는 코드를 로드하지 못하도록 grub2, kernel, fwupdate, fwupd, shim, dbxtool 패키지에 대해 새로 검증된 키와 인증서가 발행됩니다.

완화 방법

현재 이 보안 취약점에 대한 완화 조치가 없습니다. 

개선 방법

Red Hat은 모든 고객이 grub2 패키지를 업데이트할 것을 권장합니다. Secure Boot를 사용하는 Red Hat 고객은 새로 검증된 키와 인증서가 포함된 kernel, fwupdate, fwupd, shim, dbxtool 패키지를 업데이트해야합니다.

Red Hat Enterprise Linux 8에서 Secure Boot를 실행하는 사용자는 grub2 패키지 업데이트를 적용한 후 이전에 릴리스된 RHEL 8 커널로 부팅하기 위해 추가 단계를 수행해야합니다. 자세한 내용은 아래 RHEL 8 섹션을 참조하십시오.

기술적 세부 사항

GRUB 2 부트 로더는 여러 문자열 토큰으로 구성된 grub.cfg 파일을 통해 설정할 수 있습니다. shim이라는 초기 부트 로더가 로드된 직후 GRUB의 초기화 단계에서 이 설정 파일이 로드되고 구문 분석됩니다. 구문 분석 단계에서 설정된 값은 메모리에 저장된 내부 버퍼로 복사됩니다. 설정 토큰의 길이가 내부 버퍼의 크기를 초과하면 버퍼 오버 플로우가 발생합니다 공격자는 이 취약점을 악용하여 임의의 코드를 실행하여 시스템의 부팅 프로세스를 탈취하고 Secure Boot 보호 메커니즘을 우회할 수 있습니다. 결과적으로 서명되지 않은 바이너리 코드를 로드하여 시스템의 무결성을 위협할 수 있습니다.

배경 정보

UEFI Secure Boot이란 무엇이며 어떻게 작동합니까?

Secure Boot는 UEFI Consortium에서 개발한 UEFI 펌웨어 보안 기능으로 부팅시 변경 불가능하고 서명된 소프트웨어만 로드되도록 합니다. Secure Boot는 암호화 및 디지털 서명을 활용하여 로드된 코드의 진위, 소스 및 무결성을 확인합니다. 이러한 검증 절차는 악성 코드가 로드되는 것을 방지하고 특정 유형의 루트킷 설치와 같은 시스템의 보안 공격을 방지하기 위해 수행됩니다. UEFI 및 Secure Boot에 대한 자세한 내용은 UEFI Secure Boot in Modern Computer Security Solutions에서 참조하십시오. 

신뢰할 수 있는 애플리케이션은 중앙 인증 기관(CA)에 의해 서명됩니다. 공용 인증서는 하드웨어에 저장되므로 이 인증서로 서명된 타사 EFI 애플리케이션을 성공적으로 로드할 수 있습니다.

Secure Boot 메커니즘을 지원하는 Red Hat Enterprise Linux 버전에서 서명된 신뢰할 수 있는 애플리케이션은 시스템 펌웨어에 의해 로드된 첫 번째 애플리케이션인 shim 패키지입니다. shim 패키지 자체에는 Red Hat 인증서가 있고 로드가 허용되는 신뢰할 수 있는 키 및 코드 해시 자체 데이터베이스를 보유하고 있습니다. 이 데이터는 GRUB 2인 부트 로더 서명을 확인하는 데 사용되며 서명이 손상되거나 변조되지 않았는지 확인합니다. 확인에 성공하면 GRUB이 로드되고 커널 서명을 확인하여 Red Hat의 인증서 또는 사용자가 Allow DB에 등록한 해시 값과 일치하는지 확인합니다. 일치하는 경우 GRUB은 커널을 로드하여 부트로드 프로세스를 완료합니다.

제품에 미치는 영향

RHEL (Red Hat Enterprise Linux) 7 및 8, Red Hat Enterprise Atomic Host 및 RHEL CoreOS (Openshift Container Platform 4의 일부)에는 보안 취약점이 있는 GRUB 2 버전이 포함되어 있습니다. 

Red Hat Enterprise Linux 8

이 업데이트의 일부로 릴리스된 커널의 기능 향상으로 인해 이전 Red Hat Enterprise Linux 8 커널 버전은 shim의 allow 목록에 추가되지 않았습니다. Secure Boot가 활성화된 상태에서 실행 중이고 사용자가 이전 커널 버전으로 부팅해야 하는 경우 해시 값을 신뢰 목록에 수동으로 등록해야합니다. 이를 위해 다음 명령을 실행합니다.

# pesign -P -h -i /boot/vmlinuz-<version>

# mokutil --import-hash <hash value returned from pesign command>

# reboot

Red Hat Enterprise Linux 7

Red Hat은 이전 Red Hat Enterprise Linux 7의 커널 해시 값을 shim의 allow 데이터베이스에 추가했으므로 Secure Boot 사용자는 이전 버전의 커널로 부팅할 수 있습니다. 

RHEL Atomic Host

현재 RHEL Atomic Host에서 shim 바이너리를 업데이트할 수 없습니다. 고객은 이 문제를 평가하고 업데이트된 부트 미디어를 사용하여 노드를 프로비저닝해야하는지 여부를 결정해야합니다.

OpenShift Container Platform 4 (RHEL CoreOS)

현재 Red Hat은 RHEL CoreOS 용 EFI 시스템 파티션 (shim, grub 포함)에 대한 업데이트를 제공하지 않습니다. 정기적으로 노드를 재프로비저닝하는 것이 최선의 방법입니다. 고객은 업데이트된 "부팅 이미지"를 사용하여 이를 수행할 수 있습니다. 고객은 이 문제의 영향을 평가하고 현시점에서 부팅 이미지 업데이트가 필요한지 결정해야합니다.

이 취약점은 Secure Boot가 활성화된 베어 메탈 시스템의 무결성에 주로 영향을 미치므로 새 부팅 이미지를 업데이트하고 사용할 것을 권장합니다. 고객이 베어 메탈 인프라를 프로비저닝하는 방법에 따라 부팅 이미지를 업데이트하는 단계가 다를 수 있습니다. 이 프로세스에서는 부트 인프라의 PXE 구성을 업데이트하여 새 부트 이미지를 제공하거나 업데이트된 설치 ISO 및 베어 메탈 디스크 이미지를 사용하여 베어 메탈 시스템을 다시 설치해야 할 수 있습니다. 고객은 사용 환경을 고려하고 OpenShift 문서를 참조하여 부팅 이미지를 적절하게 업데이트해야 합니다. 자세한 정보는 Installing a cluster on bare metal에서 참조하십시오. 

업데이트된 부팅 이미지 노드를 재프로비저닝해야하는 경우 고객은 재프로비저닝하려는 노드를 차단 (cordon) 및 드레인 (drain)하기 위해 필요한 단계를 수행해야합니다. 고객은 클러스터의 전반적인 상태가 손상되지 않도록 노드를 하나씩 다시 프로비저닝해야합니다.

다음 명령을 실행하여 노드를 차단 (cordon)합니다.

$ oc adm cordon <node name>

다음 명령을 실행하여 노드를 드레인 (drain)합니다.

$ oc adm drain <node name>

노드가 성공적으로 차단 및 드레인되면 고객은 노드를 재부팅하고 다시 설치한 다음 업데이트된 부팅 이미지로 적절하게 다시 프로비저닝되었는지 확인해야합니다.

영향을 받는 제품의 업데이트

처음 릴리스된 shim 패키지는 새 버전으로 교체되었습니다. 업데이트된 shim 패키지를 사용할 수 있으며 이전에 릴리스된 grub2, fwupd, fwupdate 패키지와 함께 사용할 수 있습니다. 처음 릴리스된 shim 패키지에 대한 자세한 내용은 https://access.redhat.com/solutions/5272311에서 참조하십시오. 영향을 받는 버전을 실행하는 고객은 이 업데이트를 적용할 것을 적극 권장합니다.

¹ Red Hat Enterprise Linux Extended Update Support (EUS)서브스크립션이란 무엇입니까?

² Advanced mission critical Update Support (AUS)이란 무엇입니까?

³ Red Hat Enterprise Linux SAP Solutions 서브스크립션이란 무엇입니까?

⁴ Atomic Host

⁵ 업데이트가 릴리스된 후 권고/업데이트 링크가 추가됩니다.

⁶ 처음 릴리스된 shim 패키지는 새 버전으로 교체되었습니다. 업데이트된 shim 패키지를 사용할 수 있으며 이전에 릴리스된 grub2, fwupd, fwupdate 패키지와 함께 사용할 수 있습니다. 처음 릴리스된 shim 패키지에 대한 자세한 내용은 https://access.redhat.com/solutions/5272311에서 참조하십시오.

⁷ 기능의 알려진 버그를 해결하기 위해 업데이트된 dbxtool 패키지가 RHEL 8 용으로 릴리스되었습니다. DBX 업데이트 적용 방법은 How to update the Secure Boot Forbidden Signature Database (DBX) with the latest UEFI Revocation List file 문서에서 참조하십시오.

진단

취약점 진단 스크립트는 현재 지원되는 Red Hat Enterprise Linux 버전을 대상으로 합니다. 진단 스크립트는 Red Hat Enterprise Linux의 계층 제품에서도 사용할 수 있습니다.

Ansible Playbook

Ansible Playbook "CVE-2020-14297-14300-update_fixit--2020-06-23-1248_0.yml"도 제공됩니다. 이러한 Ansible Playbook은 모든 관련 패키지를 업데이트합니다. Playbook을 사용하려면 업데이트할 호스트를 HOSTS 추가 변수로 지정합니다.

ansible-playbook -e HOSTS=<myhosts> CVE-2020-10713-update_fixit--2020-07-29-1613.yml

OpenPGP 서명을 다운로드하여 Playbook의 진위 여부를 확인할 수 있습니다.

자주하는 질문 (FAQ)

Q: 시스템에 Secure Boot 메커니즘이 활성화되어 있는지 어떻게 확인할 수 있습니까?

A: 다음 명령을 실행하여 Secure Boot 기능이 활성화되어 있는지 확인할 수 있습니다.

    $ mokutil --sb-state

SecureBoot enabled

  참고: Secure Boot가 비활성화된 시스템에서 mokutil 명령을 변수와 함께 사용하면 다음 출력이 표시됩니다.  

# mokutil -l

EFI variables are not supported on this system

Q: 업데이트된 패키지를 설치한 후 시스템을 재부팅하거나 다시 시작해야합니까?

A: 예. 업데이트된 구성 요소를 사용하려면 재부팅이 필요합니다.

Q: 컨테이너는 어떤 영향을 받습니까?

Red Hat Enterprise Linux 기반의 컨테이너는 이 문제에 직접적인 영향을 받지 않지만 보안은 호스트 커널 환경의 보안에 따라 달라집니다. 따라서 Red Hat은 컨테이너 호스트 시스템의 최신 이미지 및 최신 버전으로 업데이트할 것을 권장합니다. 사용 중인 컨테이너의 개인 정보를 보호하려면 컨테이너 호스트 (예: Red Hat Enterprise Linux 또는 Atomic Host)에 이러한 보안 문제를 해결하는 업데이트를 적용하고 배포해야 합니다. 

Q: Red Hat Enterprise Linux 7을 실행 중이지만 커널 버전을 업데이트할 수 없습니다. 커널 버전의 해시 값을 신뢰할 수있는 DB에 등록해야합니까?

A: 등록할 필요가 없습니다. Red Hat Enterprise Linux 7의 이전 커널 버전은 shim의 허용 목록에 자동으로 추가됩니다.

Q: Red Hat Enterprise Linux 8을 실행하고 있어도 커널 버전의 해시 값을 신뢰할 수있는 DB에 등록해야합니까?

A: 예. 등록해야 합니다. Red Hat Enterprise Linux 8 이전의 커널 버전은 기본적으로 신뢰할 수 없습니다. 이전 커널 버전을 모두 부팅가능하게 하려면 root 사용자로 다음 명령을 실행합니다.

# pesign -P -h -i /boot/vmlinuz-<version>

# mokutil --import-hash <hash value returned from pesign command>

# reboot

Q: Secure Boot을 사용하지 않는 경우 GRUB에 이 업데이트를 적용한 후 수정 사항없이 이전 버전의 RHEL 7 및 8 커널로 계속 부팅할 수 있습니까? 

A: 예. Secure Boot 옵션을 비활성화하면 서명 확인이 수행되지 않으므로 추가 작업 없이도 이전 커널 버전을 부팅할 수 있습니다.

Q: 새로운 DBX 업데이트는 언제 UEFI 펌웨어에 적용됩니까?

A : GRUB의 보안 취약점으로 인해 이전 Red Hat Secure Boot 서명이 취소되고 DBX (Disallow DB) 데이터베이스에 저장되며 고객이 dbxtool 업데이트를 적용할 때 새 서명이 사용됩니다. 업데이트에는 새 DBX 파일이 포함되며 이전 Red Hat 키가 취소됩니다. 그러나 dbxupdate는 기본적으로 실행되지 않으며 이는 이전 키를 제외하려는 IT 전문가에게 적합합니다. 모든 Red Hat 고객의 Red Hat 키를 무기한 취소하기 위해 새로운 필수 및 자동 dbxtool 업데이트가 향후 몇 개월 내에 릴리스될 예정입니다.  

Q:이 취약점은 Secure Boot 사용과 관계없이 실행되는 프로그램 코드에 영향을 미칩니다. 그렇다면 Secure Boot가 활성화된 시스템과 그렇지 않은 시스템간에 취약점의 영향이 어떻게 다른가요?

A: Secure Boot 메커니즘은 시스템의 펌웨어 및 후속 로더 구성 요소에서 수정되지 않고 신뢰할 수 있는 서명된 코드만 로드할 수 있도록 설계되었습니다. 즉, Secure Boot 메커니즘은 부팅 단계 (부트 로더, 커널 및 커널 모듈) 동안 신뢰할 수 없는 소프트웨어를 로드하지 못하도록 추가적인 보안 경계를 제공합니다. GRUB 2 취약점으로 인해 임의의 코드가 실행될 수 있으므로 공격자는 이를 악용하여 Secure Boot에 의해 설정된 보안 경계를 넘어 서명 검사를 우회하거나 신뢰할 수 없는 코드를 실행할 수 있으므로 로드된 커널의 무결성을 위협하게 됩니다. 

Secure Boot이 비활성화되면 서명 확인이 수행되지 않습니다. 결과적으로 추가 보안 경계가 설정되지 않습니다. 이 취약점으로 인해 코드가 로드될 수 있으므로 Security Boot 메커니즘을 사용하지 않는 GRUB의 경우 이 취약점은 임의의 코드 실행을 허용하는 다른 결함과 같이 처리될 수 있습니다.

Q: POST 후에 시스템이 중단되고 RHSA-2020:3216 또는 RHSA-2020:3217을 적용한 후에도 grub 메뉴가 로드되지 않으면 어떻게 해야합니까?

A: https://access.redhat.com/solutions/5272311에서 자세한 내용을 참조하십시오. Red Hat은 2020년 8월 1일 토요일에 이 문제에 대한 업데이트된 shim 패키지를 릴리스했습니다. Red Hat 고객은 RHSA-2020:3216 또는 RHSA-2020:3217에서 제공하는 이전 버전의 shim 패키지를 사용하지 않고 RHBA-2020:3262 및 RHBA-2020:3265에서 제공하는 shim 패키지 (또는 최신 버전)를 사용하는 것이 좋습니다.  

감사 인사

Red Hat은이 취약점을 보고해 주신 Eclypsium의 Jesse Michael과 Mickey Shkatov님에게 감사드립니다. 또한 Red Hat은 이 문제의 대응에 협력해 주신 업계 파트너 및 GNU GRUB 커뮤니티에 감사드립니다. 

참고 자료

• Eclypsium - There's a Hole in the Boot 
• How to apply the updated DBX file within dbxtool updates
• Working with GRUB 2
• UEFI Secure Boot in Modern Computer Security Solutions
• How to use GPG to verify signed content from Product Security