Mmap Kernel 취약점이 재등재되었습니다.

과거 몇 개의 글에서 새로운 Linux Kernel 취약점에 대해 다뤘지만, 이번 글에서는 실수로 재등재된 취약점에 대해 살펴보겠습니다. 잘못 재등재된 보고서와 원래의 보고서 모두 메모리 확장 함수를 사용할 때 경합 조건이 발생할 수 있는 Linux Kernel 메모리 매핑의 취약점을 지적하고 있습니다.

이 취약점은 있는 그대로 다룰 것입니다. 하지만 이중 리스팅을 통해 드러난 핵심 문제, 즉 보안 전문가들이 기존 취약점을 '신규' 및 '방금 발견'으로 재등재할 정도로 쉽게 놓칠 수 있다면 취약점 관리 현황에 대해 어떤 시사점을 주는지 살펴볼 것입니다.

수많은 공격 전략에 취약하지만 보안 전문가에게 도움을 받아야 하는 전 세계 Linux 사용자들에게 이는 어떤 의미일까요?

콘텐츠

1. mmap Kernel 취약점 이해하기

2. 메모리 확장

3. 경쟁 조건 및 사용 후 무료에 대한 간략한 개요

4. 이 특정 취약점의 영향은 무엇인가요?

5. 잠깐, 여기 와본 적 있는데...

6. 더 큰 문제가 걸려 있습니다.

7. 효과적인 취약점 관리는 매우 어렵습니다.

8. 효과적인 취약점 관리

9. 패치 적용이 중요합니다.

10. 자동화된 실시간 패치가 핵심

11. 결론

mmap Kernel 취약점 이해하기

애플리케이션은 거의 항상 애플리케이션이 실행되는 동안 컴퓨터 메모리에 무언가를 저장해야 하는데, 그렇지 않으면 그다지 유용하지 않습니다. 따라서 운영 체제 Kernel은 애플리케이션에 메모리 공간을 할당해야 합니다. 이 메모리 할당을 요청하는 데 사용되는 함수를 메모리 매핑 함수인 mmap이라고 합니다.

물론 모든 컴퓨터에는 한정된 양의 메모리가 있습니다. 메모리를 할당할 때 Kernel은 수요를 신중하게 관리하고 필요한 경우 사용하지 않는 메모리를 다른 애플리케이션에 다시 할당해야 합니다.

이 특정 취약점에서는 서로 다른 두 애플리케이션이 동일한 메모리에 대한 액세스를 요청할 수 있는 에지 케이스가 있습니다. 마지막으로 도착한 애플리케이션은 요청에 실패하게 됩니다. 이 취약점이 발생하는 이유는 두 번째 애플리케이션이 이제 유효하지 않은 메모리 위치에서 계속 읽을 수 있기 때문입니다.

그러면 Kernel 크래시가 발생하여 해당 메모리 위치의 정보가 공개될 수 있습니다. 이 정보에는 완전히 무해한 정보부터 암호화 키까지 모든 것이 포함될 수 있으며, 바로 여기에 위험이 있습니다.

메모리 확장

이 취약점의 원인은 메모리 확장이 처리되는 방식에 있다는 점에 주목할 필요가 있습니다. Kernel은 메모리 페이지 목록을 유지하여 할당된 메모리를 관리합니다. 때때로 애플리케이션에 더 많은 메모리가 필요하거나 실제로 이 메모리 중 일부를 포기해야 할 수도 있습니다.

예를 들어, 애플리케이션 사용자가 대용량 파일을 열면 애플리케이션은 메모리 할당을 확장해야 할 수 있습니다. 이 확장은 기존 할당된 메모리에서 "업" 또는 "다운"될 수 있습니다. 일반적으로는 문제가 되지 않지만 확장은 신중하게 처리해야 하며, 그렇지 않으면 동일한 애플리케이션의 여러 스레드 또는 다른 애플리케이션에서 상호 작용이 발생할 수 있는 문제가 발생할 수 있습니다.

안타깝게도 이 취약점을 발견한 연구원들이 발견한 바에 따르면, 일부 경우 영향을 받는 Linux Kernel 버전은 메모리 확장을 올바르게 처리하지 못합니다. 이 취약점으로 인해 특정 확장 함수(expand_down_down 및 expand_up_up)와 페이지 테이블 프리 작업 간에 경합 조건이 발생할 수 있습니다.

경쟁 조건 및 사용 후 무료에 대한 간략한 개요

이 취약점을 둘러싼 두 가지 일반적인 보안 문제를 빠르게 살펴볼 필요가 있습니다. 첫째, 많은 보안 문제가 경쟁 조건과 관련되어 있습니다. 이 취약점에서 경합 조건이 어떻게 작동하는지 위에서 설명했는데, 두 애플리케이션이 동일한 메모리 공간에 대한 액세스를 요청하는 경우입니다. "늦게" 도착한 애플리케이션이 다른 애플리케이션에 할당된 메모리에 잘못 액세스할 수 있습니다.

이는 경쟁 조건의 한 예일 뿐입니다. 일반적으로 경합 조건은 동일하거나 다른 애플리케이션의 두 개 이상의 스레드가 동일한 데이터에 액세스하려고 시도할 때 발생합니다. 이 데이터는 공유 데이터일 수도 있고 할당된 메모리 공간과 같은 것일 수도 있습니다. 공격자는 경합 조건으로 인해 발생하는 오류(Kernel 충돌 포함)를 악용하여 서비스 거부부터 데이터 탈취에 이르기까지 다양한 공격을 수행할 수 있습니다.

사용자 사용 후 해제 또는 UAF 시나리오는 애플리케이션이 메모리가 해제된 후 해당 메모리에 액세스하려고 시도하는 경우입니다. 예를 들어, 애플리케이션의 포인터가 동적 메모리의 데이터 세트를 가리키는데, 실제로는 포인터가 업데이트되어야 하는데 더 이상 사용되지 않아 해제되어 있는 경우입니다.

다시 말하지만, UAF 취약점은 공격자가 프로그래밍 오류를 악용하여 시스템을 다운시키거나 데이터를 훔치는 등 보안 침해를 유발할 수 있는 여지를 제공합니다.

이 특정 취약점의 영향은 무엇인가요?

현재 이 취약점을 악용한 익스플로잇이 알려진 바는 없지만, 언제나 그렇듯이 익스플로잇이 나타날 위험은 존재합니다. 취약점을 악용하기 위해 로컬 계정에 액세스해야 한다는 점을 고려할 때 이 취약점이 출현할 위험은 중간에서 낮은 수준입니다. 그럼에도 불구하고 공격자는 로컬 계정 액세스를 통해 특수 코딩된 프로그램을 만들어 Kernel을 크래시하는 사용 후 무료화를 트리거할 수 있습니다.

이러한 충돌의 부작용으로 공격자는 영향을 받은 메모리의 내용이 포함된 충돌로 인해 생성된 오류 메시지를 가져오는 등 정보를 훔치도록 프로그램을 설계할 수 있습니다. 공격자는 Kernel이 충돌할 때마다 생성되는 '코어 덤프'를 참조할 수도 있습니다. 제대로 실행된 공격은 이 정보를 다른 시스템으로 유출할 수 있습니다.

이 취약점은 5.7.11 이전 Kernel 버전에 영향을 줍니다. 대부분의 배포판에서 해당 취약점에 대한 수정 사항을 릴리스했으며, 관련 패치를 적용하면 워크로드를 이 취약점으로부터 보호할 수 있습니다. 물론 KernelCare는 지원하는 모든 배포판에서 이 취약점에 대한 실시간 패치를 제공하고 있습니다.

잠깐, 여기 와본 적 있는데...

해당 취약점에 대한 CVE입니다, CVE-2020-20200는 최근 유보 상태(즉, 취약점이 확인되었을 가능성이 있지만 확인되지는 않았음)로 나타났습니다. 알고 보니 중복된 보고서였습니다. 사실 작년 11월에 다음과 같이 정확히 동일한 취약점이 보고되었습니다. CVE-2020-29369.

CVE-2020-20200을 예약한 연구원들은 이 취약점이 이미 보고되었다는 사실을 몰랐던 것이 분명합니다. 그 결과 CVE-2020-20200은 단순히 CVE-2020-29369로 통합되었습니다. 보안 취약점이 중복 보고된 것은 이번이 처음이 아니며, 이번 사례로 인해 이중 보고 문제와 그 의미가 다시금 주목받고 있습니다.

Linux Kernel 보안과 밀접한 관련이 있는 사람들조차도 두 번째 공개를 받아들였습니다. 여러 개인과 팀이 이러한 취약점을 점검하고 있다는 점은 긍정적이지만, 그 과정에서 기존 취약점이 너무 쉽게 잊혀질 수 있다는 점은 우려스럽습니다.

더 큰 문제가 걸려 있습니다.

두 번이나 보고되었다는 것은 더 넓은 보안 커뮤니티에서 취약점에 대한 인식이 부족하다는 것을 의미한다고 주장할 수 있습니다. 이 특정 취약점은 기본적인 Kernel 기능에 영향을 미치지만, 두 번이나 보고되었다는 사실은 그 존재가 널리 알려지지 않았음을 시사합니다.

보안 전문가들의 인식 부족을 탓하기 쉽지만, 사실 이러한 개인과 팀은 수많은 취약점 속에서 길을 잃고 있습니다. 보안 문제의 증가로 인해 한 개인이나 팀이 중요하고 보고된 취약점을 지속적으로 인지할 수 있는 실질적인 기회는 사라지고 있습니다.

다시 말해, 전문가들조차도 발견되는 취약점의 홍수에 일관되게 대처할 수 없다는 것입니다.

효과적인 취약점 관리는 매우 어렵습니다.

보안 전문가가 취약점 관리에 어려움을 겪는다면 일상적인 IT 운영을 담당하는 직원은 훨씬 더 큰 어려움을 겪을 것은 말할 필요도 없습니다. 일반적인 시스템 관리자는 이미 일상적인 업무에 시달리고 있으며, 최근에 패치가 필요한 취약점 5~10개만 기억해도 운이 좋다고 할 수 있습니다. 하지만 수십 개 또는 수백 개? 그럴 가능성은 거의 없습니다.

현실적인 의미는 취약점이 제대로 관리되지 않는다는 것입니다. 많은 취약점이 눈에 띄지 않게 지나갈 것입니다. 다른 취약점들은 패치가 적용되겠지만, 패치가 배포된 지 한참 후에 적용될 가능성이 높습니다.

취약점에 대한 이러한 '불완전한' 처리는 악의적인 공격자에게 기회를 제공합니다. 더 심각한 문제는 공격자가 일반적으로 자동화된 도구를 사용하여 패치되지 않은 취약점을 검색한다는 것입니다. 즉, 단편적인 패치는 패치를 적용하지 않는 것과 크게 다르지 않습니다.

효과적인 취약점 관리

취약점 관리는 다양한 도구의 이점을 누릴 수 있습니다. 예를 들어, 자격 증명과 권한을 면밀히 관리하는 것은 공격자가 도난당한 자격 증명으로 일으킬 수 있는 피해를 제한하는 핵심 도구 중 하나입니다.

마찬가지로 보안 모니터링은 진행 중인 공격을 발견하고 피해를 제한할 수 있는 기회를 제공합니다. 물론 방화벽과 기타 보안 도구는 자동 공격이 뿌리를 내리기 전에 차단할 수 있습니다.

패치 적용이 중요합니다.

그러나 매우 일관되고 신속한 패치는 취약점을 관리하는 가장 효과적인 방법입니다. 대부분의 경우 취약점에 대한 패치는 익스플로잇이 출현하기 훨씬 전에 릴리스됩니다. 패치가 출시되기 전에 익스플로잇이 공개되는 경우에도 익스플로잇과 패치 사이의 간격은 상대적으로 좁습니다.

반면, 패치가 효과적이지 않은 경우, 익스플로잇이 야생에서 발견되고 패치가 최종적으로 적용될 때까지 수년이 걸리거나 무기한이 될 수 있습니다.

패치가 어렵다는 것을 잘 알고 있습니다. 예를 들어 패치를 완료하려면 서버를 다시 시작해야 하는 경우가 많습니다. 유지 보수 기간 중에 패치를 적용하면 도움이 되지만 중요한 패치는 유지 보수 기간 외에도 적용해야 합니다.

자동화된 실시간 패치가 핵심

패치를 수동으로 수행하면 시간이 많이 걸립니다. 자동화된 패치는 더 나은 방법으로, IT 리소스를 낭비하지 않고 일관성 있게 패치를 적용할 수 있습니다.

물론 패치를 관리하는 가장 효과적인 방법은 자동 패치와 재부팅 없는 패치를 결합하는 것입니다. 즉, 재시작할 필요 없이 실시간으로 패치를 적용하는 것입니다. 재부팅 없이 실시간으로 패치를 적용한다는 것은 기본 서비스를 중단하지 않고도 서버를 최신 상태로 유지한다는 것을 의미합니다.

그 서비스 바로 KernelCare 라이브 패치 의 핵심은 서버를 중단 없이 재시작할 필요 없이 자동으로 원활하게 패치를 적용하는 것입니다.

결론

넘쳐나는 취약점을 추적하는 것은 매우 어렵습니다. 취약점 관리에 가장 밀접하게 관여하는 전문가조차도 때때로 잘못 파악하는 경우가 있습니다. 최첨단 자동화 도구를 사용하지 않는 한 시스템 관리자와 기업 보안 전문가도 비슷한 오류를 범할 것이라는 데는 의문의 여지가 없습니다.

재부팅할 필요 없이 자동화된 실시간 패치를 제공하는 KernelCare는 패치가 릴리스되는 즉시 위의 mmap 취약점 및 기타 여러 유형의 취약점에 대한 패치를 적용합니다. 따라서 KernelCare와 같은 도구는 취약점 및 관련 익스플로잇과의 지속적인 싸움에서 매우 중요합니다.