ClickCease Virtuozzo에서 발견한 새로운 Kernel 취약점 라이브 패치 - TuxCare

인기 뉴스레터 구독하기

4,500명 이상의 Linux 및 오픈소스 전문가와 함께하세요!

한 달에 두 번. 스팸이 없습니다.

Virtuozzo에서 발견한 새로운 Kernel 취약점, KernelCare에 의해 라이브 패치됨

2020년 7월 2일 TuxCare 홍보팀

Virtuozzo에서 발견한 새로운 Kernel 취약성 - KernelCare에서 라이브 패치 적용

한 달 전, 버츄오조팀은 Kernel의 새로운 보안 취약점인 CVE-2020-14305를 발견했습니다. 이 취약점은 v3.5부터 v4.10까지 Kernel의 메모리를 손상시키며 다양한 Linux 배포판에 영향을 미칩니다. KernelCare는 이번 주에 제공될 이 CVE에 대한 패치를 준비 중입니다. 이 글에서 취약점이 발견된 경위와 이에 대한 완화 방법에 대해 알아보세요.

메모리 손상 CVE (CVE-2020-14305)는 6월 초에 Virtuozzo의 Linux Kernel 엔지니어인 바실리 아베린에 의해 발견되었습니다. 이 취약점은 다양한 Linux 배포판에 영향을 미칩니다: Red Hat 엔터프라이즈 Linux 7, 데비안 8 및 9, Ubuntu 14.04 및 16.04, UEK 3 및 4, 센토스 7 ALT 및 3.5에서 4.10까지의 Kernel. 노드에서 IPV6 포트 1720이 열려있는 경우, 이 포트에 연결하면 메모리가 손상됩니다. 특히, 이 버그를 Virtuozzo 팀에 보고한 사용자 인 FastVPS 팀은 kmalloc-192 슬래브의 요소가 손상되는 것을 경험했습니다. 이 취약점은 Virtuozzo 하이브리드 서버 7.0 업데이트14ReadyKernel 108에서 수정되었습니다.

 

Red Hat에 따르면 이 문제는 IPV6 포트 1720만 사용되며, 특정 모듈이 IP를 통한 음성 H.323을 사용하는 경우로 제한되어 있기 때문에 영향이 보통인 것으로 평가됩니다.

이 문제를 해결하기 위해 Virtuozzo 팀은 Virtuozzo 7용 패치를 만들었고, KernelCare 팀은 재부팅 없이 배포할 수 있도록 영향을 받는 다른 Linux 배포판용 패치를 만들었습니다.

KernelCare 팀은 이 버그를 발견하고 고객에게 CVE-2020-14305에 대한 패치를 신속하게 제공할 수 있게 해준 Virtuozzo 팀과 바실리 아베린에게 감사의 뜻을 전합니다.

 

KernelCare 패치 릴리스 일정

 

다음은 KernelCare 패치 릴리스 일정입니다:

  • 7월 6일 월요일: RHEL7, 데비안8 및 9, Ubuntu 14.04 및 16.04, 
  • 7월 9일 목요일: Unbreakable Enterprise Kernel 3 및 4, CentOS 7.

 

완화 지침

 

이 취약점의 패치를 위해 특별한 완화 조치가 필요하지 않습니다. Kernel이 영향을 받고 KernelCare를 사용 중인 경우 업데이트 설정에 따라 패치가 자동으로 적용됩니다(기본적으로 KernelCare 에이전트는 4시간마다 패치를 확인합니다).

KernelCare를 사용 중인 경우 - KernelCare에서 패치를 자동으로 제공하므로 추가 작업을 수행할 필요가 없습니다. 그렇지 않은 경우 - 지금이 바로 30일 평가판에 가입할 수 있는 적기입니다. 신용 카드가 필요하지 않습니다.

 

CVE-2020-14305는 어떻게 발견되었나요?

Virtuozzo 팀은 이 CVE가 어떻게 발견되었는지에 대한 독점적인 세부 정보를 KernelCare에 제공했습니다. 이는 고객인 FastVPS 팀의 도움으로 가능했습니다. 

"이 버그를 보고해준 FastVPS 팀과 이와 관련한 그들의 헌신, 인내심, 협력에 감사드립니다. 그들의 협력이 없었다면 이 취약점을 전혀 발견하지 못했을 수도 있습니다."라고 Virtuozzo의 Linux Kernel 엔지니어인 Vasily Averin은 말합니다.

전체 이야기를 알아보려면 계속 읽어보세요. 

크래시 덤프를 검색한 결과, 버츄오조 팀은 크래시의 원인이 128바이트에서 192바이트의 다양한 Kernel 객체가 저장되는 kmalloc-192 슬래브의 메모리 손상이라는 것을 알아냈습니다. 이전에 이러한 객체 손상에 대한 보고를 받았지만 그때마다 조사가 벽에 부딪혔습니다.

메모리 손상은 그 특성상 조사하기가 매우 어려웠습니다. 예를 들어 사용하지 않는 메모리가 손상된 경우와 같이 메모리 손상이 감지되지 않는 경우가 많습니다. 때때로 운이 좋으면 손상된 메모리가 중요한 부분에 해를 끼치지 않을 수 있습니다. 그러나 Kernel 크래시로 이어지더라도 크래시 원인이 메모리 손상이라고 이해하기는 어렵습니다.

손상의 본질을 이해하는 것은 훨씬 더 어렵습니다. 보통은 사용 후 사용으로 인해 발생하므로 할당, 초기화, 참조 카운팅, 손상된 오브젝트 해제 등을 확인해야 합니다. 하지만 kmalloc-192 슬래브의 경우 상황이 더 심각합니다. 다양한 오브젝트를 보관하는 데 사용되기 때문입니다. 버츄오조 팀은 가장 많이 사용되는 것을 추적하려고 시도했지만 실패했습니다.

그러나 때때로 버츄오조 팀은 무언가를 발견했습니다. 2월에 Vasily는 kmalloc-192에서 메모리 손상을 유발하는 버그를 발견했습니다.

그는 문제를 해결하기를 바랐습니다. 그러나 어느 날 FastVPS에 동일한 문제가 발생했습니다. Vasily의 팀은 위의 수정 사항을 사용하여 Kernel에서 문제를 재현하도록 요청했지만 도움이되지 않았고 문제가 반복되었습니다.

일반적으로 이러한 경우 Virtuozzo는 Kernel 디버그와 추가 다목적 디버그를 사용합니다. 디버그 Kernel은 성능이 크게 저하되고 호스트가 완전히 수용할 수 없기 때문에 고객은 프로덕션 환경에서 디버그 Kernel을 사용하지 않습니다. 그러나 FastVPS는 디버그 Kernel을 프로덕션으로 옮겼습니다. 시간이 좀 걸렸지만 문제가 재현되지 않았기 때문에 일반 Kernel로 다시 전환했습니다.

일반 Kernel에서 문제를 포착하기 위해, Virtuozzo는 FastVPN에 슬러브_디버그를 활성화하도록 요청했습니다. 

또한 성능을 저하시키고 메모리 소비를 증가시키며, 오브젝트 할당 및 해제 시 추가 메모리 검사를 수행하고, 손상된 오브젝트가 과거에 어떻게 사용되었는지 추적할 수 있게 해줍니다. 하지만 여전히 문제가 재현되지 않았고 slub_debug를 활성화한 노드는 정상적으로 실행되었습니다. 하지만 결국 6월 초, 버츄오조 팀은 슬러브_디버그가 활성화된 노드로부터 보고서를 받았습니다. 이 보고서를 통해 어떤 오브젝트가 메모리 손상을 일으켰는지 파악했고, 손상된 오브젝트의 특성도 파악했습니다. 즉, 사용 후 자유 액세스가 아니라 상당히 드물게 엔드 오브 오브젝트를 넘어서는 액세스가 발생했습니다.

이는 본질적으로 조사에 도움이 되었고 며칠 후 Vasily는 문제의 원인을 발견했습니다.

 

패치를 즉시 사용할 수 있는 시기를 확인하려면 이 블로그 게시물이나 트위터 Facebook 채널을 확인하세요.

Kernel 재부팅, 시스템 다운타임 또는 예정된 유지 보수 기간 없이 취약성 패치를 자동화하고 싶으신가요?

TuxCare로 라이브 패치에 대해 알아보기

TuxCare 게스트 작가 되기

시작하기

메일

가입

4,500

Linux & 오픈 소스
전문가!


뉴스레터 구독하기