서버 재부팅 없이 SRBDS(CVE-2020-0543) 취약점을 완화하는 방법

최근 VUSec(Vrije Universitys Systems and Network Security Group)의 학자들이 Intel 프로세서의 CrossTalk 또는 SRBDS(CVE-2020-0543) 취약성에 대한 세부 정보를 발표했습니다. CrossTalk 취약점으로 인해 하나의 CPU 코어에서 실행되는 공격자 제어 코드가 다른 코어에서 실행되는 다른 소프트웨어의 민감한 데이터를 유출할 수 있습니다. 이 문서에서는 서버를 재부팅하지 않고 이 Intel CPU 취약점을 완화하는 방법을 보여줍니다.

크로스톡이란 무엇입니까?

CrossTalk 취약점은 Zombieload와 유사한 MDS(마이크로아키텍처 데이터 샘플링) 공격 유형입니다. 시스템이 액세스하는 동안 중요한 데이터를 노출하고 훔칠 수 있습니다. MDS는 CPU 및 이와 연결된 많은 시스템 내부에 상주하는 일시적인 상태의 사용자 데이터를 대상으로 공격합니다.

SRBDS/CrossTalk 취약점은 일시적인 실행 취약점입니다. Intel에서 명명한 \CVE-2020-0543)는 공격자가 제어하는 코드가 하나의 CPU 코어에서 실행되도록 허용하여 다른 코어에서 실행되는 피해자 소프트웨어에서 민감한 데이터가 유출되도록 합니다.

Intel CPU를 사용하는 모든 시스템이 이 취약점의 영향을 받을 수 있습니다. CPU가 영향을 받는 경우 여기를 확인하십시오.

SRBDS(CVE-2020-0543) 취약점의 재부팅 없는 완화

Intel은 2020년 6월 9일 화요일에 소프트웨어 공급업체에 배포된 마이크로코드 업데이트에서 SRBDS 취약성에 대한 완화를 구현했습니다. 이 완화를 위해서는 최신 Linux 커널 패치 및 마이크로코드 업데이트를 설치해야 합니다. 두 작업 모두 전통적으로 재부팅 시 수행됩니다.

몇 대의 서버를 재부팅하는 것은 문제가 아닌 것처럼 들리지만 500개 이상의 서버를 관리하는 시스템 관리자라면 문제가 될 것입니다. 전체 서버 플릿을 재부팅하려면 일반적으로 철저한 유지 관리 기간 계획이 필요합니다. 다행스럽게도 라이브 패칭 기술을 통해 마이크로코드 업데이트와 Linux 커널 패치 적용 모두에 대해 재부팅 없이 CrossTalk에 대한 보안 업데이트를 시스템에 적용할 수 있습니다.

Canonical, Red Hate 및 기타 배포 공급업체는 지원되는 모든 Ubuntu 배포, Debian, CentOS, Red Hat Enterprise Linux에 대한 보안 패치를 출시했습니다. 그리고 Canonical 및 Red Hat에는 재부팅 없이 취약점을 패치하는 자체 솔루션이 있지만 SRBDS/CrossTalk의 경우 업데이트 후 여전히 데스크톱 또는 서버를 재부팅해야 합니다.

KernelCare 팀은 패치를 적용하기 위해 서버를 재부팅하지 않아도 되도록 CrossTalk/SRBDS에 대한 재부팅 없는 완화 기능을 만들었습니다. 아래 지침을 찾으십시오.

A) 하드웨어에서 실행 중인 경우 재부팅 없이 CrossTalk/SRBDS 취약성으로부터 서버를 보호하려면 다음 3단계를 수행하십시오.

1단계: KernelCare 무료 평가판 라이선스 등록

KernelCare는 모든 서버에서 30일 동안 무료로 사용할 수 있으며 의료 기관의 경우 2020년 남은 기간 동안 무료로 신용 카드가 필요하지 않으며 비영리 조직의 경우 영원히 무료입니다.

2단계: 재부팅 없이 마이크로코드 업데이트

예: RHEL에서 마이크로코드 업데이트

이것은 RHEL에서 재부팅 없는 마이크로코드 업데이트의 예입니다. Debian, Ubuntu, CentOS 및 기타 배포에 대한 지침은 KernelCare 문서에서 찾을 수 있습니다.

RHEL 기반 배포의 경우 microcode_ctl 유틸리티를 사용하여 마이크로코드를 업데이트할 수 있습니다.

시작하기 전에 배포용 패치가 준비되었는지 여기에서 확인하십시오. 페이지는 매시간 업데이트됩니다.

1. microcode_ctl 패키지를 업데이트하여 최신 마이크로코드를 가져옵니다.

yum update microcode_ctl

2. 펌웨어 디렉토리 내에 force-late-intel–06–4f–01을 생성합니다.

touch /lib/firmware/`uname -r`/force-late-intel-06-4f-01

3. 마이크로코드 업데이트 실행

/usr/libexec/microcode_ctl/update_ucode

4. 커널이 새 마이크로코드를 로드하도록 합니다.

에코 1 > /sys/devices/system/cpu/microcode/reload

5. 새 마이크로코드 확인

dmesg | grep microcode
[ 2.254717] microcode: sig=0x306a9, pf=0x10, revision=0x12
[ 2.254820] microcode: Microcode Update Driver: v2.01 <>, Peter Oruba
[ 1483.494573] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09
[ 1483.495985] microcode: updated to revision 0x21, date = 2019-02-13
[ 1483.496012] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09
[ 1483.496698] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09
[ 1483.497391] platform microcode: firmware: direct-loading firmware intel-ucode/06-3a-09

6. (선택 사항) 새 마이크로코드 버전을 다시 확인합니다(코어당 개정).

cat /proc/cpuinfo | grep -e microcode
microcode : 0x21
microcode : 0x21
microcode : 0x21
microcode : 0x21

3단계: KernelCare 패치 적용

이제 로컬 사용자가 CPU에서 실행 중인 데이터를 읽을 수 없도록 Linux 커널을 업데이트해야 합니다. KernelCare를 사용하면 재부팅하지 않고도 그렇게 할 수 있습니다. 1단계에서 평가판에 가입했다면 모든 설정이 완료되었으며 다른 작업을 수행할 필요가 없습니다.

B) VM에서 실행 중인 경우:

VM 내부의 Linux 커널만 패치하면 됩니다. 일반적으로 서비스 공급자가 수행하는 호스트 노드도 업데이트되었는지 확인하십시오.

KernelCare를 사용하는 경우 - 패치는 KernelCare에 의해 자동으로 제공되며 추가 조치가 필요하지 않습니다. 그렇지 않은 경우 - 30일 무료 평가판에 등록하세요.