세 가지 좀비 Kernel 버그가 지속적으로 패치를 해야 하는 이유를 증명합니다.

최근 스펙터(Spectre)라는 익스플로잇이 공개되면서 오랫동안 알려진 취약점이 다시 등장했는데, 패치 부족으로 인해 이 잘 알려진 취약점이 다시 위험에 노출되었습니다.

그리고 또 다시 비슷한 일이 발생했습니다. 이번에는 보안 연구원들이 15년 된 Linux Kernel 코드에서 세 가지 치명적인 버그를 발견했습니다. 이렇게 오래된 코드는 지금쯤이면 버그가 있는지 철저히 조사했어야 하며, 그 동안 악의적인 공격자들이 이러한 취약점을 얼마나 자주 악용했을지는 누구나 짐작할 수 있습니다.

현재CentOS 8, Oracle EL8, RHEL8, CloudLinux 7h, CloudLinux 8, AlmaLinux OS, Ubuntu Bionic HWE, Debian 10, Debian 10 Cloud, Debian 9 백포트 및 Proxmox VE6에 대한 패치가 릴리스되었습니다.

또한 이제 CloudLinux 6h, CloudLinux 7, CentOS 7, CentOS 7-plus, Oracle EL7 및 RHEL 7에 대한 패치도 사용할 수 있습니다.

이 글에서는 방금 발견된 세 가지 취약점을 간략하게 설명하고, 오픈 소스 코드가 항상 제대로(또는 적절한 사람들에 의해) 면밀히 검토되지 않는 이유를 설명하며, 지속적인 패치의 중요성을 지적합니다.

콘텐츠

1. 우리를 괴롭히는 오래된 코드

2. 명백한 코딩 결함

3. SCSI를 사용하지 않더라도 취약합니다.

4. 코드가 오픈 소스이고 무료로 볼 수 있다는 이유만으로....

5. 패치를 적용하면 서버를 절약할 수 있습니다.

6. 자동 패치 적용 고려

7. 패치 릴리스 일정

우리를 괴롭히는 오래된 코드

많은 최신 운영 체제의 놀라운 점은 기본 코드가 상당히 오래되었다는 것입니다. Linux가 1991년에 뿌리를 두고 발전하면서 Kernel은 지속적으로 업데이트되었지만, 그렇다고 해서 Linux Kernel이 완전히 다시 작성된 것은 아닙니다. 코드가 추가, 업데이트 및 제거되었지만 한 번에 모두 제거되지는 않았습니다.

따라서 현재 사용 중인 최신 릴리스의 Linux OS에는 수십 년이 지난 코드가 포함되어 있을 수 있습니다. 그리고 10년 이상 된 코드에서 다음과 같이 기록된 세 가지 취약점이 발견되었습니다. CVE-2021-27363, CVE-2021-27364 그리고 CVE-2021-27365.

이 글에서는 세 가지 취약점에 대해 자세히 설명하지 않겠습니다. GRIMM에서 원본 보도를 읽어보실 수 있습니다.. 하지만 간략한 개요는 다음과 같습니다.

GRIMM의 연구원들은 무심코 Linux Kernel의 코드를 살펴보던 중 매우 눈에 띄는 보안 취약점을 발견했습니다. 회사가 보고한 일련의 세 가지 버그 중 첫 번째 버그는 너무나도 명백했습니다. 또한 코드가 작성될 당시 보안 위험에 대한 인식이 부족했음을 반영하는 것이었습니다.

이 코드는 5.11.3까지의 모든 Kernel 버전에 존재했습니다. 이는 15년 전으로 거슬러 올라가는 모든 Linux 배포 및 모든 버전에 영향을 미치는 버그로 해석할 수 있습니다.

명백한 코딩 결함

GRIMM의 팀은 SCSI 드라이버 코드에서 문제를 발견했습니다. 프로그래머가 코드의 한 영역에 문자 *buf를 포함할 때 길이 매개변수를 지정하는 것을 소홀히 한 것입니다. 길이 유효성 검사가 없기 때문에 공격자는 약간의 노력만 기울이면 이 코드를 악용하여 공격을 시작할 수 있었습니다.

두 번째와 세 번째 취약점은 Linux iSCSI 하위 시스템에서 발견되었습니다. 두 번째 취약점에서는 프로그래머가 Kernel 주소를 핸들로 사용했습니다(공격자가 우회할 수 있는 Kernel 주소 공간 레이아웃 무작위화)을 우회할 수 있는 Kernel 주소를 핸들로 사용했고, 세 번째는 프로그래머가 Kernel에서 사용자 데이터의 유효성을 검사하지 않은 것입니다.

이 세 가지 취약점은 모두 보안 문제로 이어지는 일반적인 프로그래밍 결함을 지적하지만, 코드가 작성될 당시에는 프로그래머들이 이러한 문제를 널리 인식하지 못했습니다. 오늘날에는 이러한 프로그래밍 결함으로 인해 악의적인 공격자가 여러 Linux 배포판에서 로컬 권한 상승 공격을 실행할 수 있습니다.

SCSI를 사용하지 않더라도 취약합니다.

세 가지 최신 취약점은 모두 SCSI 드라이버와 관련이 있습니다. 소형 컴퓨터 시스템 인터페이스의 줄임말인 SCI는 컴퓨터와 주변 장치를 연결하기 위한 1986년 표준입니다. 수년에 걸쳐 발전해 왔으며, SAS(Serial Attached SCSI) 및 iSCSI(기본적으로 TCP를 통한 SCSI)와 같은 표준을 통해 여전히 사용되고 있습니다.

그러나 워크로드가 SCSI에 의존하지 않더라도 이러한 취약점은 여전히 서버에 영향을 미칠 수 있습니다. 그 이유는 Linux Kernel 패키지가 서로 의존하는 방식 때문입니다. 종속성 때문에 서버에 SCSI 장치가 연결되어 있지 않더라도 SCSI 드라이버 코드가 서버의 메모리에 로드될 수 있습니다.

간단한 예로, 네트워크를 통해 중앙 집중식 데이터에 액세스하는 신뢰할 수 있는 방법인 iSCSI를 예로 들어보겠습니다. 서버가 iSCSI를 호출하면 취약점이 발견된 SCSI 코드가 호출됩니다. 이는 Linux Kernel이 모듈의 기능이 필요할 수 있음을 식별하고 해당 모듈을 로드할 때 자동으로 발생합니다.

결과적으로 위협 행위자는 모듈이 필요에 따라 자동으로 로드된다는 사실을 이용하여 워크로드에 전혀 사용하지 않을 수도 있는 코드의 취약점을 악용할 수 있습니다.

코드가 오픈 소스이고 무료로 볼 수 있다는 이유만으로....

방금 나열한 세 가지 취약점에는 흥미로운 측면이 있습니다. 오픈 소스 코드는 정의상 누구나 조사할 수 있습니다. 코드는 공개 도메인에 게시되어 있으며 자유롭게 보고 실험해 볼 수 있습니다.

이론적으로는 오픈 소스 코드가 매우 개방적이기 때문에 보안성이 높다는 의미일 수 있습니다. 많은 사람이 오픈 소스 코드에 대해 이렇게 가정합니다.

하지만 오늘 설명하는 세 가지 취약점은 15년 동안 Linux Kernel의 일부로 사용되어 온 코드에서 발견되었습니다. 눈에 잘 띄는 이 취약점들이 오래 전에 발견되었을 거라고 생각했지만 그렇지 않았습니다.

따라서 어떤 면에서는 오픈 소스 코드가 면밀히 조사할 수 있기 때문에 더 안전하다는 전제가 언뜻 보기보다 타당하지 않을 수도 있습니다.

반대로 지능형 지속적 위협(APT) 공격자가 지능형 지속적 위협(APT) 공격자가 이러한 취약점을 화이트햇 보안 연구원보다 먼저 발견했는지, 발견한 정보를 가지고 무엇을 했는지도 알기 어렵습니다. 엄청난 양의 매년 발견되는 Linux Kernel 취약점의 양 또한 보안 침해로 이어질 수 있는 아직 발견되지 않은 취약점이 많다는 것을 의미합니다.

패치를 적용하면 서버를 절약할 수 있습니다.

Linux Kernel 취약점은 계속 쌓여가고 있으며, 15년 된 코드에서도 여전히 놀랄만한 취약점이 발견될 수 있습니다. 보안 연구자들이 아직 발견하지 못한 취약점에 대해서는 패치를 적용할 수 없지만, 공개 도메인에 있는 취약점 및 관련 익스플로잇에 대해서는 패치를 적용할 수 있습니다. 그렇게 하지 않는 것은 어리석은 일입니다.

알려진 취약점에 대한 패치는 시스템을 더욱 단단하게 만듭니다. 연구자들이 아직 발견하지 못한 취약점으로 인해 공격자가 네트워크에 침입하더라도 알려진 익스플로잇에 대해 시스템이 지속적으로 패치를 적용하고 있다면 측면 이동이 더 어려워질 것입니다.

하지만 우리 모두 알다시피 일관된 패치는 쉽지 않습니다. 종종 재부팅이 필요하고 서버를 오프라인 상태로 전환하여 서비스를 중단해야 합니다. 패치 작업에는 시간이 걸리는 노동 시간도 있습니다. 이러한 이유로 패치를 소홀히 하는 경우가 많습니다.

자동 패치 적용 고려

Linux 기반 운영 체제를 사용하는 기업에는 자동 패치를 배포할 수 있는 옵션이 있어 OS 패치를 수동으로 적용할 필요가 없습니다.

자동 패치 솔루션인 KernelCare 자동 패치 솔루션의 경우 재부팅 없이 실시간 패치가 가능하다는 추가적인 이점이 있습니다. 즉, KernelCare는 서버를 재시작할 필요 없이 서버를 자동으로 패치하고 실시간으로 패치를 수행할 수 있습니다.

그러나 신중한 수동 패치 또는 KernelCare와 같은 라이브 패치 도구 중 어떤 경로를 선택하든 기존 및 새로운 위협으로부터 워크로드를 보호하려면 지속적으로 패치를 적용하는 것이 중요합니다.

패치 릴리스 일정

현재 KernelCare 팀은 이러한 취약점에 대한 재부팅 없는 패치를 개발 중입니다. 첫 번째 패치는 3월 18일에 배포될 예정입니다. 패치가 배포되면 이 블로그 게시물을 계속 주시하여 업데이트를 받아보세요.